What an MVP Actually Is

The definition

A minimum viable product is the smallest thing you can build that lets you learn something essential from real customers behaving normally. Its purpose is learning, not revenue, completeness or impressiveness.

Two words carry the weight. Minimum means as little as possible while still being useful. Viable means it must actually deliver the value — a customer must be able to get the real outcome, not a demonstration of it.

What it is not

• Not a bad product. "Minimum" applies to scope, not to quality. A narrow product that works reliably teaches you something; a broad product that breaks teaches you only that it breaks.
• Not version one of the roadmap. An MVP is designed around a question, not around a subset of the eventual feature list.
• Not a prototype. A prototype demonstrates; an MVP is used by real customers to do real work.
• Not an excuse for carelessness. If the domain requires reliability, security or regulatory compliance, those are part of viable.

Starting from the question

The right first question is "what is the riskiest thing we believe?" and the MVP is whatever tests it most cheaply. If the risk is whether people will pay, the MVP might be a payment page and a manual service. If the risk is whether the technology works, it might be a technical proof with no interface at all. If the risk is whether people will change their workflow, it might be a deliberately manual product that forces that change.

Different risks produce completely different MVPs for the same eventual product, which is why copying someone else's MVP is meaningless.

Forms an MVP can take

• Concierge — the service delivered entirely by hand. Unscalable, deliberately, and it teaches the process in detail while proving demand.
• Wizard of Oz — an apparently automated product with humans behind it.
• Single feature — the one thing that delivers the core value, with nothing around it.
• Existing tools assembled — spreadsheets, forms and off-the-shelf software configured to deliver the outcome without writing software.
• Manual-first — automate only the steps that prove expensive once real volume arrives.

The discipline of narrowness

The pressure to add is constant: a prospective customer asks for something, a competitor has a feature, the team believes it is obvious. Every addition delays learning, increases cost and makes it harder to tell what is working.

The useful test for each proposed feature: will its absence stop a real customer getting the core outcome? If not, it waits.