Product development in embedded-system companies is often subject to quite some fallacies and shadow beliefs. In a new series, Jan Bosch discusses ten persistent ones.
During the last months, several companies connected with me to help them with their product development process. Typically, these are embedded-systems companies with strong stage gate processes dictated by the challenges associated with mechanics and electronics. Their challenges are typically associated with procurement and manufacturing.
The reason that these companies reach out is the increasing awareness that the current ways of working aren’t resulting in the business success they used to enjoy. Either the growth isn’t there, the margins are under pressure or the market share is shrinking. It becomes obvious that what made them successful in the past is no longer working and they need to find new forms of differentiation. As the saying goes, what got us here won’t get us there.
An interesting observation I’ve made is that those working with mechanics and electronics are of course aware of digitalization as a concept but, similar to the business folks, often fail to recognize that this affects them to a much larger extent than many appreciate. Digitalization fundamentally changes the way we develop and evolve products, leading to a host of fallacies around product development.
Many of the beliefs held by people in these companies may have been true in the past. With the digital transformation, however, these beliefs have become invalid or at least less important. The hard part is that it still is entirely feasible to build products the old way. It’s just less and less aligned with the expectations in the market and the cost associated with product development tends to be higher than when using more modern means. I’ve tried to capture some of the fallacies, each of which I aim to discuss in more detail in the upcoming posts.
1. Product management knows what customers want
Many in R&D are focused on the specification of a new product or a new feature in an existing product. The assumption is that it’s the job of product management to interact with the market and customers and to distill these insights into a specification that’s the optimal content. Reality shows that in practice, this is incorrect at multiple levels. First, it’s based on a generalization of the verbal input received by product managers. Second, it’s based on what customers say, rather than on what they actually do.
2. Manufacturing is the hardest challenge
Setting up a factory to build the product under development can be extremely expensive and everything in R&D has traditionally focused on optimizing the manufacturing process, including procurement. Modern practices allow for much more flexibility when manufacturing a portfolio of products, reducing the associated risks. At the same time, building a differentiating product that customers actually want to buy is a much harder challenge in a competitive market.
3. The start of production is the end of R&D
One of the key differences between traditional and digital companies is their view on the start of production (SOP). Traditional companies view SOP as the end of R&D as manufacturing of the product commences and we can move on to other projects. Digital companies view SOP as the real start of R&D as we now have a feedback loop with the customer and deployed systems that we can use to inform our decisions concerning the evolution of the system.
4. Innovation means the latest technology
Many product companies equate innovation with employing the latest technology in their products. The implicit assumption seems to be that if we just have the latest technology, the customers will flock to our products. Of course, innovation is about meeting unidentified customer needs or meeting known ones much better than with existing offerings. Technology is a means to that end, not a goal in itself. There are many more dimensions of innovation, including business model, channel and ecosystem, that have much more impact.
5. Software development is a factory cranking out features
One of the ways I gauge the understanding of digitalization in companies I work with is how they talk about software development. Those that use the “software factory” metaphor have real misconceptions about the role of software development and the creative design activity it really is.
6. Experimentation has no role in product development
The use of minimal viable products and A/B experimentation is typically non-existent and discouraged in traditional companies. The specification is used as a basis for all development activity and there’s no reason to question it. This brings us to the notion of knowable versus unknowable. Some things are simply unknowable until we try them out. The response of customers to new products or new features is one of these.
7. Data is only relevant for quality assurance
All companies collect data from products in the field, but traditional companies tend to only collect defect and diagnostic data. Very few of the companies I work with can, for example, answer questions concerning feature usage and the gap between product management predictions about the impact of new features and the actual outcome.
8. The bill of materials has the highest priority
R&D in traditional companies tends to have a strong focus on the bill of materials (BOM). Anything that allows for a BOM reduction is often viewed as justified, even if it means introducing strong dependencies between different subsystems and a significant deviation from the common platform architecture of the product portfolio.
9. Products are static
The focus on the BOM is justified because traditional R&D views products as static. In practice, products evolve continuously in response to, among other things, cost-down initiatives in mechanics, obsolescence and lack of availability of electronic components and new software features deployed. A stronger focus on preparing for evolution can significantly reduce the cost of evolving a product (or platform) over time.
10. The customer cares about the product
Although there are of course products where customers really care about the physical item itself, they’re predominantly concerned with what it allows them to do. For instance, most employees at car companies are deeply passionate about cars, but most of their customers have a mobility need that just happens to be best met by owning a car. And that car should be acceptable from a brand and luxury perspective in the area where the customer happens to live.
Product development in embedded-system companies is often subject to quite some fallacies and shadow beliefs. All of these were or might have been true at some point in the past but are, by and large, no longer true. Product development practices need to evolve for companies to stay competitive. In the end, it’s not about mechanics, electronics, software, manufacturing or procurement but about meeting customer needs in a superior way so that we can capture part of the value we provide for them.