Stage-gate process: the five stages, what happens at a gate, and a worked example

A stage-gate process splits new product work into a fixed sequence of stages, with a management decision point called a gate between each one. At every gate the project is given one of four verdicts: go, kill, hold or recycle. The point of the structure is to stop weak projects early, before they consume the budget that a strong one needed.

Robert G. Cooper built the model from empirical research into how companies that consistently launched successful products actually worked, and the term "Stage-Gate" first appeared in print in 1988. It spread because it solved a real and expensive problem: organizations were funding new product projects to completion because cancelling one felt like an admission of failure, and by the time the failure was undeniable the money was gone. Stage-Gate made killing a project a scheduled, unremarkable event rather than a scandal.

Nearly four decades later it is still the default operating model for corporate product development, and most enterprise innovation management software is essentially a workflow engine wrapped around it. It is also routinely misunderstood, usually by teams who inherit the ceremony without the logic. This piece covers the stages, what actually happens at a gate, a worked example, how it compares to agile, and the assumption it never states.

What is the stage-gate process?

The stage-gate process is a roadmap for moving a project from idea to launch through alternating periods of work and decision. Stages are where cross-functional teams do the work: research, design, build, test. Gates are short, scheduled reviews where a group of decision makers with budget authority decides whether the project continues, using criteria agreed in advance rather than invented in the room.

The separation is the whole design. Inside a stage, the team is trusted to work without interference. At a gate, the team has no vote. That division stops two common failure patterns at once: executives redirecting a project weekly, and teams marking their own homework. Stage-Gate International, the consultancy Cooper founded, reports that the great majority of North American product developers use some version of the model, and while that is a figure from a party with an interest in it, the underlying point is uncontroversial. Almost every large product organization runs something gate-shaped, even when they call it something else.

What are the five stages of the stage-gate process?

The canonical model has five stages, preceded by a discovery phase that generates candidate ideas and separated by five gates. The names vary by company. The sequence rarely does.

What happens at a gate?

A gate has three parts: deliverables, criteria and an output. The team arrives with a defined set of deliverables agreed at the previous gate. The reviewers judge them against criteria that were also set in advance, usually a mix of must-meet items that kill a project outright and should-meet items that are scored. The output is a verdict plus, if the project survives, an approved budget and the deliverables required at the next gate.

The four possible verdicts matter more than teams expect. Go continues with funding. Kill ends it. Hold means the project is sound but the resources are not available now, which is an honest answer that most organizations avoid because it sounds indecisive. Recycle sends the project back to redo part of the stage, and is the verdict that gets abused: a gate that recycles everything is a gate that has stopped deciding.

Gates fail in one direction almost universally. They become status meetings. The tell is that no project has been killed in a year, which does not mean your idea quality is exceptional. It means the gate is not doing the one job it exists to do. A second, quieter failure is arguing about the numbers instead of the decision, which happens when nobody pulled the actual figures beforehand and the room is left comparing recollections. Getting the real number out of the warehouse before the meeting rather than during it, whether that is by querying the data directly in plain English or by making one analyst responsible for the pack, removes an astonishing amount of gate-meeting friction.

Stage-gate process example

Take a US B2B software company adding a payments feature. Discovery surfaces the opportunity from three support themes and a competitor launch. At Gate 1 it passes the idea screen in ten minutes, because the strategic fit is obvious and the cost of a look is two days.

Scoping finds a plausible market and one significant problem: compliance requirements the team has never dealt with. Gate 2 says go, and explicitly names the compliance question as the thing the business case has to answer. Stage 2 produces customer interviews with eleven accounts, a technical spike, a compliance assessment, and a financial case showing payback in fourteen months. Gate 3 is the expensive one, and it goes to hold rather than go, because the two engineers who would build it are mid-migration and will not be free for a quarter. That is the model working. A year later, most organizations would have started anyway, staffed it with whoever was available, and delivered something late and thin.

Development runs a quarter behind the hold. Gate 4 catches that the assumed transaction volume came from eleven interviews, all with the largest accounts, so validation adds a paid pilot with mid-market customers before launch. Gate 5 funds the launch. The feature ships fourteen months after the first support ticket, which sounds slow until you count the three other ideas that died at Gate 1 and Gate 2 for the price of about six days of work each.

