Minimum Viable Product

There was a long stretch when everything to be built was decided at the start and nothing went out until all of it was done. Forty features in the spec, eighteen months of implementing them one at a time, and a single release at the end. In that order, whatever was wrong can only be seen on the last day — after eighteen months and all the salary that went with them have been spent to discover that the product had no use.

The scene repeated in a recognizable shape. A team works through the night to attach all forty features by the launch date, and three weeks later has forty sign-ups, four of whom came back a second time. The retrospective tends to produce the same sentence: it took eighteen months to learn that nobody uses this. Thirty-seven of the forty features did not need to be built, and it was not that there had been no way to find out beforehand. Nobody had tried to find out.

Lean startup, the idea of growing a business by building small and learning as you go, reversed that order. It starts by redefining what a startup does as running experiments rather than producing products. An experiment needs a hypothesis before anything else, and what gets built becomes the instrument for testing it. In build-measure-learn, the loop of building, measuring and learning, a minimum viable product (MVP) is the thing that sits in the first slot. Since the aim is to shorten the time it takes to go around once, whatever is built there should be as small as it can be.

The word minimum is where the misreadings start. It does not mean a small number of features. It means as much as is needed to answer the one hypothesis currently being tested, which is why the same product calls for different builds depending on the question. If what you want to know is whether people will pay to have this problem solved, a description page and a payment button cover it. If what you want to know is whether your method actually saves time, that one path has to run all the way through. The second word carries a condition too: viable means at least one problem a user has must genuinely get solved, so a screen where nothing happens when you press the button does not qualify.

Which is why what to build is settled only after the hypothesis has been written out as a sentence. In practice it takes roughly this shape: someone in a certain situation is trying to do a certain thing, and if we do this for them they will take a particular action, and more than a given percentage taking that action counts as correct. Leave off the last piece, the bar, and the team looks at the result and argues all over again about whether it passed. Whether three sign-ups out of twenty is a success or a failure has to be decided before shipping, not after.

The product field keeps four things that get built small before anything is finished, and an MVP is the one that goes in front of real users. A prototype is put together temporarily to see a reaction, a proof of concept checks only whether something is technically possible, and a pilot opens a finished product to a handful of customers as a trial deployment. What separates the four is not size but what each one is trying to find out.

The terms under MVP fall into two groups: what gets built and shown in order to test a hypothesis, which is the types, and which direction the minimum line gets moved, which is the variants.

The types group sorts the ways of reducing how much gets built. There are three, separated by how much work a person does behind the scenes and what is put in front of the user.

1. Concierge MVP — nothing is automated and a person delivers the service directly. For a product that plans meals, instead of writing the program you ask ten people what they need and write their plans out by hand. The user knows the service is coming from a person rather than a product. Build time is close to zero and the conversations stay with you, so what needs automating shows up faster this way than any other. Past about twenty people no one can keep up by hand, which means this approach cannot measure anything about scale.
2. Wizard of Oz MVP — the surface looks like a product running on its own while a person handles the work behind it. You build a screen where a user uploads a document and a summary appears thirty seconds later, and during those thirty seconds someone reads the document and writes the summary in. What differs from the concierge approach is that the user does not know a person is involved, so what you see is the reaction to an automated product as it would actually be. Because you are not telling them, the quality and the response time have to hold to whatever was promised.
3. Landing page MVP — no product is built at all, just a page that measures demand. It states what the product does and what it costs, with a sign-up button attached. The answer is how many of a thousand visitors pressed it, and anyone who does is told it is still on the way and asked for a contact address. It is the cheapest of the three and also the narrowest: it reports whether people respond to the description, and says nothing about whether they would keep using the thing once they had it.

The variants group moves the minimum line. Both terms came out of situations where MVP was being used badly in practice.

1. MLP, a minimum lovable product, argues for keeping the release small while finishing it well enough to be liked. Use learning as a shield to ship something unpleasant to use and you cannot tell whether people turned away because the idea was wrong or because the thing was crude. The proposal is to leave the feature count where it is and make the one feature that remains properly.
2. MMP, a minimum marketable product, is the smallest configuration you can charge for. Shipping to learn and shipping to bring in revenue call for different things. Payments and refunds, handling questions, terms of service — none of it is needed for learning and none of it can be skipped when selling.

The two groups follow each other in time. The types are what you choose from while a hypothesis is still being tested; the variants are the threshold you cross once the testing is done and the decision is to grow this into a real product. Serve ten people by hand through a concierge run, then build it properly, then charge for it. Skip the order and you spend six months building something nobody wants, carefully. Choosing among the five follows from the same logic: when you do not yet know whether there is demand at all, take the cheapest option among the types, and when demand is confirmed but people leave quickly, it is time to move to the variants.

"Let's take this as an MVP. Open the invite screen alone within three weeks, watch what happens, then decide."

A proposal to build the basis for the decision before building the thing itself, and the three weeks is a ceiling on what the check is allowed to cost.

"Is this an MVP or just a smaller build? Nothing here says what we're trying to find out."

Without a hypothesis to test, something small is only something small.

"Let's run the MVP as a concierge. Automation goes in once demand is confirmed."

Check by hand first and build nothing until the answer comes back.

Pagedeck once looked at a feature that would turn comments inside a document straight into tasks. Mia's hypothesis was a single sentence: people are genuinely bearing the effort of copying requests out of comments into a separate task tool, and if that copying is done for them they will keep using it. Theo put the build at seven weeks.

Mia went the concierge route first. She asked eight paying teams for their consent, and for two weeks she read the comments on each team's documents herself and sent out a task list every morning. The only thing built was a sign-up form. What surfaced after two weeks was that half the hypothesis was wrong. Six of the eight teams opened the lists, but what they wanted was not comments turned into tasks — it was being told who had not replied yet. The direction changed without the seven weeks ever starting, and what eventually got built was a far smaller feature that gathered up unanswered comments. Mia spent about forty minutes a day over those two weeks. Finding the same thing out through code would have cost the seven weeks and Theo's time first, and the news that it was wrong would have arrived afterward.

The most common mistake is reading an MVP as a cheap version with fewer features. The name carries minimum in it and the thing really is built small, so the reading is understandable. What gets cut, though, is scope rather than finish. Keep one thing and make that one thing work well enough for a user to actually use it. Without that distinction a team ships ten features each built halfway, and when users leave there is no telling whether the idea was wrong or the thing was unpleasant to use. No experimental result survives, the next decision goes back to being a hunch, and the advantage of having built small disappears with it.

The second is reading an MVP as a stage you ship once and finish. It gets used as another name for a first release often enough to encourage that. It is really one slot in a loop, made in order to look at a result and make the next call. When two weeks return a wrong hypothesis, as in the Pagedeck case above, dropping that direction and moving to a different hypothesis is the normal ending. Teams that read it as a final stage keep growing what they already shipped even when the result points the other way. Six months later they are looking at the same numbers they saw in the first three weeks, with ten more features attached. Closing an experiment that came back negative is not a failure but the experiment doing its job, and the moment it is labeled a first release, closing it gets hard.