Cost of Delay

Origin & evolution

The concept was made rigorous by Don Reinertsen, whose 2009 book The Principles of Product Development Flow argued that most product organisations manage everything except the one variable that dominates economic outcomes🏆OutcomeStrategyA desired business or user outcomeView reference →: the cost of queues and delay. Reinertsen showed that teams routinely optimise for efficiency or utilisation while leaving Cost of Delay unquantified, and that this single blind spot explains a large share of poor prioritisation. His central claim is blunt: if you only quantify one thing, quantify Cost of Delay.

The idea has older roots in economics and lean manufacturing, where the cost of holding inventory and the cost of late delivery were long understood, but Reinertsen was the one who translated it into a usable product-development discipline. It later became the numerator of WSJF in the Scaled Agile Framework, which is how most practitioners first encounter it today.

How it works in practice

Cost of Delay is usually estimated from three contributing components, which are assessed for each candidate and then combined:

• User or business value: the value the item delivers once shipped, in revenue, retention, or strategic terms.
• Time criticality: how quickly that value decays. A feature⭐FeatureProduct SpecificationA product capability or featureView reference → tied to a regulatory deadline or a seasonal window has high time criticality; an evergreen improvement has low.
• Risk🎲RiskComplianceA risk to the product or businessView reference → reduction or opportunity🚪OpportunityDiscoveryA validated gap worth solvingView reference → enablement: the value of what the item unlocks or de-risks, even when its direct value is modest.

The output is a rate, typically expressed per week or per month. The more useful derived measure is CD3, Cost of Delay Divided by Duration, which ranks items by economic urgency relative to how long they take. CD3 is the same logic that WSJF formalises.

A worked example. A team weighs two initiatives🚀InitiativeStrategyA large coordinated effort to achieve a strategic goalView reference →. A payments integration is estimated to be worth about 10,000 per week once live, with high time criticality because a partner contract lapses at quarter end, giving it a Cost of Delay near the top of the list. A settings redesign is worth perhaps 2,000 per week with low time criticality, because nothing about its value erodes if it ships a month later. Even if the redesign is the smaller job🔨JobUserJob To Be Done: what the user is trying to accomplishView reference →, the payments work carries roughly five times the weekly cost of waiting, so delaying it is the more expensive choice. The number does not make the decision⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference →, but it makes the trade-off legible to everyone in the room.

When to use it (and when not)

Cost of Delay earns its keep when items genuinely differ in how their value decays over time, and when the organisation is willing to reason in economic terms. It is the right lens when deadlines, market windows, and dependencies⛓️DependencyTeam & OrganisationA cross-team or system dependencyView reference → are real and varied, and it is especially valuable for breaking deadlocks between a loud stakeholder🧑‍💼StakeholderTeam & OrganisationA person with influence over the productView reference → and a quiet but expensive opportunity.

It is weaker when every candidate has roughly flat, evergreen value, because then time criticality stops discriminating and the ranking flattens. The honest failure mode is false precision: a Cost of Delay figure is an estimate built on estimates, and treating it as a measured fact invites the same overconfidence it was meant to cure. Use it to surface and compare assumptions🤔AssumptionStrategyA belief taken as true that underpins a strategyView reference →, round generously, and revisit the figures as evidence🔎EvidenceValidationData supporting or refuting a hypothesisView reference → arrives.

In the Unified Product Graph

Cost of Delay is a prioritisation framework. The items it evaluates are feature⭐FeatureProduct SpecificationA product capability or featureView reference → and opportunity🚪OpportunityDiscoveryA validated gap worth solvingView reference → entities, scored on a shared set of inputs:

• User or business value maps to the value the item delivers, modelled against an outcome🏆OutcomeStrategyA desired business or user outcomeView reference → the work serves.
• Time criticality is a metric🔢MetricStrategyA unified metric that measures progress, health, or behaviour across the productView reference → input capturing how fast value decays.
• Risk reduction is a risk🎲RiskComplianceA risk to the product or businessView reference → input capturing what the item mitigates.

Because the same inputs feed both Cost of Delay and wsjf, a feature scored once can be sequenced by either method without re-scoring. Changing the prioritisation lens becomes a query, not a fresh workshop, which is the whole point of holding the scores on the entity rather than in a spreadsheet that dies after the meeting.