Minimum Viable Product (MVP)

“MVP” is one of the most misused words in the startup world. When a team says “we'll ship the MVP in six months,” what they usually mean is “the first version.” Six months, three engineers, one designer. On launch day the first real customer asks: “I was already doing this in Excel, why should I switch?”

The words in the definition should be read one at a time. Minimum: the least of what? Viable: can it be tried with a real person in real conditions? Product: would someone give you something for it? All three are parts of an experiment; none of them is a synonym for “small.”

When you need it

Before you build something, but when you have already decided to build it. That is, if you see these signs:

• There is a big item on the roadmap and its only basis is “customers seem to want it.”
• The riskiest part of the idea is unclear, or team members see different parts as risky.
• A feature costs several sprints to build, but the likelihood of use is a guess.
• You need to show investors or leadership “evidence” and all you have is a presentation.

Where it is too early: if you do not know who has the problem, it is too soon for an MVP. An MVP tests a solution; understanding that the problem exists is done first, through interviews. Check the reality of the problem before you test the solution.

What most teams miss

An MVP is not a product size, it is a type of experiment. And the type is set by the risk you want to test. So the first question is: which is the weakest assumption this idea could collapse on? Demand? Delivery? Price? Technical feasibility? Each risk needs a different MVP.

A few well-known examples. Dropbox's founder Drew Houston put the idea out with a short demo video before the product fully worked; the aim was to see whether people wanted it. The technical difficulty was already known; the uncertainty was demand. For Zappos, the often-told story is that the founder photographed shoes in local stores, put them on a site, and bought the pair retail when an order came in. What was tested there was not warehousing or sourcing but whether people would buy shoes online. In both cases the product was not small, the question was.

The measure of a good MVP is not how little it contains, but how expensive a question it answers, and how cheaply.

The second common mistake is to treat the MVP as a “bad product.” From the customer's side, the experience must work flawlessly in the part you serve; what is missing is scope. In an MVP one feature should work end to end rather than ten features half-working. Otherwise the feedback you get cannot tell you whether the product is weak or the idea is.

Teams who grasp this ask “what decision will the MVP let us make?” instead of “when do we finish the MVP?” The second question talks calendar, the first talks learning.

The difference from the lean startup piece: lean startup describes the rhythm of experiments and the discipline of decisions; the MVP is the design of one experiment inside that rhythm.

The playbook

1. Pick the riskiest assumption

List the assumptions the idea rests on and mark the one where, if you are wrong, everything collapses. It is usually demand or willingness to pay, but sometimes a technical obstacle, sometimes whether a channel is reachable. A single MVP should target a single assumption.

2. Write the pass and fail criteria

Before the experiment: “If at least twenty of five hundred visitors leave an email, we interview twenty of them; if fewer, we change the message.” The number can be arbitrary, but it must be written down in advance. If the threshold is interpreted after the result arrives, the experiment turns into a ritual of belief.

3. Choose the MVP type by risk

For demand risk: landing page and smoke test, demo video, presale. For solution risk: a concierge MVP (delivering the service by hand, alongside the customer). For technical risk: “Wizard of Oz” (a human works behind the scenes while the customer assumes automation) or a small prototype. For price risk: an offer page that asks for real payment.

4. Produce real behavior

Ask for an action, not a compliment or a promise: payment, an appointment, importing data from their current tool. Leaving an email is the cheapest action; can you turn it into the next step, a call or a deposit? The more costly the action is for the customer, the stronger the evidence. A free like is weak, a prepayment is strong.

5. Turn the result into a decision

When the experiment ends there are three options: scale up, change, drop. If the result is ambiguous, the experiment was designed too loosely; set up a sharper second test. Every MVP should give birth to the next MVP or to a decision.

What to measure

• Conversion-action rate: The share of people who saw the offer and took the action you asked for. A leading indicator.
• Cost per learning: The total price (time, money) of settling one assumption. It should fall in later experiments.
• Unprompted return: The share of users who come back without being nudged. Lagging but the strongest evidence.
• Prepayments or commitments: The gap between words and money shows how real the demand is.

Pitfalls

Treating the MVP as version one. Not collecting feedback until the product is complete. That is an expensive guess.

Scope creep. “What if we also add this” turns an MVP into a product. For every new feature, ask: does this strengthen the assumption we are testing, or does it just make us feel better?

Friendly testing. Showing it to friends, followers, or investor acquaintances. They are polite. Get data from people who do not know you and who live the problem.

Start this week

1. Write your idea's riskiest assumption in one sentence and check whether the team picks the same one.
2. Design the cheapest experiment that can test it (landing page, demo video, hand delivery) and write the pass-fail threshold.
3. Launch the experiment within ten days to reach at least fifty real potential customers, and put the results meeting on the calendar.