Stage-gate process: How gates and stages drive NPD

For a VP Engineering already running some governance process, the real question isn't whether stage-gate exists, it's whether your gate criteria still have teeth. Here's how the stages, gates, and outputs actually work, and where the model fits against Agile.

What is the stage-gate process? (TL;DR)

Most new product development (NPD) projects don't fail in engineering. They fail because no one made a real go/kill call before the team spent budget building the wrong thing.

Robert G. Cooper's stage-gate process, also called a phase-gate process, divides development into distinct stages separated by gates, where cross-functional gatekeepers apply go/kill/hold decision criteria before releasing budget for the next phase. Cooper's benchmarking study analyzed over 90 factors in hundreds of corporate innovation projects.

The model runs from the fuzzy front end through launch, with the first full business case review sitting at gate 2, where kill decisions tend to cluster once real financial assumptions replace early estimates.

In our work with product teams running this process, we've tracked that same clustering pattern, and what breaks when engineering treats gates as rubber stamps instead of real checkpoints.

What follows maps the six stages, gate activities, and where a hybrid stage-gate-agile model fits teams running sprint-based development inside a gated portfolio management process.

Where the stage-gate model came from

Robert G. Cooper built the stage-gate process in the early 1980s by studying why so many R&D projects at industrial and technology firms failed after full funding. His research, backed by the PDMA, tracked hundreds of new-product projects and found that companies without a phased, disciplined process wasted budget on ideas that should have been killed months earlier.

Cooper's answer split the innovation project into distinct stages of activities, each separated by a checkpoint, or gate, where a cross-functional team reviewed evidence before releasing the next round of investment. That structure formalized what informal R&D management had done ad hoc for decades.

The original model targeted physical product development in manufacturing and industrial R&D settings. Software and digital teams later adapted the same gate logic to fit sprint-based work, which is where the hybrid stage-gate-agile model most engineering leaders run today came from.

The six stages, from discovery to launch

The stage-gate process breaks new product development (NPD) into six phases, each followed by a gate where cross-functional stakeholders make a go/kill/hold call before the next phase gets funded.

Discovery

The fuzzy front end starts here: unstructured idea generation, market scanning, and early technology assessment. Nothing is scoped yet.

Teams document a rough opportunity statement, not a business case, and gate 1 simply asks whether the idea deserves a scoping budget.

Scoping

The scoping stage is a short, cheap investigation, usually two to four weeks in our client engagements, covering market size, technical feasibility, and competitive positioning. It produces enough evidence for gatekeepers to decide whether a full business case is worth building.

Business case

This is where many projects stall. Gate 2, the business case review, forces a real financial model, resourcing plan, and product definition.

In our experience running stage-gate reviews across mid-market product organizations, more projects get killed at this gate than at any other stage, often because gate 1 was rubber-stamped instead of scrutinized.

That pattern makes sense: it is the first point where a team has to prove commercial value, not just technical promise.

Development

With a funded business case, the team moves into detailed design and build. Many organizations now run this stage as sprints inside a hybrid stage-gate-agile model, keeping the gate as a governance checkpoint while product innovation itself stays iterative.

Testing

Testing and validation covers field trials, pilot customers, and operational readiness, confirming the product performs as the business case promised before launch spend gets approved.

Launch

Gate 5 authorizes full commercialization: production ramp-up, go-to-market execution, and post-launch review criteria (Phase Gate - an overview (ScienceDirect)). Strong project governance has a measurable payoff: one industry analysis shows high-performing organizations complete 89% of projects successfully, compared with only 36% for low performers with weak governance (PMI, Pulse of the Profession 2014: The High Cost of Low Performance).

Each gate should carry weighted scorecard criteria, not a single up-down vote, so gatekeepers can compare projects competing for the same resources across all phases of the pipeline.

What happens at each gate

A gate review runs the same way regardless of which of the six stages precedes it: cross-functional gatekeepers convene, score the project against a scorecard, and issue a go/kill/hold decision criteria call before another dollar gets committed. Nobody advances on momentum alone.

The gatekeepers are not a single product leader signing off. Robert G. Cooper's original PDMA research specified representation from R&D, marketing, sales, operations, and finance at every gate, precisely so a project can't clear a checkpoint on engineering enthusiasm while the go-to-market case is thin.

Gatekeepers are cross-functional senior managers (heads of marketing, sales, technical, ops, finance) who own resources for each gate (Stage-Gate International, via Wellspring).

Each gate reviews a fixed output set: the project's business case, updated risk register, resource ask, and a scorecard with weighted criteria across strategic fit, market attractiveness, and technical feasibility. A project that clears gate 1 on a strong opportunity statement can still fail gate 3 if the prototype missed its adoption signal.

The kill decision is the mechanism gate reviews exist to protect. In our experience running phase-gate process reviews with product teams, kill decisions cluster hardest at the gate following business case review, once real cost and revenue assumptions replace early estimates.

Teams running a hybrid stage-gate-agile model keep this same go/kill/hold structure at the macro level while running sprints inside each stage. The gate still governs funding and scope; the sprint cadence governs execution. Treat a gate as a rubber stamp and the scorecard stops predicting anything, which is where kill-rate benchmarking becomes diagnostic rather than decorative.

