October 19, 2026
What Is Cost of Delay? The Hidden Cost of Slow Product Decisions
Cost of delay is the value you lose for every week a feature sits unbuilt. Learn the formula, the three components and how to prioritize with it.
TL;DR
Cost of delay is the value you lose per unit of time while a decision, a feature or a fix waits. Estimate it as value per week times the weeks of delay, split into value, urgency decay and risk, then divide by job size for a WSJF score. Teams that rank this way ship the expensive-to-wait items first, not the loudest request.
Author: Inputly
What is cost of delay?
Cost of delay is the economic value lost for every unit of time a decision, a feature or a fix is postponed. It is not the cost of building the thing, it is the cost of not having it yet. If a checkout fix would recover 4,000 dollars a week, its cost of delay is 4,000 dollars a week, and a six week queue burns 24,000 dollars before anyone writes code. The idea comes from lean product development, where Donald Reinertsen showed that queues, not engineering hours, are where value leaks out. That reframe changes the question: not what is cheapest to build, but what is most expensive to wait for.
TL;DR: Value lost per week times weeks of delay is your cost of delay. Split it into value, urgency decay and risk, divide by job size for a WSJF score, and rank on that. Prioritization becomes a conversation about money per week.
Why is waiting usually more expensive than building?
Building costs are visible: engineers, design weeks, QA cycles. Waiting costs are invisible: churn nobody reports, support tickets about a known gap, and deals that stall on a missing integration. A feature that lands a quarter late arrives after the people who asked for it stopped asking, which is how a backlog fills with items that matter less every month.
How do you calculate cost of delay?
Start with three components, often called CD3, and keep the estimates rough on purpose:
| Component | Question it answers | Example | | --- | --- | --- | | Value | What does one week of the outcome earn or save? | 4,000 dollars of revenue per week | | Urgency decay | How fast does that value shrink? | Seasonal window closes in eight weeks | | Risk | What does waiting expose you to? | Contract penalty or compliance date |
Multiply value by urgency and risk for a weekly figure, then multiply by the weeks the item will sit in the queue. Express everything per week so different sizes compare, and note the source of each input, because a number nobody can trace is a confident guess.
How does cost of delay become a ranking?
Divide cost of delay by job size and you get weighted shortest job first, or WSJF. An item worth 10,000 dollars a week that takes two weeks beats one worth 12,000 dollars a week that takes a quarter. WSJF rewards small work that stops a large leak, so it pairs well with the effort scores inside RICE. It complements scope methods: MoSCoW decides what fits a fixed release, cost of delay decides which release the item belongs in. Run both and prioritizing feature requests stops being a quarterly argument.
What mistakes make the estimate useless?
- Treating the number as precise. It is an order-of-magnitude signal, so three digits invite arguments nobody wins.
- Ignoring decay. Score urgency once a quarter and a deadline expiring next month looks distant.
- Scoring everything. Twenty high scores means the model failed, so reserve it for items you are choosing between.
How does customer feedback feed the estimate?
Feedback supplies the value inputs. Feature voting shows which items keep resurfacing and for how many accounts, and win loss analysis prices the deals lost on a gap. A churn survey turns a leaving customer into a number, and feature adoption data shows whether what you shipped is earning what you assumed. One warning: a loud request is not an expensive delay, so weight by segment and revenue, otherwise the ranking measures who has the most time to comment.
When should you not use cost of delay?
Skip it when work is small, reversible and undated, since the estimate costs more than the insight. Skip it for legal, security or safety obligations, since no weekly figure survives an audit. And do not make it the only lens on the roadmap you publish: platform health and technical debt rarely produce a clean weekly number, yet they cap everything else. Use it where a real trade off exists. Once a ranking exists, communicating it turns arithmetic into trust.
Frequently Asked Questions
- Is cost of delay the same as opportunity cost? They are close cousins. Opportunity cost asks what else the capacity could have done, cost of delay asks what value disappears per week of waiting.
- How do you estimate urgency decay? Ask what changes if the item ships eight weeks later: a season ending, a renewal, a competitor launch. If nothing changes, decay is low.
- What is a good WSJF score? There is no absolute scale, only a relative one. Scores mean something inside a single comparison set.
- Does it work for small teams? Yes, and most of all there. With the least slack, a week on the wrong item hurts more.
- How often should you recalculate? Whenever a deadline moves or a segment changes. Quarterly is a fair default, plus a rerun when an item sits longer than planned.
Waiting is a decision with a price tag. Create a free board on Inputly to rank requests by real demand, then put a weekly number next to each one.