In Innovation and Entrepreneurship, Peter Drucker discusses the various sources of innovation. One of them is technical knowledge, which is often the foundation of ventures set up by tech entrepreneurs. Drucker notes that science-based / technology-based innovation is loaded with extremely high risks. The window of opportunity is often very narrow and heavily congested, with large numbers of entrepreneurs and enterprises trying to exploit it. Under such circumstances, the cost of delay (COD) is particularly high. In simple words, it is a question of how much revenue you will lose by delaying the product market launch. How much will you need to lower the price if your competitor manages to enter the market before you do?
Paradoxically, even under such circumstances, many product developers act as though time was not money. When building their products, they see the revenue potential introduced by new features, the associated development expense and even – though much more rarely – the increasing cost of product support and maintenance. Hardly do they quantify and consider the loss they may incur due to being late with the product launch. If they did, they would be able to make much better decisions when managing their project scope.
Capturing COD in the project’s economic framework
Don Reinertsen @DReinertsen has offered a way to view the timeline within an financial framework, rather than just temporally, for product development projects. The figure below presents his framework that has been modified in a way to better match the context of web / mobile projects we develop with our clients at Selleo. It was adapted from Reinertsen’s The Principles of Product Development Flow.
By converting schedule / cycle time into cost of delay ($), you arrive at a common denominator for all the dimensions involved and are thus better equipped to make more fully-informed economic decisions. In product development you are very often confronted with trade-off decisions, i.e., you cannot optimize one dimension without affecting the others. To cite an example, a Product Owner decides to add a new feature (and thus increase the scope of the solution implemented) hoping it will allow them to capture more customers or charge a higher price for the product. In doing so, however, they simultaneously increase the development expense as well as the support and maintenance cost. More importantly, with a fixed capacity of the development team, they often postpone the launch of their product, which means they incur a cost of delay and increase the market and technology risks involved. As another example, Product Owners may be tempted to speed up feature implementation at the expense of QA measures, e.g. tests, refactoring, etc. In doing so, they:
- reduce the scope and the associated workload (in the short run),
- reduce the development expense (in the short run),
- significantly increase the support and maintenance cost,
- reduce the cost of delay,
- affect risks in multiple ways.
Should they do so? It depends. Their decisions should be made upon considering their overall impact on the product life-cycle profit. Since COD has an impact on the latter, it should be part of the equation. It was already in the early 80s that Reinertsen published an insightful article that first quantified the value of speed, indicating that a 6-month delay can deplete 33% of lifecycle profits. In The Principles of Product Development Flow, published in 2009, he maintains 85% of companies still do not quantify the impact of COD on their projects and he comes up with a bold suggestion: if you only quantify one thing, quantify the cost of delay.
What happens when the cost of delay is ignored?
Since schedule is usually expressed in time rather than monetary units, Product Owners may easily ignore the impact of COD on the economics of their projects. They may, for instance, increase their project scope AND lower / eliminate the product’s revenue potential. In practice, scope is often bloated – the products developed get loaded with a number of features which – from an economic point of view – should never have been implemented. Blindness to COD may very well be one of the main factors behind(https://en.wikipedia.org/wiki/Scope_creep)**[scope creep](https://en.wikipedia.org/wiki/Scope_creep)** – uncontrolled growth in a project’s scope. All in all, Product Owners often make decisions as though time was not money. Well, in fact, it IS.
What if you take COD into account?
You may choose to remain blissfully ignorant of what it costs you to delay the product launch and increase some of the risks described above. There is an alternative, though. Convert the timeline into monetary units and estimate – however roughly – what it may cost you per day / week to delay. Is it $100, $1000 or $10.000 per week? It will obviously be very project-specific. Next time you come up with an idea for a new feature to enhance your product, you will need to make sure the expected value exceeds a much higher cost hurdle which includes not only development expense and support/maintenance cost but also the cost of delay. When it is fed into the economic equation, you will find it much harder to justify any new features, which will in turn reduce the risk of scope creep on your project. If such a rigid economic approach was applied to manage the product backlog, many features would not pass the cost-benefit test. Scope creep could be more effectively constrained.
A note on the fully loaded cost
To make matters worse, the note and the figure above do not capture the whole intricacy of costs encountered in product development projects. It is often assumed that development and support/maintenance costs increase linearly as new features are added to the system. The assumption is very often false. Each feature added to the system introduces more complexity. Complexity has got its own cost, and it is exponential rather than linear in nature. Each feature added, makes it harder and more expensive to develop and integrate subsequent features and maintain the whole system. In other words, the cost of adding one and the same feature varies depending on when it is added. Viewed from a different perspective, given a fixed development velocity, you will implement ever smaller portions of scope as you progress through the iterations. Consequently, cost estimates should be adjusted for complexity if we are to make optimal economic decisions. It is only when we are sure that the fully loaded cost exceeds the expected value that we should allow a new feature to enter the project scope. Taking the above into account, it is only too reasonable to implement high-value features first and thus avoid littering the system with trivia which may block the way for important enhancements later on in the development process. With COD quantified in the economic equation, you are much more likely to reduce the complexity of the system developed and thus lower the associated complexity costs.
A note on risks
A careful look at the diagram in Figure 1, offers another insight. When you delay the product launch in a competitive environment – for instance, in the market type with a first-mover advantage, you significantly increase the market risk of a competitor preempting the market space before you launch your solution. With delayed feedback, you are at least less likely to detect and respond to changes in customer preferences and risk no / poor product market fit. In both cases, you decrease the likelihood of ever materialising the expected revenue. You may also unnecessarily expose your product to technological risks, e.g. changes in the underlying technology. Again being fully aware of COD and accounting for it in your decisions on project scope may help reduce such risks.
All in all, if you are a tech entrepreneur, as Drucker pointed out – your window of opportunity may be very narrow and congested. Be fully aware of the cost of delay on your project, quantify it and treat it as an important factor to consider when managing your product scope. It is yet another constraint to manage. Still it may be an eye-opener with a potential to help you build a better solution and a viable business venture.
Paradoxically, if you enter the market too early, the cost of delay can actually be positive, i.e., it can have a positive impact on revenue. In such cases though, it may simply be reasonable to wait rather than implement a product the market is not ready for.