A minimum viable product is the simplest version of a product that proves its core value and earns real feedback from real users. For a physical product, that means resolving the minimum feature set rather than shipping a cut-down build, and it's one of the most effective ways to reduce risk before committing to full development and tooling. This guide covers what to include, how to build it, and the mistakes that undermine it.
The idea behind a minimum viable product is simple: build the least you can that still proves the core value, put it in front of real users, and learn from what they actually do with it. It's a way of testing the riskiest assumptions in a product without carrying the cost of developing every feature first. For physical products in particular, an MVP disciplines a project towards what matters, because every added feature carries tooling, cost and complexity that a lean first version avoids.
What "minimum viable" means for a physical product
Most MVP advice is written for software, where you can ship a stripped-down app and add to it later. Physical products don't work that way, tooling and manufacturing make after-the-fact additions expensive, so the MVP is less about a rough build and more about the right feature set. The question is which core functions prove the product's value, and which are additions that raise cost and dilute the proposition without earning their place. Getting that judgement right is the heart of a good MVP, and it's the same discipline that keeps a product commercially viable later.
Why it reduces risk
An MVP earns its place because it replaces assumption with evidence at the cheapest possible stage. It confirms whether the core value actually lands with users before money goes into secondary features, it surfaces problems while they're still inexpensive to fix, and it gives you real feedback to refine against rather than opinion. It also tends to reach a testable point faster, which matters when you're trying to prove an idea to yourself, to users, or to investors.
Deciding the core feature set
The hard part of an MVP is restraint. Start from the single problem the product exists to solve, and include only what's needed to solve it convincingly. Everything else, the refinements, the nice-to-haves, the features you're personally attached to, is a candidate for later, once the core is proven. A useful test for each feature is whether the product still demonstrates its core value without it. If it does, it's not part of the MVP. This is also where honest research pays off, because the feature set should reflect what users actually need, not what's most interesting to build.
How to build one
For a physical product, an MVP is usually realised through prototyping: a working version, built to prove function rather than to look finished, that users can handle and respond to. The level of prototype depends on what you need to learn, and choosing it well is a subject in itself, covered in our guide to prototype development. The aim is a version complete enough to give a genuine read on the core value, and no more complete than that, so you learn quickly and cheaply. Once it exists, put it in front of the right users and gather both what they say and, more tellingly, what they do.
The mistakes that undermine an MVP
A few predictable errors reduce an MVP's value. Building too much turns it back into full development and defeats the point. Building too little, so the core value can't actually be judged, wastes the exercise from the other direction. Misreading the feedback is a subtler risk, particularly reading enthusiasm as commitment when the real test is whether people would pay. And underestimating demand, or the effort to meet it, can turn a promising response into a problem if you're not ready to act on it. The MVP is a learning tool, and it only works if you're honest about what it's telling you.
Measuring whether it worked
An MVP succeeds or fails against what you set out to learn, so decide that first. Depending on the product, the signals might be how users engage with the core function, the quality and consistency of the feedback, whether people will commit money or a pre-order, and how well the result aligns with the commercial case. Clear measures defined in advance are what turn an MVP from an interesting exercise into a decision you can act on.
Related guides: Idea Validation a Step by Step Guide · Prototype Development · Commercial Viability Assessment
FAQ
What is a minimum viable product? The simplest version of a product that proves its core value and gathers real user feedback, built with only the features needed to demonstrate that value.
Does the MVP idea apply to physical products? Yes, but differently from software. For a physical product it's about resolving the minimum feature set, usually through a prototype, rather than shipping a cut-down build you add to later.
How long does an MVP take? It varies with complexity, from a few weeks to a few months. The point is to reach a testable version quickly rather than a finished one.
What's the most common MVP mistake? Including too much, which turns it back into full development, or reading enthusiasm as proof of demand when the real test is whether people will pay.
