What is an MVP? A founder's guide to building one that teaches you something

Minimum viable product (MVP)

Eric Ries, author of The Lean Startup, described it in 2009 as the version of a new product that lets a team collect the most validated learning about customers for the least effort. Validated learning means evidence from real behaviour, not opinions gathered in a survey (Ries, 2009).

Why does a startup need an MVP?

Because the most expensive mistake a young company can make is building something nobody wants, and an MVP is the cheapest way to find out early. It turns an idea into an experiment with a question attached.

Say your hunch is that independent veterinary practices would pay to cut no-show appointments. You do not need a full practice-management suite to test that. You need the smallest thing that a few practices will actually use, and a way to see whether no-shows drop and whether anyone pays.

Running out of money topped the CB Insights list at 70%, but the authors point out that it is usually the final cause rather than the root one. A product the market did not want is often what drained the bank account in the first place. An MVP will not save a weak idea; it tells you sooner, and for less, that the idea is weak.

Is an MVP the same as a prototype?

No. A prototype tests whether people understand and can use a solution; an MVP tests whether they want it enough to spend real time or money on it. A clickable Figma file shown to five people is a prototype. A tool a customer relies on during an ordinary working week is an MVP.

A proof of concept sits earlier still: it only shows that something is technically possible. Mixing them up leads to the wrong questions, such as asking a prototype whether there is a market. We compare all three side by side in MVP vs prototype vs proof of concept.

How minimal should an MVP be?

Small enough to ship in weeks, complete enough to genuinely solve one problem for a narrow group of users. Minimal describes the scope, not the quality bar: few features, each one done properly.

In his 2019 Startup School lecture on planning an MVP, Y Combinator partner Michael Seibel argued for timeboxing the spec first: build in weeks rather than months, and when you fall behind, cut features rather than move the date. Some ideas can start with a landing page and a spreadsheet. Hardware, biotech and regulated markets take longer, though even there a simple explanatory site can often go live in days.

How do you build an MVP, step by step?

Start from the problem and the assumption, never from a feature list. These are the six steps we follow ourselves and recommend to any founder, whether or not a technical partner is involved.

What should an MVP include, and what can wait?

Only what a user needs to complete the core job, plus what you need to measure it. Everything else can wait, even features your competitors already have. This is the working rule we use when scoping with founders.

Where do the first users of an MVP come from?

You recruit them by hand, one at a time. Early users rarely turn up on their own, and at this stage you need conversations more than traffic.

In the essay, Graham describes the Stripe founders setting the product up in person for anyone who agreed to try it, and the Airbnb founders going door to door in New York. The same applies to your MVP: the people you interviewed, the forums and Slack groups where your ideal customer asks for help, former colleagues who work in the sector. Doing it manually also shows you what is worth automating later.

How do you know whether your MVP is working?

It is working if it leads you to a clear decision, not if people say they like it. Write down before launch which result would make you carry on and which would make you change course, so the numbers cannot bend to fit your hopes.

• Activation: how many users complete the core job on their first visit.
• Return: how many do it again the following week without being nudged.
• Commitment: who pays, books, signs a letter of intent or introduces a colleague.
• Requests: what people ask for when something is missing. If everyone asks for the same thing, that is your next feature.

Ambiguous results usually trace back to a vague assumption. When usage becomes steady and customers complain if the product goes away, you are on the road to product-market fit. How much it costs to get there depends mainly on scope; the cost drivers are broken down in MVP development cost.