Cost of Delay: Quantifying the Price of Waiting

The mental model

Cost of Delay flips the script on project planning. Instead of asking "How much will this cost to build?", it asks "How much does it cost us for every week this isn't live?". It's a way to quantify the economic impact of time, making urgency tangible. It combines the expected value of a feature with how that value changes or "leaks" over time, giving you a single metric to guide prioritization. Formally, it is the partial derivative of total expected value with respect to time.

How it works

To calculate the Cost of Delay, you estimate the value a project will deliver over a period, like weekly revenue or cost savings. If a new feature is projected to generate 10,000 per week, then the Cost of Delay is 10,000 per week. This simple number represents the money you're leaving on the table for every week you wait to ship. The process forces critical conversations about what "value" truly means for your business—is it new revenue, increased user retention, operational cost savings, or mitigating a critical risk?

When to use it

Use Cost of Delay to break decision-making gridlock when prioritizing large initiatives, epics, or features. It is especially powerful for comparing different types of projects, such as a revenue-generating feature versus a cost-saving infrastructure upgrade. By translating everything into a common unit (value lost per unit of time), you can make more rational, data-informed choices about what to work on next. It's a foundational concept in prioritization frameworks like Weighted Shortest Job First (WSJF).

When not to use it

The model's effectiveness depends on the quality of your value estimates. If your projections are pure guesswork, the resulting priorities will be equally unreliable (garbage in, garbage out). It can be overkill for small, self-contained tasks with obvious priority or for teams with a strong, intuitive alignment on what's important. It's not helpful for work with no clear, quantifiable time-sensitive value, like minor documentation updates.

One canonical example

Imagine two projects. Project A is a new checkout flow estimated to increase conversion and generate 20,000/week in extra revenue. Its value is constant. Project B is a feature tied to a major industry conference in 12 weeks; it's expected to generate 500,000 in leads if launched before the event, but almost nothing after. Project B's Cost of Delay is roughly 500,000 / 12 weeks = ~42,000/week. Even though Project A provides steady value, the time-critical nature of Project B gives it a much higher Cost of Delay. This calculation makes it clear that prioritizing Project B is the correct economic decision.