The Minimum Viable Product (MVP) for Hardware Startups

Technical Difficulty Rating: 1 out of 10

In this article we’re going to look at why you need to focus on a Minimum Viable Product (MVP) and avoid feature creep. First of all, let me explain these two concepts.

MVP is a concept that was popularized by entrepreneur and author Eric Ries in his book The Lean Startup. He was one of the main people, along with Steve Blank, that popularized the term.

Basically, an MVP is a version of your product that allows for the collection of customer feedback with the minimum amount of effort. This typically means your product needs to have just enough features to satisfy early customers.

NOTE: This is a long, very detailed article so here's a free PDF version of it for easy reading and future reference.

Then you can implement the feedback that you gather into your future product development. This allows you to avoid trying to read the minds of customers, which trust me you cannot do.

Image result for minimum viable product

Feedback from real customers is much better than trying to guess which features your customers are going to really want.

Instead, with the MVP concept, you get something out there that has the minimum features to satisfy or solve the intended problem. You can use this stripped down version of your product to get more information, and find out what are the specific features that customers want and are willing to pay for.

The key is to have just enough features to satisfy early customers. That’s the most important thing about an MVP.

On the other hand, the more common approach taken by entrepreneurs is to include every possible feature that you think customers may want. It seems like less risk to them if they just include every possible feature since they think this will improve sales. But nothing could be farther from the truth.

It is more realistic to acknowledge that you don’t really know what your customers want. You may think you know what they want, but trust me, no one can ever know what the masses really want until you test it out.

Feature Creep

Another term you will frequently hear is feature creep, which is basically the opposite of a minimum viable product. Feature creep is where you keep adding more and more features hoping it will make your product sell better. New features just keep creeping into your product definition.

For example, you may start with a fairly simple version of your product with limited features. The more you think about it and work on your product idea, you keep adding more and more features trying to build a product that meets the needs of every single person.

This is a mistake than even large companies have done in the past, but most now know that it’s not a good approach. Obviously, large companies have a lot more data on their customers. Typically, this isn’t their first product, so they have a much better idea of what their customers really want.

As a first-time hardware entrepreneur, you’re not going to have any useful data on what people want. You have to constantly be testing it.

Think Like a Scientist

To succeed in business you must think like a scientist. This is where you treat every idea like an untested hypothesis.

For those of you that aren’t science geeks like myself, a hypothesis is basically a proposed explanation made on the basis of limited evidence. It’s a starting point for further investigation. It’s basically just an untested idea.

It’s not considered a part of science until that idea has been tested and shown to match experimental data.

For example, Albert Einstein’s theories are some of the most radical theories that a human mind has ever conceived, especially his theories of relativity.

When Einstein came up with his theory of general relativity it predicted all kinds of weird things like gravity bending space and time. But it hadn’t been tested, and it seemed too crazy to be true.

Eventually scientists were able to test his wild ideas and these experiments showed that Einstein’s theory does in fact model reality.

His theories have now been tested numerous times, and every experiment performed has shown his theories to be correct.

In business and product development, you need to have that same kind of mindset. Don’t assume anything is true until you see real-world data!

Optimal Set of Features

You have to keep in mind that every additional feature that you add to your product greatly increases the complexity of the design. Each feature will increase your development cost and the cost to manufacture your product, so you’re going to have to charge a higher retail price.

Adding features will also take more time, both to develop and get to market. It even increases the likelihood of quality issues in the future. More features are more potential things to go wrong with the product. You will have to monitor more features from a quality-control standpoint.

I suggest that you start by listing every potential feature for your product. Then, rank them in a way that reflects what you think are your customers’ priorities. Keep in mind, this is untested, and is just a good starting point.

Next, determine how each of those features will impact your development cost, your development time, and most importantly the cost of your product. Ideally, you want features that are going to allow you to increase your price without a big increase in the manufacturing cost.

You always want to look at the features that, ideally, have the highest profit margins. These are the ones that you should ideally focus on.

Of course, new features also need to increase the number of sales. The feature has to create more profit, but to have profit, you have to have sales. So if a feature increases your sales or your profit margin, or ideally both, that’s a feature that you want to include.

This is a fundamental part of what I do in my Predictable Hardware Report service, where I break down your product manufacturing cost feature by feature.

I estimate the manufacturing cost, the development cost and time, for any feature you identify. Then, you can make informed decisions about which features to pursue, and which are too expensive or complex to bother with.

You want to have this information even if you don’t include these features in your initial MVP. You need to understand the profit margin and complexity of those features once you get feedback on your MVP. If customers really want a certain feature, you will already know if it’s an economical feature to include.

Once you have ranked features by complexity and cost, then isolate the features at the bottom of your list. Features that have a high complexity and/or a high cost associated with them should be removed from the MVP. Also discard any complex and costly features that are a low priority for customers.

