What Is a Minimum Viable Product (MVP)?
An MVP is the simplest version of a product that lets you test your core hypothesis with real customers. Learn what an MVP is and what it is not.
Key Takeaways
- An MVP is not a half-built product — it is the minimum needed to test a specific hypothesis
- The goal of an MVP is learning, not launching
- MVPs can be non-technical — a landing page, a concierge service, or a Wizard of Oz test
- Define what you need to learn before building the MVP, not after
What an MVP actually is
A Minimum Viable Product is not a stripped-down, bug-ridden version of your full product vision. It is the minimum set of features needed to test a specific business hypothesis with real customers and generate actionable learning. The word minimum means you do not build anything beyond what is required to test the hypothesis. The word viable means it must be good enough that customers can actually use it and give you meaningful feedback. The goal is learning, not shipping.
The hypothesis-first approach
The right way to design an MVP is to start with the hypothesis you need to test. What is the single most critical assumption that, if wrong, would invalidate your entire business? Build the minimum version that tests that assumption — nothing more. If your hypothesis is that small business owners will pay for automated bookkeeping, your MVP needs to demonstrate that automation and that those customers will pay. It does not need to handle every edge case, support every browser, or have a polished UI.
Non-technical MVPs
MVPs do not need to be software. A landing page that describes a product that does not yet exist, with a sign-up button, tests demand without writing a line of code. A concierge MVP delivers the promised outcome manually — if you are building a restaurant recommendations app, you can start by texting personalised recommendations to users yourself. A Wizard of Oz MVP presents a product that appears automated but is actually operated manually behind the scenes. These approaches generate real learning at a fraction of the cost of a built product.
Common MVP mistakes
Building too much: adding features beyond what is needed to test the hypothesis, driven by the desire to impress rather than learn. Building in private: developing the MVP for months without showing it to any potential customers. Optimising for the wrong metric: measuring downloads or signups rather than whether customers are getting genuine value. Treating the MVP as the finished product: the MVP is a learning vehicle, not a foundation. Once you have validated the core hypothesis, rebuild properly rather than continuing to patch.
When the MVP is done
The MVP phase is over when you have answered the critical hypothesis with enough evidence to make a well-grounded decision. The decision might be: validate and scale, pivot to a related hypothesis, or stop. The key discipline is defining your success criteria before starting the MVP — what result would convince you the hypothesis is validated? What result would falsify it? Without pre-defined criteria, confirmation bias will lead you to interpret ambiguous results as validation.