What are the advantages and disadvantages of the stage-gate process?

The advantages are real and mostly about money. It kills weak projects while they are still cheap. It makes decisions visible and auditable, which matters enormously in regulated industries and in any organization where a project's survival otherwise depends on its sponsor's seniority. It forces cross-functional involvement early, so manufacturing or compliance objections surface at Gate 2 instead of two weeks before launch. And it gives teams protected working time between reviews, which is genuinely rarer than it sounds.

The disadvantages are equally real. It is slow, and its critics are right that a rigid five-gate process applied to a small incremental feature is pure overhead. It rewards projects that produce good documents, which is not the same population as projects that produce good products. It assumes you can forecast a market at Gate 2, which is reasonable for a line extension and close to fiction for anything genuinely new. And it can turn into theater: gates that never kill, deliverable checklists nobody reads, and a business case written backwards from the desired conclusion. Cooper himself has spent years arguing for lighter, more flexible versions precisely because so many implementations became bureaucratic.

Is the stage-gate process better for incremental or discontinuous innovation?

Incremental, clearly, and this is the most useful thing to know before adopting it. The model asks for a market forecast and a financial case early, and those are answerable when you are extending a known product into a known market. For genuinely new-to-the-world work, the honest answer at Gate 2 is that nobody knows, and a process that demands a number will get a fabricated one.

Most mature organizations run two tracks for this reason. Incremental and platform work goes through the full process. Genuinely uncertain work goes through a lighter, faster path where gates fund the next experiment rather than the next stage, and the deliverable is evidence rather than a forecast. Keeping both is more honest than either pretending your innovation portfolio is uniform or abandoning governance entirely. If you are deciding which track a given piece of work belongs on, the criteria worth using are in idea evaluation criteria.

Stage-gate versus agile: which one do you need?

This is framed as a choice far more often than it is one. They operate at different levels. Stage-gate is a business governance model that answers "should we fund this project", at intervals of weeks or months, with the decision made by people who control budget. Agile is a delivery model that answers "what should we build next", at intervals of days or weeks, with the decision made by the team and its product owner.

The common and workable arrangement is agile inside the stages and gates around them. Stage 3 becomes a series of sprints rather than a waterfall build, and the gate at its end asks a business question that no sprint review covers. The friction shows up in two places: gate deliverables written for a document-heavy process, and gate dates that ignore sprint boundaries. Both are fixable by rewriting the deliverable list to accept working software and validated learning as evidence. Where the two genuinely conflict is scope. Agile expects scope to change as the team learns; a gate approved a specific business case. The resolution is to require a return to the gate when the change is large enough to alter the economics, and to leave the team alone when it is not. The wider comparison of how these two philosophies fit together is in design thinking versus agile, and the question of how a roadmap absorbs both is covered in product roadmap prioritization.

The assumption the model never states

Every stage-gate implementation is a filter, and a filter's output quality is capped by its input. The process is superb at telling you which of the eleven ideas in front of you deserves funding. It has nothing whatsoever to say about whether those eleven were the right eleven, or whether the idea that would have doubled the business was never submitted because nobody thought of it in the shower.

This is why so many organizations end up with a beautifully governed pipeline producing consistently unremarkable products. Every gate works. Every criterion is applied. And the whole apparatus is grinding through a candidate set that was assembled casually, from whatever occurred to a handful of people under normal working pressure. The discovery phase is nominally where this is fixed, and in most companies it is the least resourced part of the entire model.

Fixing it is not complicated, but it does have to be deliberate. Run discovery as a scheduled session rather than a standing invitation. Generate widely and silently before anyone discusses anything, so the first person to speak does not set the boundary of what gets proposed. Cluster the output into named themes so the review sees a dozen coherent directions instead of ninety fragments, and score impact against effort before Gate 1 so the screen is judging a ranked shortlist. The studio at the top of this page is built for exactly that first step: put the real problem in, get dozens of tagged directions back, and walk into Gate 1 with a candidate set that is wider than what your team already believed. A gate can only judge what walks in.