For most of GreatCTO's life the pipeline started at the architect. You typed /start "build X", the architect drafted an ARCH doc and ADRs, and the first thing you approved was the architecture.
That always bugged me. By the time you're approving architecture, you've already answered the expensive question — should we build this at all, and what exactly? — silently, in the prompt. The architect is brilliant at HOW. Nobody owned WHAT and WHY.
So we added stage zero: a product-owner agent that runs before the architect. And we moved the single human gate to it.
What it does
product-owner is the cheapest place in the pipeline to say no. It runs four steps before a line of architecture is written:
- Frame the problem — restate the idea as a problem, not a solution. "I want a booking app" becomes "solo operators lose jobs because scheduling lives in their head." It locks who has the pain, what it costs them today, why now, and one measurable success metric.
- Diverge — generate 3–5 genuinely different bets (different user, different wedge, different scope), not cosmetic variants of one idea.
- Debate — the part I'm most proud of (below).
- Synthesize — write a brief the CTO can approve or kill in 60 seconds, and hand the architect a complete, unblockable handoff.
If the call is don't build, the pipeline stops here and writes the reason down. That's a feature, not a failure.
Top feature: a 4-model idea debate
A product owner who validates every idea is useless. To keep it honest, the brainstorming skill spins up a panel of four personas, each on a different model, debating over two rounds:
| Persona | Argues | Model |
|---|---|---|
| Visionary | the strongest case FOR — the 10x outcome | Opus |
| Skeptic | the strongest case AGAINST — why it dies | Sonnet |
| User-Advocate | the user's honest reaction — would I pay, switch, care? | Haiku |
| Pragmatist | cost, time-to-ship, build-vs-buy, unit economics | Kimi K2 |
Model diversity matters: different model families fail differently, so they catch different holes. Round 1 is blind and parallel; round 2 feeds each persona the others' positions and asks for a rebuttal plus the one condition that would change its mind. The product-owner (Opus) chairs — it doesn't count votes, it names the decisive consideration and preserves dissent.
The whole panel costs $0.30–0.60 per idea. That's the cheapest insurance in the pipeline: it runs before any engineering time is spent, at the stage where "no" is free and "yes" is expensive.
How it actually helps you build
We ran it for real on a test product — PatientFlow, a reminders + intake app for small medical clinics — and the debate did exactly what a good product review does:
- Visionary (Opus): BUILD — no-show reminders + auto waitlist backfill, ~$140K/yr leaking per clinic, week-one ROI.
- Skeptic (Sonnet): DON'T BUILD — reminders are commoditized and bundled free by incumbents; you can't price them standalone.
- User-Advocate (Haiku): BUILD, but warned 40% of an older patient panel has stale phone numbers and staff won't adopt a second login.
- Pragmatist (Kimi): PIVOT — only the metadata-only version (no PHI, no HIPAA BAA) keeps margin alive.
The chair's synthesis wasn't an average. It found the one move that escaped both kill-vectors — the auto-backfill wedge scoped to appointment metadata only — and encoded the Skeptic's surviving objection as a kill criterion with a threshold ("if fewer than 3 of 10 clinics will pay ≥$200/mo standalone, stop"). That's a brief an architect can build against and a CTO can bet on.
Why we went to one gate — and why we moved it
GreatCTO's whole philosophy is one human gate: you approve the direction, the pipeline does the rest. CI and the generated tests are the quality gate; you sign the spec, not every line. More gates don't buy you more safety past a point — they buy you context-switching and rubber-stamping.
But here's the thing we got wrong at first: the gate was at the architect. So the one decision you made was "is this architecture good?" — which is answering the right question about the wrong thing. If the product is wrong, a perfect architecture just helps you build the wrong thing faster.
So we moved the gate upstream, to the product brief: gate:product. You approve WHAT and WHY before HOW. The architect now runs after your approval, on a validated brief — it never burns a cycle architecting something you'd have killed. One gate, at the only point where your judgment is irreplaceable: deciding what's worth building.
The receipt: an eval that caught its own bug
We don't ship pipeline changes on vibes. We ran the product-owner's output through an independent evaluator scored 0–100, and the first version scored 74.
It lost almost all its points in one place: the handoff. The brief was excellent, but it forgot to write mode, team-size, cost-cap, and geo into the project manifest — which means the architect's own gate would have blocked on the next step. The eval caught a real integration bug, not a style nit.
We fixed the spec (it now writes the full handoff contract and self-checks before raising the gate), re-ran the same eval, and it scored 94 — with the architect-acceptance check flipping from BLOCK to PROCEED. The agent even auto-classified the project as healthcare and set the stricter compliance fields on its own.
Wire it, guard-test it, eval it. Every new agent in GreatCTO ships with a structural test that asserts it's actually in the pipeline — because creating agents/product-owner.md isn't the same as wiring it.
Try it
npx great-cto init
/start "describe the product you want to build"The product-owner frames it, runs the debate, and hands you a brief. Approve it once — everything after is automated, through to a shipped repo and a live URL.
It's free, MIT, and runs locally. The product-owner prompt and the brainstorming skill are on GitHub — read them, override them, fork them.