Stage-Gate Process: Stages, Gates, Examples, and How It Works

Overview

Building a new product costs money long before it earns any. Engineers need time, prototypes need materials, and marketing needs a budget. But some ideas don't hold up once the team starts asking basic questions. Do customers need this? Can we build it at a reasonable cost? Will anyone pay enough to make it worthwhile?

The hard part is that you rarely know these answers at the start. You learn them as the project moves along. So a company needs a way to make investment decisions in steps across the project lifecycle: put in a little money, learn something, then decide whether to put in more.

That is what the Stage-Gate process does. It splits the product development process into stages of work, with a decision point after each one. In this guide you'll see how the stages and gates are structured, what gets checked at gate reviews, how a project moves from idea generation to launch, and how to set the process up without burying your project teams in approvals.

What Is the Stage-Gate Process?

The Stage-Gate process is a project management methodology built for new product development. Work is split into stages, and each stage ends with a gate where managers decide whether the project gets more money and people. A stage is a period of work with a clear goal: research the market, build a prototype, run field tests. A gate is a meeting where the results of that work are reviewed and a decision is made about what happens next.

The model was developed by Robert G. Cooper, a product innovation researcher who studied why some new products succeed and others fail. Cooper coined the term "Stage-Gate," which first appeared in print in 1988, and described the system in detail in a 1990 Business Horizons article, "Stage-Gate Systems: A New Tool for Managing New Products." Stage-Gate is a registered trademark of Stage-Gate International, the consulting firm associated with Cooper. You will also see the same idea under other names, such as phase-gate, phase-review, or gated development.

The stage gate model was built for product development projects, and that is still where many organizations use it most. The underlying principle, though, shows up in many other places: capital projects, IT programs, and pharmaceutical pipelines all use some form of "do a chunk of work, then decide whether to continue."

Here is what this looks like in practice. Say a company wants to build a new handheld device for warehouse workers. Before it pays engineers to build a working prototype, it checks three things. Is there real demand, meaning have potential buyers confirmed the problem and shown interest? Is it technically feasible with available components and the team's skills? And do the rough numbers work, with a plausible price that covers the expected cost? If any of those answers come back weak, the company has spent a few weeks of research instead of a year of engineering. Catching costly mistakes at this point is the whole idea behind the stage gate approach.

How Does the Stage-Gate Process Work?

The rhythm is simple. A cross-functional team does the work of a stage: research, design, testing, whatever that stage calls for. The project manager pulls the results into a set of agreed deliverables and brings them to a gate review. At the gate, the managers responsible for the next round of funding look at the evidence and make a decision. If the decision is Go, the project moves forward into the next stage, which costs more, and the next gate asks harder questions.

What makes this different from a simple project plan with sequential phases is that the path isn't fixed. A project can move forward, but it can also be sent back to fill gaps, put on hold while resources go elsewhere, or stopped. Cooper's own description of the model stresses that real projects loop back and iterate within and between stages; the neat left-to-right picture is a simplification.

The work inside a stage also isn't handed from one department to the next. Marketing, engineering, operations, and finance usually work on the same stage in parallel, because the gate will ask about all of those areas at once. Working this way also keeps stakeholders from different departments on the same page about project progress.

A common version of the flow looks like this:

Read it left to right, top row first: after Gate 3, the project enters Development. The dashed line shows one possible return path, here from Gate 4 back to Development; any gate can send a project back. This is the most widely cited layout, not the only one. Many companies merge stages, add extra gates for regulated industries, or run a shortened version for small projects.

The 6 Stages of the Stage-Gate Process

The classic stage gate model has a discovery phase followed by five key stages. Each stage represents a different set of questions, and the financial commitment usually grows as the project advances. To keep things concrete, we'll follow one illustrative project through every stage: a company that sells heating and cooling equipment to commercial buildings is considering a smart thermostat for small offices. The company and figures are invented. The full example later in the article returns to the same project and looks at the decisions made at each gate.

One naming note: Stage-Gate International's current overview calls Stage 1 "Concept" rather than "Scoping." The work is the same, and many companies still use the older label.

Stage 0: Discovery

Goal: find new ideas worth looking at. Idea generation draws on many sources: customer complaints, sales feedback, technical breakthroughs in the lab, competitor moves, or changes in regulation.

What the team does: talks to customers about their problems, reviews support tickets, scans what competitors are doing, and runs idea sessions. The output isn't a product spec. It's a short description of a problem and a hypothesis about how to solve it.

Example: A regional sales manager keeps hearing the same complaint from small-office clients such as dental clinics and accounting firms: heating bills are high, and nobody remembers to change the thermostat schedule. A product manager turns this into a one-page idea: a simple smart thermostat that learns office hours and can be adjusted from a phone.

