MVP is one of the most abused terms in product development. It has been used to justify shipping broken software, cutting accessibility, skipping security, and delivering work nobody asked for. This guide covers what MVP actually means, how to define it correctly, and the failure modes that destroy products before they have a chance.
What Eric Ries Actually Said
Eric Ries defined MVP in "The Lean Startup" (2011) as "the version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort." The word "viable" is critical — an MVP must be viable. A broken, embarrassing, or harmful product is not an MVP; it is a failed product that happens to have shipped early.
MVP vs MMP vs MLP
| Term | Definition | Goal | When to use |
|---|---|---|---|
| MVP (Minimum Viable Product) | Smallest thing to validate a hypothesis | Learn | Early discovery, new market |
| MMP (Minimum Marketable Product) | Smallest thing customers will pay for | Revenue | First commercial release |
| MLP (Minimum Loveable Product) | Smallest thing users will recommend | Retention and growth | Consumer products, high competition |
How to Define the Right MVP Scope
- State the hypothesis: "We believe [target user] has [problem] and will [behaviour change] if we provide [solution]."
- Identify the riskiest assumption: What must be true for this to work? This is what you are testing, not building a product.
- Design the smallest possible test: Can you test this with a landing page? A concierge service? A paper prototype? A 5-user interview? Build only what is required to test the riskiest assumption.
- Define your success metric upfront: "We will consider this hypothesis validated if X% of users do Y within Z time." Without this, every result is ambiguous.
- Set a time limit: MVP discovery should have a time box — 4–8 weeks is typical. Without a deadline, "we need more data" becomes a way to avoid making a decision.
The Skateboard Analogy (and Why It Is Misused)
The famous "skateboard to car" diagram (start with a skateboard, add wheels, build up to a car) illustrates iterative product development. It is frequently misapplied. The analogy assumes all versions of the product solve the core transportation need. If your user's job-to-be-done is "get across town reliably in any weather," a skateboard does not solve the problem. The right starting point depends entirely on the minimum viable version of the core value proposition — not the minimum number of features.
Non-Negotiable MVP Requirements
Regardless of how minimal the MVP, these must always be present:
- Security: User data must be protected. "We will add security later" is not acceptable for an MVP that handles real user data.
- Accessibility (WCAG 2.1 AA): Legal requirement in the UK and EU. Accessibility cannot be retrofitted cheaply.
- Error handling: Users encountering unhandled errors will not give feedback — they will leave and not return.
- Privacy policy: Required by GDPR for any product that processes personal data of EU/UK users.