Cost of Delay

Prioritization spent years missing one axis: time. Teams argued hard about how valuable something was and how much effort it would take, and scoring methods like RICE captured both of those, but nobody put a number on the act of waiting. Postponing looked free.

So the meeting always had the same shape. Twelve candidates on a list, someone walking down it item by item, one person saying "that one matters" and another saying "can't that wait until next quarter?" Neither side had evidence, so the item usually landed wherever the loudest or most senior voice pointed. Three months later, pulling the deferred items back out, some of them had gone stale — a competitor shipped the same thing first, and building it now bought nothing.

Cost of delay puts a number on that missing axis, and it does it by changing the question. Instead of asking how valuable a piece of work is, it asks what a month of waiting costs. The two questions rank candidates differently. Some work is worth a lot and loses nothing by sitting in the queue for a quarter. Other work is worth a moderate amount and evaporates if this particular month goes by. Score only for value and those two look identical.

Add up the money that disappears for each month the work is late. The measurement is the gap between finishing now and finishing a month from now — not the total revenue the feature will ever produce.

Three buckets usually cover it.

1. Revenue you don't collect. Deals that stall because the feature is missing, or subscription payments that simply arrive later. If 300 accounts at $7 a month are stuck before checkout because of this one gap, that's $2,100 a month of monthly recurring revenue (MRR) — the revenue that repeats every month — sitting on the other side of the work.
2. Costs that keep running. Work a person still does by hand because nothing automates it, or support time that a known defect generates every month. If one person spends 40 hours a month on it, that payroll is the cost of delay.
3. Windows that close. Value that vanishes entirely if the timing slips. A year-end reporting feature that misses December is worth zero until the following December.

Keep the time unit identical across every candidate. Score one item monthly and another annually, then put them in the same table, and the ranking inverts for no real reason. Pick one unit per team and write everything in it. Monthly is the common choice.

The finished number is not the ranking. Suppose one candidate loses $3,800 a month and another loses $3,000 a month, but the first takes four months to build and the second takes two weeks. Clearing the short one first loses less money overall. That's why Weighted Shortest Job First (WSJF) exists — it divides cost of delay by job size. Cost of delay is the numerator in that division.

What matters is whether the candidates separated, not whether each figure is correct. If one item comes in at $6,000 a month and another at $450, the order holds even if the true values were $5,500 and $600. A gap of that size is enough. The opposite case is the problem: when every number lands around $2,300 a month, the table can't rank anything. Rather than estimating more carefully, break the candidates into smaller pieces. Large chunks pull their estimates toward the middle.

The comparison also breaks when the estimating method shifts between rows. If one item is grounded in two signed contracts and the next is a guess, the grounded one gets scored conservatively and sinks, which has nothing to do with its actual urgency. Someone swapping rulers between measurements gets the same result. So the numbers are set in a room rather than by one person — the team pulls candidates from the product backlog, the ordered list of everything waiting to be built, and product, engineering and sales score them together.

Numbers also age. The month a competitor ships the same capability, an item that was worth $6,000 a month drops to $750. Re-walk the table each quarter and retire the rows that collapsed. A team carrying six-month-old estimates is sequencing its work against a six-month-old market.

"Cost of delay on this is $6,000 a month. Pushing it to next quarter is an $18,000 decision."

Attaching a price tag to the proposal to postpone.

"The cost of delay is high but so is the size, so it never surfaces. Can we split it?"

Suggesting shipping the front half now instead of waiting for the whole thing.

"Nothing is lost by doing that later, so I scored its cost of delay at zero."

It can move to the back of the queue without anyone paying for the wait.

At Pagedeck the week before quarterly planning goes to filling in these numbers. Mia puts the candidate list on screen, Sofia flags the items tied to open deals, and Theo answers how many hours a month the team currently spends patching something by hand. Once the column is full, the table gets re-sorted, and every quarter one or two items change places. Something everyone assumed was obviously next turns out to be work that could happen any time at all.

Grace tends to add the same comment: this table decides what to postpone, not what to build. Writing the monthly figure next to each deferred item means next quarter's discussion starts from the record instead of from scratch.

The most common mistake is treating the figure as something that has to be right. It's written in currency, so it reads like an accounting number, and people who can't defend a precise value stop filling in the cell at all. The number only ever decides an order. It needs separation between candidates, not accuracy. A team that holds out for precision ends up with an empty table, and an empty table means the loudest voice picks the order again.

The mistake also runs the other way: reading a large cost of delay as an instruction to start immediately. Bigger looks more urgent, which is an easy assumption to make. But the figure isn't a ranking until job size enters the picture. Start a six-month item losing $3,800 a month ahead of a two-week item losing $2,300 a month, and the shorter one sits untouched for half a year while $13,800 leaks out. Divide by size and it becomes an order.