The Product Delivery Lifecycle is our model for where delivery effort should go — as opposed to where it actually goes. Most teams run a lifecycle with one fat stage in the middle and eight thin ones either side of it: everything is in service of Build. The model corrects that by making the lifecycle explicit and putting an acceptance gate at every stage, so that progress is earned by evidence rather than by elapsed time or committed code.
The case for rebalancing is not ideological. McKinsey's Operating Model Index — a survey of 757 senior executives in April–May 2024 — found that organisations with high product-operating-model maturity post 60% higher total returns to shareholders and 16% higher operating margins than bottom-half performers. The same body of work notes that even top performers capture only around 70% of their strategy's full potential, and that the shortfall sits in the operating model, not the build. How you run the lifecycle, not how much you build, is the binding constraint.
The nine stages
- Vision — name the outcome and who it is for; the gate is a falsifiable problem statement, not a feature wish-list.
- Discovery — learn what is actually true about the user and the problem; the gate is evidence, not opinion, that the problem is worth solving.
- Validation — test the riskiest assumptions cheaply before committing code; the gate is a result, because most ideas fail.
- Architecture — make the decisions whose cost-of-change is high while you still can; the gate is a defended, recorded decision, not a diagram.
- Planning — sequence the work and the bets; the gate is small, reversible batches with a clear first slice of value.
- Build — produce the change; the gate is correctness and intent-fit, not volume.
- Release — get it into users' hands; the gate is a safe, reversible deployment, ideally a non-event.
- Operate — run it in production; the gate is observed behaviour and reliability against the Vision's outcome.
- Evolve — change it as you learn; the gate is evidence that each change moves the metric, retiring what does not.
Why most teams over-index on Build
The failure mode has a name. The 'feature factory' is the team that measures success by the quantity of features shipped — story points, velocity, releases — rather than the value delivered. It feels productive because Build is the stage that looks like work. But the evidence on what gets built is sobering. Microsoft's experimentation team, Ron Kohavi and Stefan Thomke, report that roughly a third of tested ideas produce positive results, a third produce none, and a third actively harm the metric they target; across firms it is common for 70–90% of ideas to have no impact or move things the wrong way. If most ideas fail, then the cheapest place to find that out is Validation — and the most expensive place is production. Building faster only ships the failures sooner.
AI sharpens the warning. The 2024 DORA State of DevOps research associated a 25% increase in AI adoption with an estimated 1.5% fall in delivery throughput and a 7.2% fall in stability, and added rework rate as a stability factor. In the same period the high-performance cluster shrank from 31% to 22% of respondents while the low cluster grew. Faster generation did not buy better delivery, because delivery performance is an organisational and decision property — psychological safety was among the strongest predictors — not a tooling one. Accelerating Build without strengthening the gates around it makes the lifecycle worse, not better.
A lifecycle is not a conveyor belt with one busy station. It is a sequence of decisions, each of which can be wrong — and a gate is simply the cheapest place to find out before the next decision makes the last one expensive to reverse.
How the acceptance gates work
Each gate asks the same question in stage-specific terms: what is the evidence that this stage is done well enough to spend the next stage's money? The discipline is consistent with the wider product literature. Marty Cagan's 'Transformed' (SVPG, 2024) argues that empowered teams must be given problems to solve and held to results — outcomes over output — which is precisely what the Vision and Operate gates enforce. Teresa Torres' continuous-discovery framing separates the decision work of determining what to build from the work of building it, with weekly customer touchpoints; that is why Discovery and Validation are recurring gates, not a single up-front phase you pass once.
The Architecture gate deserves a specific rule. Lean practice — decide as late as possible — says you defer irreversible choices until evidence exists, which is exactly why Architecture sits after Validation but before heavy Build: you make the high cost-of-change decisions (tech stack, data models, auth) on evidence, while keeping the reversible ones (tooling, internals, naming) cheap and open. Evolutionary-architecture practice makes this measurable through 'architectural change cases', which expose hidden assumptions and t-shirt-size the cost of change — turning the gate from a gut call into a recorded criterion.
Keep the gates light
The obvious risk is that gates become a phase-gate bureaucracy. Critiques of classic Stage-Gate are fair: rigidity drives schedule and budget overruns, late feedback forces costly rework, and gates degenerate into 'creativity-numbing rework loops'. Robert Cooper, who originated Stage-Gate, has since moved practitioner consensus towards hybrid Agile-Stage-Gate models that keep cross-functional governance and templated evidence while regaining iterative responsiveness. That is the design intent here: an acceptance gate is a lightweight evidence check owned by the team, not an approval committee. The named-stage lifecycle is established — Pendo, for instance, frames Discovery → Validation → Build → Launch → Iteration with per-phase metrics — so the differentiator is not the stages. It is putting an honest gate on every one of them, and resourcing the eight stages that are not Build.
Used well, the lifecycle redistributes attention rather than adding ceremony. Spend more on Vision, Discovery and Validation so you build fewer wrong things; treat Architecture as recorded decision-making; make Release boring; and fund Operate and Evolve as where software earns its return. If your gate criteria measure output, you are policing the one stage least correlated with success — the same trap the acceptance gap describes once generation becomes cheap. For the narrative version of this model and the evidence behind each stage, read our companion piece, From Idea to Production.