What MVP Actually Means (Not What Most Builders Think)
The minimum viable product concept, popularised by Eric Ries in The Lean Startup, describes the version of a new product that allows the team to collect the maximum amount of validated learning with the minimum amount of effort. The ‘viable’ in minimum viable product is the key qualifier: it must be viable enough to be used by real customers and to generate real feedback about whether the product creates the value it’s intended to create. It doesn’t mean the smallest possible thing the team can build — it means the smallest thing that answers the specific hypothesis being tested.
The most common MVP misunderstanding: treating ‘minimum viable product’ as permission to ship something bad. An MVP that’s embarrassingly broken, that crashes regularly, or that delivers an experience so poor that users leave in frustration before the value proposition can be assessed doesn’t generate useful product learning — it generates evidence that the execution is bad, which doesn’t distinguish between a good idea poorly executed and a bad idea. The MVP needs to be good enough that users can experience the intended value; it doesn’t need to be comprehensive, polished, or scalable.
The Hypothesis That the MVP Tests
Before designing an MVP, the team should be able to state the specific hypothesis it’s testing in a form that has a clear true or false answer. Not ‘will people like this product’ but ‘will at least 30% of users who try the onboarding flow complete it and perform at least one core action within 24 hours.’ Not ‘is there demand for this service’ but ‘will at least 10 out of 50 potential customers pay $49/month for this specific feature set as described in a demo call.’
The hypothesis specificity matters because it determines what the MVP needs to test and what evidence counts as validation or invalidation. An MVP designed to test an underspecified hypothesis produces ambiguous results: ‘people seemed interested’ is not validation; ‘we got 8 out of 50 to pay, and we needed 10’ is a clear near-miss that produces a specific decision about whether to iterate on the offer or abandon the hypothesis.
Types of MVPs: Beyond the ‘Build Something Small’ Version
The MVP toolkit includes approaches that don’t require building any product at all for initial validation. The landing page MVP tests whether a defined audience is interested in a specific value proposition: build a page that describes the product as if it exists, include a call-to-action (sign up, join waitlist, pre-order), drive targeted traffic, and measure whether the conversion rate suggests sufficient demand. The concierge MVP tests whether the service creates value for customers by delivering it manually: instead of building software to automate a workflow, have a team member perform the workflow manually for real customers and measure whether they value the outcome.
The Wizard of Oz MVP — presenting what appears to be an automated system while humans perform the actions behind the interface — has been used to validate many now-successful products. Zappos initially tested whether people would buy shoes online by photographing shoes in local stores, posting the photos online, and purchasing shoes from the stores when online orders came in. The test required no inventory system, no warehouse, and no supply chain investment — just enough to answer whether the customer behaviour the business depended on would actually occur.
What to Measure and What to Ignore
The MVP measurement framework should focus on the metrics that directly test the core hypothesis rather than the metrics that are easiest to collect. Traffic numbers, social media followers, and demo requests are vanity metrics — they indicate that people are aware of the product but not that they find it genuinely valuable. The engagement metrics that indicate genuine product value: retention (do users come back?), active usage (do users do the core thing the product is designed to do?), and willingness to pay (will users pay a specific price for this specific product?)
The retention metric is particularly diagnostic: a product that users try once and don’t return to hasn’t found product-market fit regardless of how many users tried it. The acquisition and retention chart that shows new users and returning users growing in parallel indicates that the product is both attracting new interest and creating enough value to bring users back. The chart where new user acquisition is growing but returning users aren’t indicates that something is attracting users but the product isn’t delivering enough value to retain them.
When to Stop Iterating and Either Commit or Kill
The pivot-or-persevere decision — whether to continue iterating on the current direction or to fundamentally change the product, customer, or model — is the decision that most startup teams find hardest because it requires honest assessment of a direction they’re emotionally invested in. The signals that indicate continued iteration is warranted: specific, addressable reasons why the MVP didn’t achieve its hypothesis (the target customer was wrong but we have evidence of a different customer who values the product, the price was too high but retention data suggests customers would pay a lower amount), and a revised hypothesis that the next iteration can test.
The signals that indicate a pivot is needed: multiple iterations have failed to find a customer segment that values the core product at a viable price, the feedback from customers who tried the product suggests the problem being solved isn’t actually painful enough to merit a paid solution, or the unit economics of the identified customer segment are structurally unsatisfactory regardless of iteration. The courage to kill a hypothesis that has been adequately tested and failed is one of the most valuable capabilities a founding team can develop — it redirects resources toward the next hypothesis rather than deepening investment in a direction with deteriorating evidence.