Walk into almost any delivery organisation and ask where the effort goes, and the honest answer is the same: Build. Engineers are building, managers are tracking how much is being built, and the roadmap is a queue of things waiting to be built. The lifecycle, on paper, has nine stages — Vision, Discovery, Validation, Architecture, Planning, Build, Release, Operate, Evolve — but in practice eight of them are treated as ceremony on the way to the one that feels like real work. That instinct is wrong, and the evidence against it is now stronger than the folklore that props it up.
Start with the awkward number. The Standish Group's enterprise-application research found that only around 7% of features are 'always' used and 13% 'often', leaving roughly 64% 'rarely' or 'never' touched. That figure deserves caveats — the original sample was four internal applications, and Mike Cohn's careful re-examination of it is worth reading before anyone quotes it as gospel. A separate, larger triangulation from Pendo (vendor framing — this is product-analytics data analysing 615 subscriptions, so treat it as directional rather than definitive) put the rarely-or-never figure nearer 80%. The exact percentage is contestable. The direction is not: a large fraction of what teams build is waste, and you cannot out-build your way past that. Over-indexing on Build is, mechanically, over-indexing on the part of the lifecycle most likely to produce things nobody wants.
The bottleneck has not moved in twenty years
If raw build throughput were the constraint, two decades of better tooling, faster machines and now AI assistance should have shifted the outcomes. They have not. Standish's CHAOS data shows roughly 29% of projects fully succeed on time, scope and budget and around 48% are 'challenged', a trend essentially flat across twenty years. We have made building faster and delivery no more successful. The implication is uncomfortable for anyone whose dashboard measures lines, commits or story points: the limiting factor sits upstream and downstream of Build, in the stages teams skimp on.
DORA's 2024 Accelerate State of DevOps Report — a Google Cloud research programme drawing on around 39,000 professionals — sharpened the point in the AI era. It found AI adoption lifted individual productivity and flow but actually had a negative effect on software delivery throughput and stability. The fundamentals, small batch sizes among them, still governed outcomes. The same report found that organisations prioritising end-user experience built higher-quality products, while unstable organisational priorities drove persistent productivity drops and burnout that strong leaders and good documentation could not offset. Read that twice: the damage from skipping Vision and Discovery is not recoverable downstream by heroics. It compounds.
Why the early stages actually matter
The usual defence of front-loading is the cost-to-fix cliché — that a defect caught in requirements costs a fraction of one caught in production. It is worth being precise here, because the cliché is shakier than most architects assume. A peer-reviewed empirical study by Menzies and colleagues, testing the 'delayed issue effect' across 171 projects between 2006 and 2014, found no consistent evidence that defects cost substantially more to fix later. That does not vindicate skipping Discovery; it reframes why the early stages earn their keep. Their value is not defect-cost avoidance. It is decision quality — deciding to build the right thing, and deciding how, before the cost of being wrong is locked into committed code and customer expectations. Vision, Discovery, Validation and Architecture are where the expensive decisions get made cheaply. This is the same argument that runs through our work on architecture as decision-making rather than diagram production, and it generalises across the whole lifecycle.
Marty Cagan of the Silicon Valley Product Group puts the discovery case in operational terms in 'Transformed' (2024): product discovery should test ideas ten to a hundred times faster than building them, and teams must be accountable for outcomes rather than output. The outcomes-over-output framing is Cagan's, and it is the cleanest articulation of why Validation precedes Build — you are buying down risk at a fraction of the cost of buying it down in code.
Building faster has never been the same thing as delivering better. The teams that ship value treat Build as the cheap, reversible part — and spend their scarcest attention on deciding what is worth building and what happens after it ships.
Planning, Release and the back half of the lifecycle
The standards world has long modelled the full span. ISO/IEC/IEEE 12207 defines life-cycle processes across acquisition, development, operation, maintenance and disposal; the 2017 edition is current, with a revision under way to align with Agile, DevOps and cloud-native practice. The point of citing a standard here is not to recommend ceremony — it is to note that Operate and Evolve are first-class stages in every serious model, not an afterthought once Build 'finishes'. Build never finishes. Software that matters spends most of its life being operated and evolved.
On Release specifically, the most useful field signal comes with a label attached. Thoughtworks' Technology Radar (vendor framing — this is a consultancy's self-observation of its own engagements) places continuous deployment, 1% canary releases and component testing in 'Adopt', and warns that mandated pull requests can disrupt flow and undermine genuine continuous integration. Treat it as a hypothesis worth testing in your context rather than a verdict, but the underlying mechanic is sound: small, reversible releases turn deployment from an event into a non-event, which is precisely what shifts effort away from heroic Build-and-ship cycles.
McKinsey's research on the product operating model closes the loop with analyst evidence: among five core areas, 'ways of working' showed the strongest correlation with business performance, and time-to-market emerged as the IT-productivity metric that mattered most. Time-to-market is a flow measure spanning the whole lifecycle — Discovery through Operate — not a build-volume measure. Optimise the flow and Build stops being the thing you stare at.
What to do with this
The practical correction is not to add stages or governance gates. It is to redistribute attention. Spend more on Vision and Discovery so you build fewer wrong things. Make Validation cheap and fast, in Cagan's ten-to-a-hundred-times spirit, so being wrong costs days not quarters. Treat Architecture as decision-making, capturing the reasoning so later evolution is informed rather than archaeological. Make Release boring through small, reversible increments. And resource Operate and Evolve as the stages where software actually earns its return, not as warranty work. The teams that get this right are usually the ones that have rethought how delivery itself is organised — the connection between team design and delivery outcomes is its own subject, but it starts with refusing to treat Build as the whole job.
If your delivery metrics today count output, you are measuring the one stage least correlated with success. Shift the measurement to flow and outcomes, and the lifecycle rebalances itself. That is the difference between a team that builds a great deal and a team that delivers.