An MVP (minimum viable product) is the smallest version of a product that can test the most important assumption behind a startup with real customers and produce validated learning at the lowest possible cost in time and money. Among startup fundamentals it is the central tool of the lean startup method, where it drives the build, measure, learn loop that a young company repeats until it either finds product-market fit or decides to pivot.
The word minimum refers to scope, not to quality: an MVP leaves out everything that is not needed to answer the current question. The word viable means that customers can genuinely use it, or at least respond to it in a way that reveals real behavior rather than polite opinion.
What an MVP is designed to prove
An MVP is designed to prove or disprove a specific hypothesis, so it begins with the assumption that carries the most risk rather than with a feature list. Typical risky assumptions concern whether a problem is painful enough, whether a target group will pay, and whether a proposed solution actually removes the pain.
Before building, the team defines a falsifiable hypothesis and a success threshold, for example that a stated share of visitors will pre-order within two weeks. Without a threshold agreed in advance, almost any result can be interpreted as encouraging, and the experiment teaches nothing.
| Risk type | Question to answer | Evidence that counts |
|---|---|---|
| Problem risk | Do customers really have this problem | Repeated, specific complaints and workarounds |
| Value risk | Does the solution create enough value | Repeat usage, retention after first use |
| Willingness to pay | Will customers pay the intended price | Payments, deposits, signed letters of intent |
| Channel risk | Can customers be reached affordably | Acquisition cost from small campaigns |
| Feasibility risk | Can the product be built and delivered | Working prototype under real conditions |
Types of minimum viable product
An MVP does not have to be software. Many effective MVPs simulate the product or deliver it manually so that demand can be tested before engineering effort is spent. The right type depends on which risk is being tested and how expensive a real build would be.
| MVP type | How it works | Best for testing |
|---|---|---|
| Landing page | Page describes the offer and collects sign-ups or pre-orders | Demand and messaging |
| Explainer video | Video shows the intended product in use | Interest in a complex idea |
| Concierge MVP | Founders deliver the service personally to a few customers | Value and workflow |
| Wizard of Oz MVP | Product looks automated but people work behind it | Value before automation |
| Single-feature product | One core function built properly | Usage and retention |
| Piecemeal MVP | Existing tools combined into a working service | End-to-end value at low cost |
| Pre-sale or crowdfunding | Customers pay before the product exists | Willingness to pay |
The concierge and Wizard of Oz approaches differ in transparency: in a concierge MVP the customer knows a person is doing the work, while in a Wizard of Oz MVP the manual effort is hidden. Both deliberately trade scalability for speed of learning and should be replaced once demand is confirmed.
MVP compared with prototypes and related concepts
An MVP differs from a prototype and a proof of concept in who sees it and what it measures. A prototype tests whether a design is understandable, a proof of concept tests whether something is technically possible, and an MVP tests whether real customers will behave in the way the business needs.
| Concept | Main question | Audience | Typical output |
|---|---|---|---|
| Proof of concept | Is it technically feasible | Internal team | Technical demonstration |
| Prototype | Is the design usable | Test users | Mockup or clickable model |
| MVP | Will customers adopt or pay | Real early customers | Behavioral evidence |
| Minimum lovable product | Will early users enjoy and recommend it | Real early customers | Retention and referrals |
| Version 1.0 release | Can it serve a wider market | General market | Revenue and growth |
The minimum lovable product idea arose as a reaction to MVPs that were functional but unpleasant. It argues that in crowded markets the bar for viability includes a good experience, which is a reminder that viable is defined by the market, not by the founders.
Building and measuring an MVP
Building an MVP starts from the hypothesis and works backward to the least work that produces a trustworthy signal. Every feature is questioned with one test: would removing it change the answer to the question being tested? If not, it waits for later.
- State the riskiest assumption and write it as a testable hypothesis.
- Define the success metric and threshold before launch, such as a conversion or retention level.
- Choose the cheapest MVP type that can produce that metric with real customers.
- Recruit a focused early audience from the intended segment rather than friends and family.
- Run the test for a fixed period, often a few weeks, and collect behavioral data plus interviews.
- Decide to persevere, pivot or stop based on the threshold agreed in advance.
Behavioral evidence outweighs stated intentions. A sign-up is weaker than a deposit, and a deposit is weaker than repeated paid use, so teams should prefer metrics that cost the customer something real, such as money, time or data.
Common misconceptions and mistakes
The most widespread misunderstanding is treating an MVP as a cheap first release rather than an experiment. When the learning goal is missing, the result is simply an unfinished product, and its failure says nothing about whether the underlying idea was sound.
| Mistake | Consequence | Better practice |
|---|---|---|
| Building too much | Months pass before any learning | Cut scope to the riskiest question |
| Building too little | Customers cannot judge the value | Ensure the core job is genuinely done |
| No success threshold | Every result looks promising | Agree the threshold before launch |
| Wrong audience | Friendly feedback hides real demand | Test with the target segment |
| Ignoring negative results | Waste continues after the signal | Treat failure as valid learning |
| Scaling the MVP as is | Technical debt and fragile operations | Rebuild deliberately after validation |
An MVP also carries reputational risk for established companies, whose customers expect polish. They often test under a separate brand or with a limited group, while startups can usually accept rough edges in exchange for speed.
Stripped to the essentials
An MVP is the simplest thing a startup can put in front of real customers to find out whether its big idea works. It is not the finished product. It is a test.
Think of a cook who wants to open a restaurant. Before signing a lease, she sells her dishes at a weekend market stall. If people come back every week, the idea has promise. If nobody buys, she has saved years and a fortune by finding out early.
Where it is applied
Two founders believe that small dental practices would pay for software that automatically fills last-minute appointment cancellations from a waiting list. Instead of writing the software, they build a concierge MVP: a simple form where practices report cancellations, after which the founders manually text patients on the waiting list.
They set a threshold in advance: at least five of ten pilot practices must keep using the service after a month and agree to a stated monthly fee. Eight practices continue, and six sign paid agreements. The founders also learn that front-desk staff want confirmations sent to the practice calendar, a requirement they had not anticipated. Only then do they start building the automated product, with validated demand, a tested price and a sharper feature list.