Stage 1: Scoping

Goal: decide, quickly and cheaply, whether the idea is worth a proper investigation. It is usually short and relies mostly on desk research.

What the team does: sizes the market roughly, looks at existing products, flags obvious technical constraints, and checks whether the idea fits company strategy. At this point the team works with information it can gather quickly; extensive research and detailed planning come later, if the idea passes the gate.

Example: The team finds that consumer smart thermostats aren't designed for shared offices with several users, while the company's own commercial systems cost far too much for a 20-person office. An engineer confirms that existing control boards can be reused. The question here is whether there's an obvious reason the idea can't work. There isn't.

Stage 2: Build the Business Case

Goal: turn a promising idea into a defined, justified project. Business case development is the last step before heavy spending, so it gets more rigor than the earlier stages.

What the team does: primary market research such as interviews, concept tests, and voice-of-customer work; a technical feasibility assessment; a first financial model; and a product definition that states who the product is for, what it must do, and what it won't do. It ends with a project plan and budget for development.

Example: Interviews with 30 office managers show that interest is strongest in offices that pay their own utility bills. Where the landlord pays, few people care. That narrows the target market considerably. The team also sets a target price and a target unit cost, and these two numbers carry most of the financial model.

Stage 3: Development

Goal: build the product, along with the plans to make, sell, and support it.

What the team does: detailed design, engineering, creating prototypes, and software development. In parallel, operations plans manufacturing, and marketing drafts the marketing strategy for launch. The deliverable is a working prototype ready for testing with real users.

Example: Engineers build a working prototype and a basic mobile app. The device works, but supplier quotes for production volumes come in well above the target unit cost, mainly because of the wireless module and the display. This is the stage where "can we build what we defined, at the cost we assumed?" gets a real answer. Here, the answer is not yet.

Stage 4: Testing and Validation

Goal: confirm the product works, customers will buy it, and the company can produce and support it at scale.

What the team does: field trials or beta testing, lab and certification testing, trial production runs, and sometimes a test market. The team also updates the financial model with real cost data.

Example: Sixty units run in 15 offices for one heating season. The learning feature works well, but office managers struggle with the initial setup, and support calls are much higher than planned. The team simplifies the setup flow before launch. This stage answers whether the product holds up outside the lab and whether the numbers are still true.

Stage 5: Launch

Goal: bring the product to market and make sure it performs as expected.

What the team does: ramps up production, trains sales and support, runs marketing campaigns, and tracks project outcomes against the business case. Cooper's model ends with a post-launch review, after which the product moves into normal business management.

Example: The thermostat launches through the company's dealer network in one region first. The team watches sales, returns, and support calls, and schedules a post-launch review six months out.

Stage summary

What Happens at Each Gate?

A gate review is not a status update. The point isn't to list everything the team has done. It's to decide whether the results justify the next, larger investment. Cooper's model frames gates as forward-looking: the question is "should we commit resources to the next stage?" rather than "did we finish our tasks?"

The decision-makers are called gatekeepers. They're usually senior managers from different functions, such as R&D, marketing, sales, operations, and finance, who control the budget and people the project needs next. Early gates might involve a small group of department heads. Later gates, where the spending gets serious, often involve the business unit's leadership team. The project manager and development team attend and present.

Each gate has three parts. First, deliverables: what the team was asked to bring, defined in advance. Second, criteria: the questions the project is judged on. Third, outputs: a decision, and for a go, an agreed budget, timeline, and date for the next gate.

Who does what around a gate

The four gate decisions

Go means the project moves to the next stage, and resource allocation for that stage is settled at the same meeting. A "go" without a budget and named people is really just a polite delay.

Kill means the project stops. The team and money move to other work. A kill is a successful outcome of the process if it happens early: the company learned something important before paying full price for it.

Hold means the project is worth doing, but not now. Usually there's a stronger project competing for the same people, or the timing is wrong, for example because a key customer has frozen budgets. The project goes back into the queue. When the bottleneck is people rather than budget, some companies keep the project moving by adding temporary capacity through resource augmentation instead.

Recycle means the project needs more work before it can move forward. Some deliverable is missing or weak, and the team goes back to fill the gap. A business case built on five customer interviews when the gatekeepers expected twenty is a typical recycle.

Must-meet and should-meet criteria

Gate criteria usually come in two types.

Must-meet criteria are pass/fail. If a project fails one, it can't proceed, no matter how good everything else looks. Examples include strategic fit with business objectives, legal and regulatory clearance, and freedom to operate on patents. Picture a medical device with large commercial potential, where the team learns the required certification would take three years longer than the market window. That single fact can block the project.

