skills/stage-gate-review/SKILL.md

name, description

name

description

stage-gate-review

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.