Innovation Deliver

Stage-Gate

Stage-Gate runs product development as stages separated by go or kill decisions, so investment grows only as uncertainty falls.

The questionAt this point, do we fund the next stage, kill the project, or send the work back?

Also called a phase-gate process. Stage-Gate is a registered trademark of Stage-Gate International.

Process · Robert G. Cooper, 1980s to 1990

1
Discovery Ideas, before Gate 1
2
Stage 1 Scope Cheap look, after Gate 1
3
Stage 2 Business case After Gate 2
4
Stage 3 Development After Gate 3
5
Stage 4 Testing After Gate 4
6
Stage 5 Launch After Gate 5

Work happens in stages. A gate before the next stage decides go, kill, hold, or recycle.

When to use it

Many product ideas compete for the same development budget, and weak ones keep absorbing spend because nobody has a kill point.
Investment jumps to a full build on a slide deck, before technical or market uncertainty has been reduced.
Functions sign off in parallel with different criteria, and a project can reach launch missing a commercial case or a manufacturing path.
Leadership wants a visible rule for when spend is allowed to grow.

When to avoid it

The uncertainty is whether anyone wants the product at all, and the cheapest test is a prototype in front of customers. Lean Startup or customer development fits, possibly inside an early stage.
The work is a known enhancement to a current line, with no technical or market doubt. A full five-gate system is overhead.
Gates will be staffed by people who will not kill. A process that never kills is a reporting calendar.
A regulation or contract already fixes the sequence and the reviews. Use that structure. Do not add a second gate system on top.

Overview

Stage-Gate runs product development as stages of work separated by gates, so the next increment of spend is released only when the last increment has reduced uncertainty. It supports the choice, at each gate, to go, kill, hold, or recycle. Stage-Gate is a registered trademark of Stage-Gate International.

A gate system that never kills is a reporting calendar. Early stages should buy customer and technical information, not documents, and criteria should tighten as the check gets larger. Use a lighter path for known line extensions, and do not let the gates forbid the cheap experiments those early stages exist to fund.

Stages, gates, and decisions

Discovery

Idea generation, sitting before the first gate. It is not a funded stage in the usual model. The output is enough of a proposal to survive Gate 1, not a business case.

Stages

Cross-functional work packages whose cost rises as the product firms up. A common five-stage pattern is scope, business case, development, testing and validation, and launch. Each stage has defined work, not "keep going." Cooper's later versions compress or overlap stages for lower-risk projects.

Gates

Decision points with required deliverables, criteria, and a small group of decision makers who own the money. A gate without kill authority is a status meeting. Criteria should be visible before the stage starts, so teams know what they are building evidence for.

Go, kill, hold, recycle

The four usual calls. Go funds the next stage. Kill stops spend. Hold freezes the project. Recycle sends it back to finish missing work. Recycle used every time is a polite refusal to kill.

Deliverables and criteria

What must be on the table at the gate, such as a market estimate, a technical feasibility check, a cost model, or test results. Criteria should get stricter as spend grows. Early gates can be qualitative. Late gates should not be.

What it is not

A waterfall plan with extra meetings. If the gates cannot kill, you have a staged reporting cycle, not Stage-Gate.
A substitute for learning from customers. Early stages should buy information. If Stage 1 is a thick report and no customer contact, the process is theater.
Agile's opposite by necessity. Many firms run sprints inside a stage and keep the gates for funding. Do not promise adaptiveness if Gate 3 still freezes the spec.

The steps

Inventory the live projects and the money already in them

List every item that is consuming development spend, with stage if any, spend to date, and the next decision date. If there is no decision date, that is the first finding.
Set gates where spend would jump

Place a gate before each material increase in cost, such as detailed design, tooling, or launch spend. Write the deliverables and the go-or-kill criteria in advance. Keep the decision group small and able to stop the money.
Run the current list through the first hard gate

Do not wait for new ideas. Put live projects through the earliest gate they cannot honestly pass. Kill or recycle. This is how the process earns credibility.
Make early stages buy information

Scope and business-case stages should produce customer evidence, technical feasibility, and a cost range, not a thicker deck. Time-box them. A Stage 1 that lasts as long as development is a failure of the design.
Review the gates, not only the projects

After a few cycles, count kills, recycles, and overruns. If nothing is killed, tighten criteria or change the decision makers. If everything is killed, the idea pipeline is the problem, not the gates.

In practice

A manufacturer has eleven "in development" SKUs and has not killed one in three years. Average spend before launch is 14 months and $1.1 million. Two recent launches missed forecast by more than 60 percent. The consultant maps the actual path of the last six: a kickoff deck, then engineering spend, with marketing and manufacturing pulled in after tooling is ordered. There is no written kill criterion.

A five-gate skeleton is put on the current list, with Gate 2 requiring a named customer sample, a unit-cost range, and a channel path, before detailed design. Of the eleven, four cannot produce a customer sample in three weeks and are killed at a reconstituted Gate 2. Two recycle to finish cost. Five go to development with a spending cap and a Gate 3 date. Six months later, one of the five is killed at Gate 3 when factory trials miss the cost range. The other four are still in process, and the development budget is down by about a third.

What you leave with

A list of live projects with spend, a stage, and a next gate date.
Written deliverables and criteria for each gate, visible to the teams.
A named decision group with kill authority.
A first pass that has actually killed or recycled some of the current list.
A simple count of go, kill, hold, and recycle, reviewed on a calendar.

Failure points

Gates that never kill

Every project gets a conditional go. Spend continues, the portfolio stays crowded, and the process is blamed for bureaucracy it does not actually impose.

Late gates with early-gate evidence

A launch gate is passed on the same qualitative story that survived Gate 1. Criteria have to get harder as the check grows.

Functional sign-off instead of a gate

Each department approves its piece on its own form. Nobody owns the whole go-or-kill call, so a project can reach tooling with no channel and no cost range.

Stage work as documentation

Teams write the required documents and skip the tests those documents were meant to summarize. The gate pack is thick and the uncertainty is unchanged.

Stage-Gate used to block cheap experiments

A landing page, a handmade prototype, or a customer visit is told to wait for Gate 3. Early stages exist to fund that learning. If the process forbids it, it is being used as a brake, not as a funnel.

The failures above are usually Leverage & IP: it was used once, and nothing was left that makes the next engagement easier.

Origin

Robert G. Cooper developed the process from studies of why new products succeed or fail, beginning in the 1980s. He published the named Stage-Gate system in Winning at New Products and in "Stage-Gate Systems: A New Tool for Managing New Products," Business Horizons, 1990. The idea is that development runs in stages of increasing spend, and that a gate with defined deliverables and a go, kill, hold, or recycle decision sits before each increase. Cooper later described faster and more flexible variants for firms that found the original gates slow.

Stage-Gate is a registered trademark of Stage-Gate International (Stage-Gate Inc.). Cooper co-founded the firm. The process diagrams, training, and software sold under the name are copyrighted and licensed. This note describes the logic of stages and gates in its own words and does not reproduce the firm's templates or artwork. Phase-gate is the generic name for the same pattern.