Are you building a minimal viable elephant?

As part of the research in Software Center, I work with dozens of companies in the software-intensive embedded systems space on a variety of topics. One of these topics is the development of new products. Having worked with online companies, as well as startups, I’ve become indoctrinated with Steve Blank’s ideas and the “lean startup” concepts. One of the key tenets is that you validate with customers every step of the way. In fact, you seek to minimize the amount of R&D investment between customer proof points. The second tenet is to only rely on what customers say when you absolutely need to, but whenever possible rely on measuring their behavior.

In the embedded systems industry, for some reason, companies are extremely reticent to validate with customers before the entire product has been built. Over the years, I’ve heard a great variety of reasons as to why this is. The main ones include: “We can’t show customers anything but a complete product”, “We’ll damage the company brand if we show an early prototype”, “This idea is so good that they’ll buy it if we only build it”, “Experimentation with customers makes us look like idiots because it looks like we don’t know”, “This stuff is secret and we don’t want to tip off the competition”, “It’s so hard to organize this across the company as I need to coordinate with everyone.”

The consequence of this is that companies tend to build, as one of my colleagues quipped, minimal viable elephants (MVEs) instead of minimal viable products (MVPs). When I confront people with this and we get past the ‘excuses’, it seems to me that there are at least three fundamental causes to this phenomenon.

First, most of the companies established themselves and became successful by building mechanical and electronic products. Because of a variety of reasons, not the least the need to establish manufacturing facilities, the design processes for atom-based products have traditionally been very waterfall and specification based. With the advent of additive manufacturing and rapid prototyping hardware facilities, this is, of course, changing, but the traditional approaches are still widespread. It’s important to realize that building innovative digital offerings requires a fundamentally different process than building physical products. In fact, using the traditional process is a recipe for disaster as you’re flying blind and base your decisions on the beliefs of you and the others at your company – beliefs that are almost certainly wrong.

Second, especially in new product development, complicated internal political processes and games tend to be part of the equation. As a consequence, the attention shifts from the customer and the business ecosystem to the internal political landscape. The folks involved in the development of the new product often have to compromise with various forces in the company. This causes functionality to be added or changed independently of actual customer feedback but based on the opinions of HIPPOs. In the worst case, this results in new products that, for all practical means, are a Swiss army knife that can do many small things but doesn’t solve the one key problem that initiated the product development in the first place.

Third, many think of new product development as a one-shot opportunity that we have to get right on the first try. This, of course, is driven by the difficulty of changing mechanical and electronic products after the start of manufacturing. However, digital offerings are akin to a conversation: constant updates are cheap, allow you to measure how customers respond and, in fact, are expected by many customers.

Building digital offerings that include mechanical and electronic components as well requires a different view on the priorities and process. First, establish problem/solution fit by simply spending ample time with intended customers, well before any R&D effort. Second, establish product/market fit by presenting the intended solution concept to customers and validate the fit, as well as their willingness to pay. Third, build the scrappiest, fastest, smallest realization of the product that allows for small-scale validation. Here you transition from measuring what customers say to what they actually do. Fourth, build a slightly more advanced prototype of the product that can be validated on a larger scale.

Of course, each of these steps is conducted iteratively and you only proceed to the next step when the feedback that you received from customers justifies it. In practice, it often means that the mechanical and electronic parts of the product are over-dimensioned in terms of specifications in order to allow for a larger ‘design space’ of opportunities for the digital part.

Concluding, innovating digital offerings is hard for embedded systems companies and the result often is a ‘minimal viable elephant’ that sees no customer feedback until after the start of manufacturing. Instead, focus extensively on collecting customer feedback throughout the entire innovation process and on customer behavior wherever possible. In the end, it’s the customer who decides whether you’ll be successful.