Reinertsen spends a lot of time in his books talking about calculating the cost of delay. He does this for two reasons:
- First, he rightly argues that decision-making in product development should be based in economics.
- Second, nearly every action in development requires time, so understanding the cost of a day/week/month is highly relevant to all decisions.
To give a 1-minute elaboration on each of those points, I’ll mention that the first one should just make sense. Adding a feature to a product or improving a design or spending money to do more testing – these things are only worth doing if they cost less than the benefit they provide. An action has negative value if it changes nothing for your product’s profitability but costs you time and money.
And to the second point, time is perhaps the most valuable resource you have in product development. Anyone who has waited until the last minute knows this. If you’ve ever said “I would pay $1,000 for one more day to work on this,” then you are speaking Reinertsen’s language. Being able to make good decisions in development comes from knowing the actual cost of delaying your product.
The major complaint about approximating the cost of delay: “It’s not accurate.” “It’s a guess.”
To those complaints, Reinersten says this: ““Some companies worry that imperfect economic frameworks will lead workers to make bad decisions. They act as if the absence of these frameworks will magically protect them from bad decisions.”
In other words, yes, the estimate you come up with for the cost of delay will be imperfect. But would you rather have an imperfect tool or no tool at all? A broken shovel is still better for digging than your bare hands. Having no tool does not magically innoculate you from making bad decisions.
All models are wrong. We know this. But some are still useful.