Gate outputs: Inputs and criteria a review needs

A gate review needs three inputs to function: a completed outputs package, a weighted scorecard, and a business case review that survives challenge from every functional lens in the room. Skip any one of the three and the gate becomes a formality, not a checkpoint.

Gate outputs scale with stage. Gate 1 (scoping) needs a market sizing memo and a rough technical feasibility note. Gate 2 needs the full business case review: revenue model, cost-to-build estimate, competitive teardown, and a resourcing ask. Gate 3 needs a validated development plan with sprint-level milestones if the team runs a hybrid stage-gate-agile model.

Gate 4 needs test results against the original success criteria, not against a revised, softer target.

Our experience running this on client product portfolios is that gate 2, the business case review, is where kill decisions cluster. Projects that pass scoping on optimism alone tend to fail the financial model once real cost estimates replace placeholder numbers.

According to industry research, 44% of new-product projects fail to meet profit objectives; research indicates that ~1 in 10 concepts succeeds (Cooper, R.G. - The Stage-Gate Idea to Launch System).

Gatekeepers who wave a weak business case through gate 2 are usually the ones cancelling the same project, at higher sunk cost, by gate 4.

When to build stage-gate vs when to skip it

Stage-Gate earns its keep on capital-intensive projects, where a wrong go decision costs real money before anyone ships anything. Hardware, regulated medical devices, industrial equipment, anything with tooling costs or long lead-time procurement benefits from a gate that forces a business case review before capital moves.

It also earns its keep at the portfolio management layer. When a VP Engineering is choosing between fifteen candidate projects for four engineering teams, weighted gate criteria give the portfolio review a shared scoring model instead of a political argument.

Skip it, or run a lightweight variant, for low-cost digital features where the cost of building a wrong bet is a sprint, not a quarter. A four-person team shipping a new checkout flow does not need a five-gate phase-gate process; it needs a hypothesis, a two-week build, and real usage data.

Teams needing production AI shipped fast, without standing up a full internal team, can use a senior AI engineering pod to build, evaluate, and ship within weeks instead of a quarter-long gate cycle.

Our view: the differentiator is not Stage-Gate versus Agile methodology, it is matching gate weight to capital risk. Most mid-market teams run a hybrid model, phase-gate at the portfolio level, sprints inside each stage.

Stage-gate vs agile methodology: Which fits a software team?

For software teams shipping continuously, Agile methodology usually beats a rigid phase-gate process on cycle time, because sprint cadence absorbs requirement changes that a fixed gate review can't. Stage-Gate still wins when a software release carries capital risk large enough to need a formal go/kill/hold call. choosing between development approaches often comes down to how much requirement volatility and capital risk a given release carries.

Most engineering organizations we work with don't pick one model exclusively. They run a hybrid: Agile sprints inside each stage, with a lightweight gate at the boundary between stages instead of at every sprint. The gate review uses a weighted scorecard, market size, technical risk, dependency load, so cross-functional gatekeepers score consistently instead of debating from scratch each time.

Kill-rate benchmarking still matters in this model. Teams that track it typically see kills cluster at the gate following business case review, not at launch, which is the signal a gate is doing real work rather than rubber-stamping a project already in motion. 44.8% of top-performing companies successfully used an Agile-Stage-Gate hybrid model, per a Danish manufacturing-firm study (Cooper & Sommer).

Benefits, disadvantages, and where stage-gate fails

Stage-Gate earns its keep on R&D projects with real capital exposure: hardware, regulated products, anything where a wrong bet costs months of budget. The main benefit is discipline: a kill decision at gate two, after business case review, is cheaper than a kill decision at gate four, after tooling and vendor contracts are signed.

That discipline shows up in the data: organizations wasted 9.9% of every project dollar, $99 million for every $1 billion invested, on poor project performance in 2018 (PMI, Pulse of the Profession 2018).

The disadvantage is speed. A phase-gate process adds review overhead that a fast-moving digital product team often can't justify, and rigid gate criteria written for physical R&D fit software poorly.

According to PDMA, kill decisions cluster heavily at the second gate, right after the business case is scrutinized, later gates rarely kill anything because sunk cost and internal momentum take over.

That pattern only holds if gatekeepers actually exercise the kill option. In practice, the model breaks down when cross-functional gatekeepers stop treating gates as go/kill/hold checkpoints and start rubber-stamping whatever the team already built.

Once that happens, the process becomes a status meeting with a fancier name, and the stage-gate label stops meaning anything the portfolio can rely on for prioritization.

FAQ: Stage-gate process questions

Build your stage-gate process with Netguru

Most new product development (NPD) teams don't need a rigid stage-gate process bolted onto Agile sprints. They need gate checkpoints that respect sprint cadence while still forcing a real go/kill/hold call at each stage.

We build that hybrid model with product and engineering leads directly, sizing gate review scorecards to the project's risk profile rather than importing a generic template.

For teams that lack the bandwidth to run this hybrid model internally, extending your product team through staff augmentation can bring in the product and engineering expertise needed without a lengthy hiring cycle.

If your current process rubber-stamps every gate, or your teams treat stage transitions as a formality, talk to our team about a gate structure that fits how your team actually ships.