On the other extreme, identify high priority features that are cheap and don’t take long to implement. Features that are easy and inexpensive to add should be included in your minimum viable product.

You may also have identified features that fall between these two extremes. For these features, you’re going need to evaluate them individually. What is the perceived priority of the feature versus its cost and complexity? Pick the most practical features to include in your MVP.

You should get the minimum viable product on the market as soon as possible. You pursue a MVP because it allows you to finish the initial product development on the earlier side.

Get that product out there so you can learn what customers want. Through sales, you gather more feedback from customers. You will also have some sales data that you can use to eventually tweak your product. The future version of your product will utilize this data to increase your sales and profit margin.

You may decide to develop a different product based on what you learned from your MVP, but most likely you’ll want to build on your MVP. It may work out that the MVP is something that sells really well and has good profit margins.

If that is the case, the second version of your product can be a more advanced version. At this point you are dealing with real customer data and you know what people really want.

This allows you to successfully develop other products, or new versions of your product, that will sell well and meet customer demands. Keep in mind that as a hardware startup, you can’t develop a long term company around only one particular product.

If the first product is successful, you’re going to want to develop other products in the future. The initial data that you collect on your MVP can be fundamentally critical for the development of any of your future products.

I can almost guarantee that some aspects of your product are not going to be done right. You’re going to include features people don’t want, and you’re going to miss out on features that they do want.

You can get close to understanding your customers by making some good guesses and doing early market research. Surveys can also help you figure out the best set of features for your product line.

It’s much better to spend a year developing an MVP than to spend three years developing what you think is the perfect product. After three years you may find out that you have developed a complex product that no one really wants to buy at the required price.

It is much smarter and safer to get the MVP on the market, gather feedback from real customers, and then tweak your design.

Everything in business should be looked at as a test of an unproven idea. Never assume that you know exactly what your customers want. Always test, test, and test. That’s the only way to succeed in business.

The key to success is knowledge of the obstacles that lie in your path and a realistic plan on how to overcome those obstacles. Helping you accomplish this is the goal of the Predictable Hardware Report.

Leave a Reply 5 comments

Nick Reply

John, good article. I feel MVP for hardware products, and especially those developed by startups need to cautious about the MVP implications. A hardware startup once it releases an MVP will be consumed by deployment and support of the MVP. There is a risk of significantly pushing out the rollout of next product. Unlike software products there is no such thing as an incremental download/release of a product unless all features can be upgraded with a firmware download. This time gap for the next product release will push the revenue generation especially if the MVP is not chosen carefully. to generate some decent revenue. Startups needs to sustain that push out. Thanks.

    John Teel Reply

    Hi Nick,

    Great feedback and for the most part I agree. The MVP concept isn’t as clean or easy as it with software, so it has to be modified somewhat for hardware. The basic concept of keeping the first product as simple as possible is critical for hardware, if not even more critical than for software. I’ve just seen too many hardware entrepreneurs spend years developing the “perfect” product to only discover most of their assumptions were wrong. With an MVP they will catch this earlier and allow a more successful pivot to what is really the right product.

    Thanks again for your feedback!

      Nick Reply

      John, thank you for the reply. I fully agree that the assumptions need to be verified sooner than later. Then the question to ask “is deploying an MVP the optimal way for hardware startups to get the product feedback”?. Testing with a “representative” alpha customer group would be cheaper, faster, and less riskier than a complete deployment of a MVP. This of course depends on identifying a solid group that is representative of the customer base. An entrepreneur at a minimum needs to know the target customer base/personas that she is going after. She could be blind sided by the product feature set assumptions, but cannot be with which customer bases she is going after.

      Thanks again for the excellent articles and insights.

KRingg Reply

Excellent article… though I do take issue with one sentence:

“It’s not considered a part of science until that idea has been tested and proven to be correct.”

In science, we never “prove” anything… we support conclusions with data. Proofs only truly exist in mathematics and courts of law.

    John Teel Reply

    Good point, thanks for the correction. I should have said “until that idea has been tested and shown to match the experimental data”. In fact, I’ve just updated the article with this correction.

    For example, I know many scientists don’t consider string theory to be science since everything it predicts can’t be realistically tested any time in the foreseeable future. Same is true for concepts such as the multiverse. Personally I think they are still science, but just theories not backed up by data. There are many things Einstein predicted that weren’t thought to be testable at the time such as spooky action at a distance, but later were shown to be testable.

    Thanks for the comment!

Leave a Reply:








Predictable Designs LLC, 10645 N. Oracle Rd, Suite 121-117, Oro Valley, AZ 85737 USA
[email protected], Phone: (520) 261-1844 (for fastest repsponse please email instead of call)
Copyright 2018 by Predictable Designs LLC

This website uses cookies. By continuing you consent to the use of cookies and the collection of your IP address. See our privacy policy for more information.