I friggin' love MVP's. Is that a weird thing to say? Probably, but I'm going to anyway: I friggin' love MVP's! For those unfamiliar with the term (but I'm guessing if you're here reading this, you're not), it refers to "Minimum Viable Product" as coined by Frank Robinson and popularized by Steve Blank and Eric Ries. The typical definition reads as follows:

"A product with just enough features to satisfy early customers, and to provide feedback for future development…"

The reason I love them, is because "necessity breeds ingenuity". Creativity really flourishes when more constraints are introduced. And what's more constrained than a cash-strapped startup trying to build a hardware product? It's in these moment I really enjoy hacking down to the core of the product and figuring out interesting ways of how you can provide a threshold level of value to customers with the least amount of resources. (If you want to learn how, I suggest you read part 2 of “How to Develop Consumer Hardware”.)

While the definition of MVP sums it up really nicely, I still see a lot of misconception about it as it pertains to consumer hardware. One of the main reasons is that they're so different from software MVPs. In a software MVP you first only build core functions to appeal to a Smallest Viable Audience (SVA), iterate on that version quickly by pushing regular updates to add features along the way and expand the market along with it. That's the beauty (and pitfall) of software: You can just keep expanding upon the same product.

And I'm not downplaying software here, software also has its tipping point going form no-code solutions to custom builds, but the fact is you can stretch it much longer to a larger audience before needing to switch to huge investment.

I've broken it down in 8 rules, but the heart of the message is the following:

Your MVP will not make you a successful company. Your MVP needs to prove that you deserve to exist.

This one’s not mine, but a rephrasing of a quote of Will Ahmed, founder of Whoop, a rather successful consumer hardware startup. It's quite clear what's meant here, your MVP is here to validate the market segment you've chosen (or SVA). It's not meant to build a profitable business, it's meant to prove there is a business in the first place. Once that's settled you can start thinking about a V2, which is what you build to dominate your market segment.

Will Ahmed founder of Whoop quote — *This guy gets it*

#1: This is not the first thing you do

Too often, I see hardware founders, especially those coming from an engineering background, that have already built or want to start by building an MVP. This is again the action bias at play which is so prevalent in those communities that I hold dear to my heart. The truth is that a lot of founder much more enjoy tinkering around with tech over doing some actual customer discovery and development. Often they feel the market is already validated because they talked to some potential customers and they said they were "interested". It really boils my blood when this happens and my typical response is "so have they put in an advance to be on the waiting list?". You can guess the rest. This is all to say that you need to first prove willingness-to-pay, as I've extensively covered in my article "Always Derisk Your Market First -- Sell before you build".

You need to validate your value proposition (or CPS) and then prove willingness-to-pay before you build something! But if you think you've done that, here’s a helpful chart!

Consumer Hardware MVP Guide — *You’re welcome*

This is the P in MVP, guys. It implies it's a product that's being sold and used!

#2: You need paying customers

As made clear above, the main goal of an MVP is to learn by developing your customers and market. It's in essence a tool for "proof-of-business" where you want to show that solving the customers problem in this way is something they're willing to pay for. In “How to Prove Willingness-to-Pay” I talked about how you can sell before you build and ensure a list of potential customers with a high chance of conversion, developing the "sellable" MVP is the next step directly after that.

It is essential that an MVP is deployed with paying customer in order to actually learn something. Feedback from free users is pretty much worthless. If they're not paying for you product, they're not assigning value to it — and if they don't value it — how can they provide useful feedback?

This was one of the early things I learned when working with the guys from Mealhero. While they had built an awesome MVP from all off-the-shelf components that satisfied the core functionalities, they only tested it with friends, family and sympathizers for the low, low price of "free".

While it did help them get some useful feedback, it didn't go above the level of optimizing for user-friendliness or general "polish" of the experience, look and feel. It made them miss out on the fact that their business model was flawed, which got them in all sort of trouble later down the line. These type of "free customers" typically don't even want to pay for a janky MVP, they're often later adopters and are expecting much more fidelity and "polish" from the experience. So, that's the type of feedback you'll get that doesn't go above the superficial level.

You want feedback from people who paid good money and can put up with a half-baked product as long as it solves their problem.

#3: It shouldn’t be able to scale

An MVP is directed at your first 100 customers, and as we know from YC's Paul Graham's infamous article, we need to do things that don't scale for our first 100 customers (If you haven't read it, you should). As stated, the goal is to use it as a tool to recruit paying users and figure out what works. This also means that you still might be wrong about the solution you've built with your MVP, this means two things:

You don't want to have invested heavily in CAPEX to create parts that do scale (think injection molding, PCBa's, but also custom firmware etc. …)
You want to be able to adapt your MVP quickly to react to customer feedback

As such, it should exist almost entirely of off-the-shelf (OTS) components. Meaning Raspberry Pi's over PCBs, 3D-prints over injection molding, … you get the idea.

Sometimes you even see that competitive or similar existing products are used to hack them into an MVP, which might feel weird at first, but you're simple capitalizing on all the work the competition has already done for you! You can even sometimes white-label existing technology with a few add-ons of your own (there’s a great example of GoPro in my article on “Expanding on the Bowling Pin Model”)

I always advise to batch MVP versions in sets of 10 when moving towards the magic number of 100 paying customers. It's large enough to already spot potential issues with things that will need to scale in the future, but small enough to get a handle on things when you need to make a change

Quick side note: you don't always need to go to a 100 and can take smaller steps like 5 at a time or something. It all depends on what you can spend, if you're selling at a loss or not, how fast you reach a good MVP configuration and pricing model. You'll know it when you everything falls in place and you're ready for scale, it'll just feel right and might happen even at 20 units already.

