--- name: stage-gate-review description: Run or prepare a stage-gate product governance review — the go/no-go checkpoint where a council approves an initiative to advance through fixed innovation stages (Frame → Concept → Prototype → Validate → Scale), each gate guarded by a per-discipline readiness checklist. Use when preparing a Product Council / steering-group ask, building a go/no-go checklist, designing an innovation governance process, or auditing whether an initiative is genuinely ready to advance vs faking the gate. Trigger phrases include "stage gate", "product council", "go/no-go", "advance to the next stage", "is this ready to progress", "gate review", "phase gate", "innovation governance". --- # Stage-Gate Review A governance pattern for moving product/innovation initiatives through fixed stages under explicit go/no-go control. A standing council (or steering group) approves each advance; every gate is guarded by a **per-discipline readiness checklist**. The point is not bureaucracy — it is to kill weak bets early and fund strong ones with conviction. This skill is the **transferable pattern**, stripped of any client instance. When a real engagement uses it, the client's council names, internal tooling, stage labels, and named contacts stay inside the client boundary (see *Client instances* below) — never bake them into this skill. --- ## The gate ladder Five stages, escalating commitment. Each arrow is a council ask. | Stage | Question it answers | Funding posture | |-------|---------------------|-----------------| | **Frame** | Is this opportunity worth exploring? | Cheap time only | | **Concept** | Is there a solution worth prototyping? | Small dedicated resource | | **Prototype** | Does the solution work and is the business case real? | Build budget | | **Validate** (market test) | Will a real customer pay / adopt? | Pilot budget + infra | | **Scale** (commercialize) | Should we invest to grow this? | Full commercial investment | Key rule: **the earliest gate (Frame → Concept) is usually feedback-only**, not approval. You bring it to the council to sharpen thinking, not to pass judgment — killing ideas at Frame teaches teams to stop framing. Approval pressure starts at Concept. The bar rises each gate: hypothesis → tested hypothesis → validated evidence + business case → signed pilot commitment → full commercial commitment. --- ## The discipline checklist Every gate is a matrix: **the same disciplines, a higher bar each stage.** A gate ask is "ready" only when every applicable discipline clears its bar for that stage. Adapt the discipline set to the domain; this is the default spine. | Discipline | What it guards | Rises from Frame → Scale | |------------|----------------|---------------------------| | **Ownership** | A named, committed product owner exists | identified → secured → full commitment to commercialize | | **Strategy fit** | Aligns with org strategy & objectives | alignment asserted → tie to portfolio confirmed | | **Economics** | Revenue + fully-loaded cost through the horizon | rough estimate → validated business case, approved | | **Customer/market evidence** | Real demand, tested with real people | hypotheses commissioned → tested → signed pilot partner | | **Experience / design** | Desirability and usability validated | design lead secured → evaluative testing + quality score | | **Technical feasibility** | Build assumptions reviewed by engineering | assumptions noted → reviewed → infra cost approved | | **Legal / risk / compliance** | Regulatory and contractual exposure surfaced | initial review → SME overviews → docs initiated | | **Go-to-market / region** | Launch market and support model identified | market aware → aligned → support & business model agreed | | **Timeline** | A credible plan to complete the next stage | — | | **System of record** | The initiative is tracked in the canonical tool | — | A discipline that clearly doesn't apply gets **explicitly waived** ("no regulatory surface — legal waived"), never silently dropped. Silent omission is the most common way a gate rots. --- ## Running a gate review **Preparing an ask (you are the team):** 1. Identify the target gate and pull its column from the matrix. 2. For each discipline, gather the evidence that clears *this stage's* bar — evidence, not intent. "We will test" does not clear a "tested" bar. 3. Mark every discipline: cleared / waived (with reason) / gap. 4. If any gap is on a discipline that gates the whole bet, **do not bring the ask** — close the gap or bring a feedback-only ask instead. **Chairing a review (you are the council):** 1. Ask for the evidence behind each "cleared", not the claim. Claims are theatre. 2. Probe the one discipline most likely to be faked for this stage (see anti-patterns). 3. Decide: advance / hold (named gaps, re-ask) / kill. A council that never kills is a rubber stamp and the gate is worthless. --- ## Anti-patterns (gate theatre) - **Checklist completion ≠ readiness.** Every box ticked, zero evidence. Demand artifacts. - **The pre-approved gate.** Decision made in the hallway; council ratifies. The gate adds cost and zero filtering. - **Evidence inflation.** "Validated" demand that is one friendly customer's enthusiasm. - **Skipping the kill.** Weak bets get "hold and re-ask" forever instead of a clean death. - **Frame-stage judgment.** Approving/rejecting at Frame teaches teams to stop exploring. - **Bar that never rises.** Same evidence accepted at Prototype as at Frame — the ladder collapses into one gate. --- ## Operator judgment (hard-won) The matrix above is generic best practice. This section is the part that comes from running real reviews — apply it over the spine. ### Which gates to collapse, and when - **Low uncertainty + high strategic fit** (you already know the customer wants it): collapse **Prototype + Validate** — build the real thing *as* the pilot. The separate prototype gate buys nothing when desirability isn't the risk. - **Moonshot / high uncertainty**: never skip **Validate** — that's the whole bet. You can skip the formal **Concept** gate (run it feedback-only) but you cannot skip proving demand. ### Where the gate gets faked — tells by stage - **Concept:** "customer research" that's really 3 friendly stakeholder chats with no disconfirming evidence sought. Worse and more common: a Concept backed only by **selective external research carried over from Frame** — the team cherry-picks the framing-stage evidence that flatters the idea and runs no fresh test. Reused evidence is not validation. - **Validate:** a "signed" pilot that is actually a warm LOI — no money committed, no go-live date. Intent dressed as commitment. ### Minimum real evidence — calibrate to what the stage *can* know Don't demand certainty a stage can't yield. The honest question is "how much **can** we know at this point?" — and against that bar, **any genuine external signal beats internal conviction**. Often the highest-value move at an early gate is simply getting *the first real evidence at all*, where before there was only opinion. So: - Reject "cleared" that rests purely on internal belief or reused framing evidence. - Accept directional external evidence early; raise the bar to **committed** evidence (paid pilot, money down, a date) by Validate. - **Economics:** distrust a polished Year-3 revenue model. Trust fully-loaded cost plus one defensible near-term number over a confident long-horizon fiction. ### The two killers (what actually defeats a gate) - **Political pre-commitment.** Some bets management simply *wants*, regardless of evidence. A gate cannot kill what leadership has already decided. Name it when you see it — the gate is theatre on that bet, and pretending otherwise corrodes every other gate. - **Sunk-cost attachment.** You advance the wrong concept, then get too vested to kill it. The antidote is a **scientific mindset with no emotional attachment to the solution**. The disease is **solutions looking for problems to solve** — fall in love with the problem, stay ruthless about the solution. A gate's deepest job is to enforce exactly this detachment. > Validated under fire — these belong in the brain as a standalone principle too, so they > outlive this one skill. See [[solution-looking-for-problem]], [[stage-gate-sunk-cost]]. --- ## Client instances When this pattern is instantiated for a named client, the instance is **confidential and stays in the client boundary**: - Council/forum names, internal stage labels, internal tooling, named contacts, strategy specifics, deal terms → client dir/org only, local models only, never the public brain. - This skill carries the **pattern**; the client carries the **wrapper**. Never merge them.