MVP for Hardware

minimum viable product design pieces of digital camera

How the Product Design and Product Innovation industries invented the idea behind the Lean Startup

As I interact with product and hardware companies (as opposed to software and web), I’m often asked, “How does Minimum Viable Product (MVP) apply in the hardware space?” The Minimum Viable Product concept has been popularized over the last several years through the Lean Startup movement. The concept—targeted mainly at web and software startups—encourages entrepreneurs to quickly develop a product with the minimum needed features, get it out to market, learn what doesn’t work, and iterate the product quickly. It’s a great idea. And one of the reasons it has caught fire is that it works so well for web and mobile products—a huge focus of attention in today’s economy.

So it’s no surprise that hardware-based businesses want to know if MVP applies to their work, and if so, how. But you may be surprised to learn that the ideas behind Minimum Viable Product actually originated in hardware…long before they were adopted by Lean Startup and applied to web startups. The core concepts behind MVP—figure out what people want, quickly prototype a version, test it with actual people, and integrate the learning into your next version—were already being practiced in Product Design and Product Innovation firms by the time Lean Startup gained popularity. Just check out this classic IDEO Grocery Cart video from 1999 (Eric Ries, the Lean Startup evangelist was still in college). That’s MVP in action. Rightly so, the software industry has  smartly adopted MVP and put it on steroids because of how well it works in web and mobile.

I’m glad the ideas have gained so much attention. I frankly don’t care how companies learn about them, as long as they try to apply them. But hardware is VERY different than software, so hardware companies need to understand how Minimum Viable Product applies to them before rushing to use it. How are software and hardware different? When it comes to MVP, there are two principal differences:

1. Cost and Difficulty of Launching Products:

Getting a product to market is simply harder and more costly in hardware. Building tools, sourcing manufacturing capacity, buying raw materials, shipping, distributing, getting shelf space, etc…all this stuff that exists in hardware (and not in software) makes it exponentially more expensive and time consuming to get your product into customers hands. Sure, new technologies are shortcutting some of this, but there’s still no comparison.

2. Higher Risk of Failure:

There’s a difference between how people perceive hardware and software products. Because software is perceived to be ephemeral, we are far more tolerant of imperfections. Even if it isn’t right the first time, we don’t abandon software brands. We expect Beta, V1.0, V1.0.1, etc. Not so in hardware. If you buy an actual, physical product and it doesn’t live up to expectations, you may be done with that particular brand.

These differences  change how we define the MVP in hardware and software. For a web startup, the Minimum Viable Product is the first live product. It’s out in the world being used by actual customers. Maybe it’s not fully publicized, but it’s a live, real product. In hardware, the MVP are tests. Many of them. Start with low-fidelity mockups that test the basic concept with a small number of subjects. Over time, work towards higher fidelity prototypes that are tested with larger number of users. It’s critical to keep track of the risks and unknowns and develop a set of tests and experiments that irons them out over time, eventually working your way up to limited pilots. Sure, there are many innovations that make it less costly and quicker to get a hardware product to market (take advantage of them!), but it’s still a far more costly and risky proposition to launch than in software.

As the web startup movement adopted the ideas behind MVP, the definition of the actual thing has changed. But the core idea behind it—figure out what people really want by building things and letting people use them while you observe and listen—have not changed since the hardware world first codified it and put it into use quite a number of years ago.

Dan Ostrower

Posted By: 

Dan Ostrower