#4: Your MVP might not even need hardware

I might hear you saying "yeah, but our product is different. We're doing something so complex it needs to be customized and we can't build it on OTS component!". And in some cases this might be true, but let's be honest, that's more often reserved for deep tech (think carbon capture and quantum computing) rather than consumer hardware.

In almost all cases, you can replace the hard parts with a human. There are countless examples of this, what is known as a "Concierge MVP" and it's one of my favorites.

Here are some notable examples:

Nest Thermostat (2010-2011)

Early prototypes had remote operators monitoring and adjusting temperatures
Helped develop the learning algorithms by understanding human decision patterns
Manual intervention validated the concept before full automation

iPhone/Siri (2010)

Before acquiring Siri, Apple tested voice assistant concepts with human operators
Operators would manually look up answers and type responses
Helped understand user intents and common queries before building AI

DoorDash (2013)

Founders manually took food orders via a simple website
They personally delivered all orders in the beginning
Used this to understand delivery logistics before building the platform

Another thing to hink about is that your entire MVP might not even be a piece of hardware at all! Think about other ways you can get intimate with the customer and their problem and get to know the market. It might be by purely offering a service, where you work as a consultant to help solve their problem.

So what are you waiting for? Hire some interns and get started!

#5: Function over fidelity

A lot of founders tend to over-emphasize on the "design" of the device early on, inspired by the likes of Apple. How it looks, feels, the UX/UI, … And as an industrial designer myself, I completely agree that these things are crucial for a succesful product, if not essential. You need to delight your customers with an exceptional experience of the "whole product" meaning it includes the entire journey of discovering, researching and ordering the product to unboxing, installing and using the product as well as an exceptional customer service.

But here's the things, all these things matter for scaling your product business, so right now, they're a bit besides the point. You simply need to get the "core loop" of your product working over anything else, the user research and "design" work should be limited to figuring out what the most basic "core loop" is that still provides value to customers.

As Reid Hoffman from PayPal and LinkedIn-fame said: "you should be embarrassed by the first verion of your product."

Reid Hoffman of Paypal Linkedin quote — *Reid also gets it.*

Your SVA can deal with a janky MVP. As long as it solves their problem better than the alternative, they'll put up with a lot of shit. But that comes with an important requirement:

#6: Customer service over product performance

While these early customers can be very tolerant for missing features, malfunctions or even complete product failures, it's really important that if these things happen, they're bailed out immediately. Your customers should have a direct line to you, the founder, to solve any grievance almost as soon as they happen.

To compensate for product performance, you need to provide an extreme level of customer service. The best thing you can do is build it into the product. It can be a QR code they can scan to provide details about the problem with a 1-hour response guarantee or even as simple as sticking your personal phone number or email address on the device, or a "help" button on every UI screen that connects to your phone number. Point is: you need to be available 24/7 to help out your customers, it's the fastest way to learn about user experience, technical flaws and what customers value.

Now, of course you don't want to be putting out (sometimes literal) fires 24/7, you need to prepare for this and it's quite a simple rule:

#7: Don't ship junk

That's it. It can be half a product, it can miss a ton of features, but those that you do ship, should friggin' work! So focus on getting those right. I'm not saying you need to run HALT's (Highly Accelerated Lifecycle Testing) — because that defeats the purpose of an MVP and things will definitely break down — but be sure to leverage the power of using OTS components and hacking existing products. These things have built-in reliability, so take advantage of that! Again, avoid the urge to make custom shit, because that's a sure-fire way to introduce unknown variables.

Ask yourself the question if you would use our own MVP. If answer’s yes: great! Do it. No joke, besides being a great indicator if your MVP is ready to go to market, making yourself your own customer is a great way to learn about your own product.

#8: Don't forget about certification!

Hah, yes, the mystical lands of CE-marking. As I started to write this section, I decided this needed it's own article, I’ll place a link here when it’s ready.

Here's the gist of it. I often get the question from founders if they "really need to CE mark their device?". The easy answer is of course "yes". All consumer electronics sold in the EU need to conform to CE marking. But for an MVP, you might not want to jump through all these hoops and lose a lot of time, right? So what are your options?

Disclaimer: these are simply my opinions based on my experience and not an instruction manual. Each case is different and you should always talk to a legal expert before making these decisions.

Assess the risk: you need to figure out in what ways your product can cause harm and how severe the harm done is. A smartwatch can most likely do less harm than an autonomous gas-powered BBQ. And while CE+CE doesn't equal CE, using pre-certified modules helps reduce the risks. Based on the assessment you might:
Swallow the risk: for low-risk MVPs (think Raspberry PI in a box with a simple I/O), you can think about self-certification without full lab testing. Consider pre-compliance testing as a middle ground, it's faster and cheaper while covering critical aspects.
Share the Risk: Have customers sign waivers acknowledging they're using a non-certified prototype. List potential risks and responsibilities clearly. While this doesn't completely protect you legally in case something does go wrong, it's a transparent approach suitable for early testing. Even if you're choosing option 1, always include this one as well for good measure and transparency.
Certify: For higher-risk products or when you need certainty, invest in proper certification. Though slower and more expensive, it reduces trouble down the line. If your product indeed carries large risks that can harm people, you owe it to them to do this right. Even when working in batches of 10, once certified, you can most likely get away with writing a rationale if you make changes or only recertifying the bits that changed.

So if you're thinking on starting to build your MVP, go through this list first and make sure doing the right thing at the right time!

8 Essential Rules for Building MVPs