Should-meet criteria are scored. They describe how attractive the project is, and gatekeepers weigh them against each other: market size, competitive advantage, expected profitability, how well the project uses existing capabilities. A project can score low on one and still pass if it is strong elsewhere.

Stage-Gate International describes gate criteria in terms of project readiness and business value, and recommends combining a risk-adjusted financial model with a scorecard rather than relying on financial projections alone. Companies set their own scales and thresholds. There's no official pass mark you're required to use.

Examples of gate criteria

The classifications in the table are examples: each company decides which criteria are must-meet for its own projects. In most systems the criteria also get stricter as the project advances. At Gate 1, "we think there's a market" might be enough. By Gate 3, the gatekeepers should see real customer evidence and a financial case they can challenge line by line.

Stage-Gate Process Example: A Smart Thermostat for Small Offices

The stage descriptions above followed the thermostat through its work. This section looks at the same project from the gatekeepers' side: what they had to decide at each gate, and why. As before, the company and figures are invented for illustration.

Gate 1. The heads of product and engineering review the one-page idea. At this point they ask only two questions: does it fit the company's strategy, and does anything obviously rule it out? It fits, nothing rules it out, and the decision is Go, with two weeks and two people for scoping.

Gate 2. The scoping summary shows a gap between consumer devices and the company's expensive commercial systems, plus a technical head start from reused control boards. Decision: Go, with a budget for customer research.

Gate 3. This is the big one, because approving development means committing engineering time for most of a year. Finance and operations join the gatekeepers. The business case is narrower than the original idea, focused on offices that pay their own utilities, but the evidence for that segment is solid. The gatekeepers approve with one condition written into the decision: the unit cost target must be confirmed during development. Decision: Go.

Gate 4. The prototype works, but the cost condition isn't met: at the planned price, the margin falls below the company's minimum. The gatekeepers weigh their options. Killing the project seems premature, since the demand evidence hasn't changed. Approving it as is would mean ignoring a criterion they set themselves at Gate 3. They choose Recycle: six more weeks in development to redesign the unit with a cheaper display and a different wireless module, and to retest the price with customers.

The redesign brings costs close to target, and a small price increase tests acceptably. At the second Gate 4 review, the project passes. Decision: Go to testing.

Gate 5. The gatekeepers review the field test results, the final costs, the support plan, and the fix for the setup problem found during testing. Decision: Go to launch, starting with one region.

The Recycle at Gate 4 is where the process paid off. Because unit cost was a condition agreed in advance, the problem surfaced in a review meeting rather than after tooling was ordered and launch materials printed. The redesign took six additional weeks, but it allowed the team to address the margin problem before launch.

Benefits and Limitations of Stage-Gate for Complex Projects

Stage-Gate solves some real problems, especially in complex projects with big budgets and numerous stakeholders, and it creates a few of its own. Both sides are worth knowing before you adopt it.

What it does well

• Investment decisions get made with better information. Instead of approving the entire project up front, the company releases money in steps, and each step comes with new evidence. If customer interviews show the problem isn't painful enough to pay for, you find out before engineering starts, and poor projects drop out before they absorb a development budget.
• Problems surface earlier. Because each gate asks specific questions, weak spots are harder to hide. That is exactly how the thermostat's cost problem came to light at Gate 4.
• Accountability is clearer. Everyone knows who decides at each gate, what they're deciding, and on what basis. Recorded decisions also leave an audit trail. A formal review gives decision-makers a set moment to raise concerns before the team commits to the next stage, not after.
• Different functions work together earlier. Gate criteria cover marketing, technical, financial, and operational questions, so all of those groups have to be involved. Manufacturing learns about a new product at the business case stage, not two months before launch.

Where it causes trouble

• More meetings and paperwork. Every gate takes preparation time. If the templates are long and the meetings are frequent, a team can spend more time preparing for gates than doing the work. Cooper himself has said that criticism of outdated, rigid gating systems is often fair, and recommends that companies update their system every few years.
• Delays while waiting for decisions. If gatekeepers are busy executives, a finished stage can wait weeks for the next review slot, and across several gates those waits add up.
• A poor fit for fast-changing work. When customer needs shift monthly, as with many software products, a business case written in March may be outdated by June. Heavy up-front definition can lock a team into the wrong product.
• Decisions are only as good as the data. Gates structure decision making; they don't make the forecast accurate. If market research is thin or the financial model is built on optimistic assumptions, gatekeepers will approve weak projects with confidence. Stage-Gate doesn't guarantee project success. It makes it more likely that bad bets are spotted before they get expensive.

