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. Studies of high growth Inc 500 startups have confirmed that firms adapting to market needs achieve growth more frequently, compared to companies sticking to an original vision and plan. Established companies looking to innovate, would be wise to allow for such flexibility as they expand their product portfolio. Corporate innovation shares the same market context with startups when launching new products.
Diving deeper into why high growth startups were successful will help increase the chances of succeeding as innovators. In contrast to startups, larger firms have access to much greater resources, although they struggle with the complexity this causes. Moreover, their starting point is often one of being cost efficient. This can lead to challenges in the early stage. Evolving products requires multiple rounds of financing, in order to minimize risk rather than using traditional budgeting to help new products succeed.
The following observations are based on my innovation experience in a B2B software context. While this is a very particular type of environment, with high technology and quality constraints but no manufacturing costs, the principles can be cross-pollinated into other environments. Also it’s worth noting that software has the ability to be packaged as products (MS Office) or as services (Google Suite). In short, the model and its insights can be applied 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