What is Minimum Viable Product (MVP)?
The simplest version of a product that lets a team test its key assumptions with real users and learn whether the idea is worth building further, with the least effort.
Definition
A minimum viable product, or MVP, is the smallest version of a product that can be put in front of real users to test whether a core idea is valuable. The goal of an MVP is learning, not perfection: it answers questions such as whether people have the problem you think they have, whether they will use or pay for your solution, and which features actually matter, before you invest months building the full product. The term was coined by Frank Robinson in 2001 and popularised by Steve Blank's customer development work and Eric Ries's 2011 book The Lean Startup, where Ries defines an MVP as the version of a new product that allows a team to collect the maximum amount of validated learning about customers with the least effort. The MVP sits at the centre of the Lean Startup's Build-Measure-Learn loop. You start from your riskiest assumption, build the minimum needed to test it, measure how real users behave rather than what they say, and learn whether to persevere, pivot to a different approach, or stop. Both words matter. Minimum means cutting everything that does not help test the assumption. Viable means it must still deliver enough real value, and enough quality, that users can actually experience the core benefit; a broken or confusing product teaches you nothing except that it is broken. An MVP does not have to be software. Common types include a landing page or smoke test that describes the product and measures sign-ups or pre-orders; an explainer video, famously used by Dropbox to show its file-syncing idea and grow its waiting list before the product was ready; a concierge MVP, where the founders deliver the service by hand to a few customers; a Wizard of Oz MVP, where the product looks automated but people work behind the scenes, as Zappos did when its founder photographed shoes in local stores and bought them only when someone ordered; and a single-feature MVP that does one job well. Airbnb began with its founders renting air mattresses in their own apartment through a simple website. In agile and Scrum, the MVP connects product strategy to delivery. The product owner defines the product goal and the hypotheses to test, orders the product backlog so the items needed for the MVP come first, and the team delivers increments sprint by sprint until the MVP can be released to real users, often within a few sprints. Story mapping helps slice a walking skeleton through each step of the user journey instead of perfecting one step, and prioritisation methods such as MoSCoW separate must-haves from everything else. After release, feedback and analytics flow back into the backlog. Scrum itself does not define the term MVP, but it fits naturally with Scrum's emphasis on empiricism and frequent delivery of usable increments. Related terms are easy to confuse. A prototype is usually a mock-up or proof of concept used internally or in user testing to explore design or feasibility, not a working product used by real customers. A proof of concept tests technical feasibility. A minimum marketable product (MMP) is the first version with enough features to sell to a broader market, and a minimum lovable product (MLP) emphasises delight over bare viability. Building an MVP typically means defining the problem and target user, listing assumptions, choosing the riskiest one, selecting the cheapest test, setting a success metric in advance, shipping quickly, and reviewing results honestly.
When to Use Minimum Viable Product (MVP)
Build an MVP when you face real uncertainty about whether users want something, which is true for most new products, features and startups. Start from the riskiest assumption, not the easiest feature: if nobody needs the product, polished authentication is wasted work. Pick the cheapest test that gives a trustworthy signal, which is often not code at all, and define the success metric and decision before launch. Use off-the-shelf tools aggressively: no-code builders, backend-as-a-service platforms, Stripe payment links, form tools and managed hosting let a small team ship in days. Keep quality high on the core flow even when scope is tiny, because users judge the experience they get. Accept some technical debt deliberately, but track it, and be ready to rebuild parts once the idea is validated. An MVP is less suitable where failure is unacceptable or regulated, such as medical devices, payments infrastructure or safety-critical systems, where a minimum product must still meet strict standards, and in mature markets where users expect feature parity on day one. In those cases, test assumptions with prototypes, pilots and research before release.
Minimum Viable Product (MVP) in Practice
- Landing page MVP: a founder testing an invoicing tool for freelancers builds a one-page site with a clear value proposition, pricing and a 'Get early access' button, then spends a small budget on targeted ads. If fewer than a few percent of visitors sign up, the message or the idea needs work before any code is written.
- Concierge MVP: before building a meal-planning app, a team creates weekly plans by hand for 15 customers over email, learning what they value, what they ignore and what they will pay for.
- Wizard of Oz MVP: an 'AI' document-summary service is launched where staff write the first summaries manually behind a simple web form, to test demand before investing in automation.
- Single-feature software MVP: a scheduling SaaS launches with only one thing, a shareable booking link synced to Google Calendar, and deliberately leaves out teams, payments and analytics until users ask for them.
- MVP in Scrum: the product goal is 'small clinics can take online bookings'. Sprint 1 delivers a booking form and email confirmation; sprint 2 adds clinic availability settings; sprint 3 adds reminders. The MVP is released to five pilot clinics after sprint 3, and their feedback reorders the backlog.
- A success metric written before launch: 'At least 20 of the first 100 sign-ups create a second booking within 14 days.' Deciding this in advance prevents rationalising any result as success.
Common Mistakes
- Building a 'minimum' product that keeps growing for months. If it takes half a year, it is no longer an MVP; cut scope until it can ship in weeks.
- Treating MVP as an excuse for low quality. Viable means the core experience must work well enough for users to see its value.
- Testing the wrong assumption: launching a polished app before checking whether anyone has the problem.
- Measuring vanity metrics such as page views or downloads instead of behaviour that signals value, such as retention, repeat use or payment.
- Confusing an MVP with a prototype. A prototype explores an idea internally; an MVP is used by real customers in real conditions.
- Never acting on the results. An MVP only helps if the team is willing to pivot or stop when the data says so.