Adaptive innovation focuses on building and releasing new products in high levels of uncertainty, and optimizing resources as you go. Not just up front at the planning stage.
The following observations are based on my experience in a B2B software context, but I think it can be generalized to other types of new product development.
1. In practice, the full cost of time is dictated by sales and external market conditions. This is because you are nearly 100% certain not to make a sales forecast, if the relevant and sufficient scope for a customer does not exist yet. This holds regardless of your confidence in your sales forecasts and estimates.
2. Any planned internal costs will always be lower than cost of lost sales. They have to be over the longer term, otherwise you wouldn’t have a viable business.
3. You can use linear approximations as an adaptive method to quantitatively arrive at a current “cost of time” to help drive optimal decision making. This is done by comparing the effect on sales if the planned scope was available immediately vs if it exists on the estimated delivery date. Based on this you can derive a cost of time.You probably won’t have the luxury of directly observable continuous functions. In effect, you’re starting to think in terms of calculus and deltas, as opposed to solving for the absolute values in algebra.you move from “overall cost” to d (cost) / dt.
4. Costs and Revenues follow different probability distributions. and these distributions are skewed costs:
- inflexible especially in the case of legacy, large, or infrastructure
- relatively certain once agreed (near 100%)
- fixed in advance in accordance with high level strategy
- once agreed, they tend to stick around for a while due to the sunk cost fallacy
Revenues:
- Highly variable
- Depend on how well the immediately available scope matches to the customer problem
- Can make a big $ sale with a small incremental add of $ (in scope terms) — true even for a new product, there is a 20% of functionality that covers 80% of the value
5. The aggregate “work time” to build something large, e.g. infrastructure, will be unknowable up front, yet it is relatively fixed. The number of people you add is just a divisor. This fixed total will roughly correlate with the aggregate cash flows required to build something. Cash flow variation will come from who you hire, where you hire, and how desperate you are.
6. Elapsed time to build something large can vary enormously, based on how the work is chopped up and distributed. The business cost of this elapsed time is primarily by the business cost of time, not by the product development team’s pace and cumulative salaries.
7. The way in which the work can be distributed is significantly affected by the nature and structure of the work itself. For example, adding a fourth developer to work on a specific chunk of code will provide less output than adding the first one. They will step on each others’ toes and generally get frustrated. Best to have the developers self-organise based on the discovered architecture.
8. There is also natural organisational upper bound to adding people, as per the old software industry aphorism that “9 mothers are unable to deliver a baby in 1 month”.9. Onboarding new team members will vary based on both the quality of the people and the ability of your organisation to do so. From soft factors like cultural fit, to harder factors like the existence of accurate and up to date documentation, to the raw curiosity the person has in your business and product.
10. As useful as they are, numerical optimizations are only part of the whole picture. You still need to create teams, delegate work properly, and set healthy boundaries for accountability. The numbers don’t absolve you of good sense managerial practices.
There you have it. These form a baseline of the thought process required to truly optimize delivery of new products, particularly for established companies, using adaptive innovation.
Keep up with me by signing up over here for updates about my upcoming book on adaptive innovation.
Leave a Reply