Although radical innovation will still be separate from traditional development, all innovation affecting existing products and platforms should be integrated into the development process, argues Jan Bosch.
Few words are as overused and misused in product companies as the word “innovation.” In most contexts, it means something along the lines of new and good. It’s new because we didn’t have it before we developed it and it’s good because it wouldn’t be innovation otherwise. Few people are interested in discussing innovation that didn’t land with customers. In my view, this is fair as my favorite definition of innovation is “invention + monetization.” Something new that you can’t monetize is no innovation.
It’s my experience that most software-intensive systems companies tend to focus on innovation that’s technology-driven rather than customer-driven. Some new technology is becoming available and this technology needs to be explored and driven upwards along the technology readiness levels. Once it has proven itself and has been integrated into our product portfolio, voila, we have innovation.
The challenge with this technology-driven approach is that most players in an industry typically get access to the new technology at about the same time. Then, the situation often becomes more of a Red Queen of Alice in Wonderland approach: running as fast as possible just to stay in the same place. So, although companies invest vast amounts of resources into incorporating new technologies into their products, the result mostly is maintained market share, rather than growth or new revenue sources.
As the new technologies typically require new skills from the engineers working with them, it’s typical that a separate team or department is formed for innovation, advanced engineering and, potentially, business development. Usually, this department is separate from the normal development organization. The separation often causes a somewhat antagonistic relationship between the two sides: normal development is viewed as somewhat boring and run-of-the-mill while the special snowflakes working new technologies are regarded as the propeller-heads that don’t contribute to the company’s revenue.
When I was heading a large lab at the research department of a large company, some leaders in the business units not-so-subtly mentioned to me that my lab (and the overall research department) was a luxury our competitors were unable to afford. This clearly indicated that the perceived value of the research activities was negligible. In practice, the people in the business units were correct as it proved prohibitively difficult to push new innovations from research into commercial products. So, even if the research department did great work, the work never reached the market due to the challenge of transitioning inventions to the business units, where they could be monetized to become innovations.
At this point, it’s important to recognize the difference between Horizon 3 innovation aimed at creating entirely new businesses and Horizon 1 innovation focused on improving the existing product portfolio. Unless Horizon 3 innovations are intended to be part of a business unit’s product portfolio, it’s typically advisable to organize them separately from the business units as they’ll typically be starved of resources and consequently fail. With Horizon 1 innovation, the focus should be on integrating innovation activities as deeply into development as possible.
As a recap of the state of R&D in the software-intensive systems industry, our research shows that 70-90 percent of R&D resources are spent on commodity functionality. For new features, research by us and others shows that somewhere between half and two-thirds of new features are never used or used so seldomly that the R&D investment in the functionality should be considered waste. Hence, the effectiveness of R&D in most companies is atrociously low.
In my experience, innovation and development need to be part of the same team, function or department. The focus on innovation tends to strengthen the importance of delivering actual value to customers and not just building what it says in the backlog. Visa versa, driving innovations in the context of the development organization simplifies their adoption in the overall product.
The main reason for the increasing importance of integrating innovation and development is the adoption of DevOps. As we can push out new software versions frequently, it becomes feasible to build a fast data-driven feedback loop to products deployed in the field. This allows us to quickly measure the impact of improvements of existing features, new features, infrastructure improvements and fixes for defects, among others.
The data-driven feedback loop means we can deliver a minimal viable (or loveable) feature, ie a slice of a feature that’s being considered. If we only build the first 10-20 percent and find out that it has no impact, it’s easy to abandon the feature and avoid wasting more R&D resources. In addition, as we can collect data on feature usage, we can stop investing in improving features that have very low use and focus our energy on high-impact ones. This can lead to significant reductions in the investment in commodity functionality. Finally, we can adopt A/B testing as a mechanism to evaluate features and feature variants. This has been used extensively in the SaaS industry, but with DevOps, it becomes feasible for software-intensive embedded systems as well. A/B testing can be used to measure the impact of feature improvements as well as the impact of new features.
Although radical, Horizon 3 innovation will still be separate from traditional development, all innovation affecting existing products and platforms should increasingly be integrated into the development process. With the adoption of DevOps, software-intensive systems companies have a fast data-driven feedback loop with the products in the field that allows for new ways of working that decrease the investment in commodity functionality and increase the success rate of new features. To end with a quote by Linus Pauling: “The best way to have a good idea is to have a lot of ideas.” Rather than betting the farm on a small number of improvements that product management wholeheartedly believes will drive growth, run fast, cheap experiments with lots of ideas and kill the ones that don’t deliver the expected impact.
