What Is an MVP? Definition, Types, and How to Build One

An MVP, or minimum viable product, is the smallest version of a product that lets you test a real customer need with real users. It is built to answer one question: should we keep going, change direction, or stop?

Outside product circles the same three letters usually mean "most valuable player," and plenty of stakeholders will happily nod along in a meeting thinking of a trophy. In product management the word is humbler. The MVP is not the star of anything. It is an experiment that happens to be shippable.

Eric Ries popularized the term in The Lean Startup, and his own definition is worth reading closely. On the Lean Startup site he describes an MVP as the version of a new product that lets a team collect the maximum amount of validated learning about customers with the least effort. The key word is learning, not launching.

That distinction explains most MVP disasters. Teams hear "minimum" and strip out features, then hear "viable" and keep adding them back. Below we cover how MVP development actually works, which kinds of product MVP exist, and how to put together an MVP plan that survives contact with a roadmap review.

‍

MVP Development: How to Build One Step by Step

Good MVP development starts before anyone opens a design tool. The first job is to write down the riskiest assumption in your idea. Not the most exciting one, the one that would sink you if it were wrong.

Here is a sequence that works for most teams:

1. Name the customer and the problem in one sentence each. If you need a paragraph, you have not decided yet.
2. List your assumptions and rank them by how badly the product fails if they are false.
3. Pick the single riskiest assumption and design the cheapest test for it.
4. Decide in advance what result counts as a pass, and what counts as a fail.
5. Build only what the test needs, put it in front of real users, and measure behavior rather than opinions.
6. Review the results with the whole team, then decide: persevere, pivot, or stop.

Step four is the one teams skip, and it is the one that hurts. I have sat in review meetings where a team shipped a "minimum" product, got 40 sign-ups, and spent an hour arguing about whether 40 was good. Nobody had written down a target, so every person in the room defended the number that supported their original opinion. A success threshold set before launch removes that argument.

Why bother with this discipline at all? Because building the wrong thing is the expensive failure. CB Insights analyzed post-mortems from failed startups and found that lack of market need was the most common reason they gave for shutting down, ahead of running out of cash. Its analysis of startup failure reasons is a useful reality check next time someone says the product just needs more features. An MVP exists to find out, cheaply, whether the market need is real before you spend the budget.

A few habits keep MVP development honest. Keep the team small. Set a time box, often four to eight weeks, and treat it as a hard stop. Talk to users while you build, not only afterward. If you are still unsure who those users are, our guide to the product discovery process covers how to find them before you commit engineering time.

‍

Product MVP Types: Pick the Cheapest Way to Learn

A product MVP does not have to be software. It does not even have to be a product yet. The right type depends on what you need to learn, and the cheapest option that answers your question is almost always the right one.

These are the formats teams use most often:

• Landing page MVP: a page that describes the product and asks for a sign-up or a pre-order. It tests demand before any code exists.
• Concierge MVP: you deliver the service by hand to a handful of customers. It is slow and unscalable on purpose, because you learn what the work really involves.
• Wizard of Oz MVP: the customer sees a working product, while people behind the scenes do the work manually. It tests whether the experience is valuable before you automate it.
• Single-feature MVP: you build one core feature properly and ignore everything else.
• Prototype or clickable mockup: a simulated flow that tests whether people understand and want the idea. This is related to an MVP but not the same thing, since nothing real is delivered. Our overview of the MVP meaning in product management walks through that line in more detail.

Picture a team building an invoicing tool for freelancers. The engineers want to build the full thing, with recurring invoices, tax reports, and currency conversion. A concierge MVP would look very different: five freelancers, a shared spreadsheet, and someone on the team sending invoices by hand for a month. By week two you know which task people dread most, and that tells you which feature to build first. The spreadsheet cost almost nothing and the learning was real.

One more point about picking a type. Fidelity should match the question. If you are testing whether anyone wants the product, a landing page is enough. If you are testing whether people can complete a task, you need something they can click. Harvard Business Review's piece on why the lean start-up changes everything describes the broader idea: treat early products as tests of hypotheses, and change course when customers do not respond, rather than defending a plan written before anyone talked to a customer.

‍

MVP Plan: Scope, Success Metrics, and When to Stop

An MVP plan is short by design. If yours runs to forty pages, it is a product spec in disguise, and it will behave like one: grow, slip, and quietly turn into version one.

A workable MVP plan fits on a single page and answers six things:

• The target customer and the problem you are testing
• The riskiest assumption and the experiment that tests it
• The scope: what is in, and, just as important, what is explicitly out
• The success metric and the threshold that counts as a pass
• The time box and the budget
• The decision date and who makes the call

The "what is out" list deserves real effort. Scope creep rarely arrives as one big request. It comes as small, reasonable asks: can we add login with Google, can we add an export button, can we support a second language. Each one is fine alone. Together they turn a four-week test into a six-month build. A written out-of-scope list gives you something to point at.

Metrics need the same care. Vanity numbers like page views or downloads feel good and decide nothing. Better signals are behaviors that cost the user something, such as completing a task twice, paying, handing over a real email, or coming back in week two. Pick one primary metric. Two or three is a dashboard, and dashboards invite cherry-picking.

Also plan for what you will do with a failure. A failed MVP is a successful experiment if it changes a decision, and a wasted one if it gets filed away. Product teams that get stuck here often benefit from an outside view, since an interim product leader has no attachment to the original idea. If your team needs that, Product People's consulting services are built for exactly that situation.

Finally, watch for the opposite problem: the MVP that never ends. A first release with no plan for iteration quietly becomes the permanent product, with all its shortcuts. Decide up front whether this is a throwaway test or the foundation, because the engineering choices are different.

‍