Stage-Gate vs Agile vs Waterfall

These three get compared a lot, but they don't answer the same question. Stage-Gate is mainly about investment decisions: which projects get funded, and when to stop. Agile is about how a team does the work, in short iterations with frequent feedback. Waterfall is about sequencing the work, finishing requirements, then design, then build, then test.

That's why a company can combine Stage-Gate with agile methodologies without contradiction. One governs whether the project continues. The other governs how the team builds things day to day.

Treat the table as a rough guide rather than a like-for-like comparison. Stage-Gate works at the level of investment decisions, while Agile and Waterfall describe how the work itself is organized, so the rows compare different layers of management.

Is Stage-Gate just Waterfall with meetings? Not quite. Waterfall assumes the plan is mostly right and focuses on executing it. Stage-Gate assumes the plan might be wrong and builds in points where the company can change course or stop. Cooper's descriptions also stress that work inside stages runs in parallel across functions and often loops back, rather than passing from one department to the next. In practice, though, a rigid Stage-Gate setup with heavy documents can feel a lot like Waterfall, which is one reason hybrids emerged.

Agile Stage-Gate as a hybrid approach

In an Agile-Stage-Gate hybrid, gates stay where they are and keep controlling investment, while work inside each stage, especially development and testing, runs in sprints. The team shows working prototypes to customers every few weeks instead of waiting for a formal test stage. Gatekeepers still decide whether to fund the next stage, but they see real progress and customer reactions rather than only documents.

Cooper and Anita Friis Sommer studied this model in physical-product companies starting around 2016. Their research describes manufacturers embedding sprints, stand-ups, and demos within existing gated processes. Firms reported faster response to change and better productivity, but also challenges such as management skepticism, the need for dedicated teams, and product definitions that keep moving. Their work also notes that manufacturers usually have to adapt Agile, since you can't ship a new version of a molded plastic part every two weeks.

How to Implement Stage-Gate in Your Organization

A common way to fail with Stage-Gate is to design a complete process on paper and roll it out to every project at once, only to find that teams start bypassing it because it slows them down. A safer approach is to start small and learn from one real project.

Pick a pilot project. Choose one new product project that matters but isn't the company's single biggest bet. It should be early enough that several gates are still ahead, and the team should be willing to try something new. A project that's nearly through development won't teach you much.

Define your stages. Start with the standard sequence and adjust it to how your company actually works. A food manufacturer might add a formal shelf-life testing step; a software company might merge development and testing into one stage. Write one short paragraph per stage: what it's for and what it should produce.

Name the gatekeepers. For each gate, decide who decides. They should be the people who control the resources for the next stage, and each gate should have a clear chair who calls the decision. A small group is usually easier to work with, as long as every function the project depends on is represented. If someone just wants to stay informed, send them the notes rather than adding them to the panel.

Set the criteria before the first gate. Write down the must-meet and should-meet criteria for each gate, and share them with the project team at the start of the stage, not the week before the review. Teams should know exactly what they will be judged on. Sharing criteria early also helps align stakeholders before the gate instead of during it.

Keep the deliverables minimal. For each gate, list the few documents or results the gatekeepers genuinely need. A business case gate might need a two-page summary, the customer research findings, a financial model, and a development plan. Ask of every template section: would a gatekeeper make a different decision without this? If not, cut it.

Run the first cycle and make real decisions. Hold the gates on schedule. When the evidence is weak, actually use Recycle or Kill. A pilot where every gate is an automatic Go teaches the organization that gates are ceremonies.

Review and adjust. After the pilot, ask the team and gatekeepers what helped and what was overhead. Fix the criteria, templates, and timing, then expand to a few more projects. Keep reviewing the process every few cycles: continuous improvement applies to your gates as much as to your products.

Why not start with the full system?

A heavy process imposed on every project at once creates resistance before anyone has seen it help. It also hard-codes guesses about what your gates need, made by people who haven't run a gate yet. A pilot gives you evidence about your own process, which is the same logic Stage-Gate applies to products.

A lighter gate process for smaller projects

Not every project needs five gates. Cooper has described scaled-down versions of the process, such as Stage-Gate XPress and Stage-Gate Lite, for projects with less risk; they typically have fewer stages and combine some gates. A minor product extension might go through just two or three gates: a quick idea check, a combined business case and development approval, and a launch decision. A startup or small team can run gates as a one-hour conversation with the founders and a single-page summary. What matters is that a real decision gets made, against criteria agreed in advance.

Common Stage-Gate Mistakes and How to Avoid Them

Most Stage-Gate problems don't come from the model itself. They come from how gates are run.

