{"id":1043,"date":"2020-03-05T09:38:47","date_gmt":"2020-03-05T09:38:47","guid":{"rendered":"http:\/\/janbosch.com\/blog\/?p=1043"},"modified":"2020-03-05T09:38:52","modified_gmt":"2020-03-05T09:38:52","slug":"are-you-building-a-minimal-viable-elephant","status":"publish","type":"post","link":"https:\/\/janbosch.com\/blog\/index.php\/2020\/03\/05\/are-you-building-a-minimal-viable-elephant\/","title":{"rendered":"Are you building a minimal viable elephant?"},"content":{"rendered":"\n
\"\"
Image by Stefan Keller from Pixabay\n<\/figcaption><\/figure>\n\n\n\n

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\u2019ve become indoctrinated with Steve Blank\u2019s ideas and the \u201clean startup\u201d 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.<\/p>\n\n\n\n

In the embedded systems industry, for some reason, companies are \nextremely reticent to validate with customers before the entire product \nhas been built. Over the years, I\u2019ve heard a great variety of reasons as\n to why this is. The main ones include: \u201cWe can\u2019t show customers \nanything but a complete product\u201d, \u201cWe\u2019ll damage the company brand if we \nshow an early prototype\u201d, \u201cThis idea is so good that they\u2019ll buy it if \nwe only build it\u201d, \u201cExperimentation with customers makes us look like \nidiots because it looks like we don\u2019t know\u201d, \u201cThis stuff is secret and \nwe don\u2019t want to tip off the competition\u201d, \u201cIt\u2019s so hard to organize \nthis across the company as I need to coordinate with everyone.\u201d<\/p>\n\n\n\n

The consequence of this is that companies tend to build, as one of my\n colleagues quipped, minimal viable elephants (MVEs) instead of minimal \nviable products (MVPs). When I confront people with this and we get past\n the \u2018excuses\u2019, it seems to me that there are at least three fundamental\n causes to this phenomenon.<\/p>\n\n\n\n

First, most of the companies established themselves and became \nsuccessful by building mechanical and electronic products. Because of a \nvariety of reasons, not the least the need to establish manufacturing \nfacilities, the design processes for atom-based products have \ntraditionally been very waterfall and specification based. With the \nadvent of additive manufacturing and rapid prototyping hardware \nfacilities, this is, of course, changing, but the traditional approaches\n are still widespread. It\u2019s important to realize that building \ninnovative digital offerings requires a fundamentally different process \nthan building physical products. In fact, using the traditional process \nis a recipe for disaster as you\u2019re flying blind and base your decisions \non the beliefs of you and the others at your company \u2013 beliefs that are \nalmost certainly wrong.<\/p>\n\n\n\n

Second, especially in new product development, complicated internal \npolitical processes and games tend to be part of the equation. As a \nconsequence, the attention shifts from the customer and the business \necosystem to the internal political landscape. The folks involved in the\n development of the new product often have to compromise with various \nforces in the company. This causes functionality to be added or changed \nindependently of actual customer feedback but based on the opinions of \nHIPPOs. In the worst case, this results in new products that, for all \npractical means, are a Swiss army knife that can do many small things \nbut doesn\u2019t solve the one key problem that initiated the product \ndevelopment in the first place.<\/p>\n\n\n\n

Third, many think of new product development as a one-shot \nopportunity that we have to get right on the first try. This, of course,\n is driven by the difficulty of changing mechanical and electronic \nproducts after the start of manufacturing. However, digital offerings \nare akin to a conversation: constant updates are cheap, allow you to \nmeasure how customers respond and, in fact, are expected by many \ncustomers.<\/p>\n\n\n\n

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

Of course, each of these steps is conducted iteratively and you only \nproceed to the next step when the feedback that you received from \ncustomers justifies it. In practice, it often means that the mechanical \nand electronic parts of the product are over-dimensioned in terms of \nspecifications in order to allow for a larger \u2018design space\u2019 of \nopportunities for the digital part.<\/p>\n\n\n\n

Concluding, innovating digital offerings is hard for embedded systems companies and the result often is a \u2018minimal viable elephant\u2019 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\u2019s the customer who decides whether you\u2019ll be successful.<\/p>\n\n\n\n

To get more insights earlier, sign up for my newsletter at <\/em>jan@janbosch.com<\/em><\/a> or follow me on<\/em> janbosch.com\/blog<\/em><\/a>, LinkedIn (<\/em>linkedin.com\/in\/janbosch<\/em><\/a>) or Twitter (<\/em>@JanBosch<\/em><\/a>).<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

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\u2019ve become indoctrinated with Steve Blank\u2019s ideas and the \u201clean startup\u201d … Read more<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"generate_page_header":"","footnotes":""},"categories":[9,8,10],"tags":[],"_links":{"self":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1043"}],"collection":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=1043"}],"version-history":[{"count":1,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1043\/revisions"}],"predecessor-version":[{"id":1045,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1043\/revisions\/1045"}],"wp:attachment":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=1043"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=1043"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=1043"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}