Managing Spend Rate, Not Cost
Traditional business finance teaches us to treat an enterprise as a steady state system, and to consider projects as investments that change that system.
The problem is, today’s enterprises are not in a steady state—not even close. The world around us is changing too fast. The steady state approach causes us to be too lethargic when we need to be agile. We need to treat an enterprise as a continuously evolving system.
Traditional project-based funding is managed by preparing a proposal with a projected return on investment (ROI). The proposal is expected to be as detailed as possible, with market analysis and empirical data. That’s too slow today for most things. If you are building something really big that cannot be done incrementally, like a bridge or a highway, then the traditional approach is probably best. But for routine investments that product companies make, that approach is too slow and has too much overhead. Today’s organizations need to make best guesses and be ready to learn and pivot rapidly based on outcomes. There is no time for deep research and making detailed up front plans that will likely not work out as planned anyway.
A far more agile financing approach is a “Lean” approach that treats an investment as ongoing instead of having a fixed duration. Once you invest in something, assume that it will continue to require investment, so that it can keep tracking the market, learning, adjusting, and staying ahead of competitors. The application of funds is managed tactically, instead of locked down in an annual plan. What you manage instead is a spend rate.
As shown in the chart below, an investment begins ① with a decision to pursue a proposed Lean business case—perhaps a one-pager that summarizes the hypothesis about what the market wants, how the need will be met, how that will be executed at a high level, and what it will likely cost as a best-effort guess.
This initial cost estimate is usually a fixed number, not a spend rate, because its purpose is to validate a hypothesis. But the cost estimate is very approximate: there is no illusion that it is accurate.
If the prototype validates the hypothesis—in other words, early trial users like the product—then a minimal version of the “real” product is built ②, to get the minimum viable version of the product to the market. The funding for this is a spend rate, because the assumption is that the product will continue to evolve and that more features will be added so that market share can be grown. Much of the funding is for marketing, and the rest is for development and operation. The cost division between development and operations is not separated, but rather it is managed tactically.
At some point profitability is expected ③. If profitability is not achieved within the time period that is considered within the risk tolerance of the organization, then funding might be cancelled; but if profitability is achieved, then funding is sustained, allowing the product to continue to evolve and to grow market share.
Inevitably circumstances change ④⑤, either because other investment opportunities arise, or changes in the market alter the optimal mix of investment resources. Eventually, the value generated by the product is shown to no longer be worth the continued investment stream, and the product is sunset ⑥.
People who are accustomed to managing in the traditional project-based manner will wonder how does one budget in a Lean approach? After all, one needs to determine if a task has been completed, and if so, how much did it cost? That’s the only way to make sure that total spend does not exceed a budgeted amount.
But that’s not how the Lean approach works. One does not assign a cost to a task. There is no budget for completing a product. There is only an investment stream, with a series of planned milestones. Early milestones are designed to verify that the investment is worthwhile: if it is not, then funding stops; but if the investment is generating value, or what looks like a strong likelihood of eventual value (in other words, positive expected value), then investment continues.
There is never a need to tally sunk costs and compare them with promised costs: there is only a continuing evaluation of whether the current investment rate is worthwhile compared to the value that is being generated.
Projecting Cost
You might wonder, if one does not assign a cost to each task, then how can one predict a cost for an entire project?
You don’t. This method is not suitable for fixed-price one-and-done initiatives. It is suitable for initiatives that live on, which is much more typical of products today.
Still, when launching a product initiative, one needs to predict costs. Otherwise, one will never get funding. However, instead of predicting a total cost, one predicts when a milestone can be achieved, and what spend rate is likely to be needed to achieve it by then. It is then merely a matter of arithmetic to compute an estimated total for reaching the milestone.
It must be clear that the prediction is only a guess: things rarely go as planned when doing something that one has never done before, and developing a new product is just that: if the product had been created before, then why would you create it again? By definition, new products and new product features are unique, and so one cannot predict the cost with any certainty.