Gates become presentations with no real decision. The team presents, gatekeepers nod, and the meeting ends with "looks good, keep going." This happens when gatekeepers don't feel they own the outcome, or when killing a project feels like a personal attack on the team. The result is that every project passes and gates add delay without value. Fix it by requiring every gate to end with one of the four decisions recorded in writing, along with the resources committed. Treat an early kill as a good use of the process, not a failure by the team.

Criteria change right before the review. A new executive joins, or a gatekeeper suddenly cares about a market the team never researched. The team then arrives with the wrong evidence and gets recycled for reasons nobody could have predicted. Over time, teams stop trusting the process. Agree criteria at the start of each stage and treat them as fixed for that gate. If strategy genuinely changes, say so openly and give the team time to respond.

Funding continues after key assumptions failed. Customer interviews didn't confirm demand, but the project already has momentum, a prototype, and a sponsor who believes in it. So it passes "conditionally." This is how companies end up launching products nobody asked for. The fix is to name the critical assumptions explicitly in the business case and make their validation a must-meet criterion at the next gate.

Too many documents and too many approvers. A gate package grows to 60 pages and needs sign-off from nine people. Preparation takes weeks, and gatekeepers skim. Cap the package, for instance at a short summary plus supporting appendices, and keep the decision group small. Anyone else who needs to know can get the decision log.

Every project gets the same process. A packaging refresh and a new product platform go through identical five-gate reviews. Small projects drown in overhead, and teams start splitting work artificially to avoid gates. Define two or three process tracks by size and risk, and decide which track a project follows at the first gate.

Stage-Gate Checklist, Templates, and Product Development Software

Before any gate review, the project manager and the gate chair can run through this checklist. If several items are unchecked, it's often better to move the meeting than to hold a review that ends in an obvious Recycle.

• All deliverables agreed for this gate are complete and shared with gatekeepers early enough for them to read it.
• The key assumptions from the previous gate are listed, each marked as confirmed, disproved, or still open.
• Evidence for each must-meet criterion is clearly identified.
• The top risks are named, with an owner and a mitigation plan for each.
• The budget, people, and timeline requested for the next stage are spelled out.
• Gatekeepers are confirmed, available, and include someone authorized to commit those resources.
• The team knows which decision it is asking for, and what it would need to change for a different outcome.

Gate Review Scorecard

Use it as a simple stage gate process template and adapt the criteria and scale to your company. The weights and thresholds are yours to define; the model doesn't prescribe them.

Decision Log

One row per gate gives you a history of why the project moved forward, and makes it easy to check later whether conditions were met. The filled rows show how the thermostat's Gate 3 and Gate 4 decisions might be recorded.

Running gates in a spreadsheet or in software

A small team can run all of this from a shared folder: one document per gate, a spreadsheet for the scorecard, and meeting notes linked from the decision log. As the number of product development projects grows, many organizations move to project management or product development software that stores gate deliverables, shows which stage each project is in, and lets managers track progress across the portfolio. The biggest gain is an audit trail: anyone can see what was decided at each gate and on what evidence. Software won't fix weak criteria, though, so get the process working on paper first.

Making Stage-Gate Work

Stage-Gate is a simple idea: don't fund a product from start to finish on day one. Fund it in steps, and at each step look at what you've learned before deciding whether to go further.

The number of gates matters much less than what happens at them. A company with three well-run gates, clear criteria, and the willingness to stop a project that isn't working will get more from Stage-Gate than one with seven gates where everything passes. A useful gate review doesn't always end in approval. Sometimes the right decision is to revisit an assumption, delay investment, or stop a project before it becomes more expensive.

Sources

• Robert G. Cooper, The Stage-Gate Model: An Overview, Stage-Gate International: stages and their current names, gate structure, gatekeepers, Go/Kill/Hold/Recycle, readiness and value criteria, origin of the term
• Robert G. Cooper (1990), "Stage-Gate Systems: A New Tool for Managing New Products," Business Horizons 33(3): 44–54
• Stage-Gate: the origin, status quo and its future, interview with Robert G. Cooper, Five i's Innovation, December 2013: XPress and Lite versions, criticism of outdated systems
• Robert G. Cooper and Anita F. Sommer (2016), The Agile–Stage-Gate Hybrid Model: A Promising New Approach and a New Research Opportunity, Journal of Product Innovation Management 33(5): 513–526
• Robert G. Cooper (2016), Agile–Stage-Gate Hybrids, Research-Technology Management 59(1): 21–29
• Robert G. Cooper and Anita F. Sommer (2018), Agile–Stage-Gate for Manufacturers, Research-Technology Management 61(2): 17–26