handbooksThe MVP
The two guesses every startup rests on, three ways to test them without building the product, and why early adopters are the only audience that matters at this stage.
- Two guesses sit under every startup: that the product creates value, and that it can grow. Prove both and you probably have a business.
- An MVP is the smallest thing that gets you real feedback on one of those guesses. It is not a small version of the product.
- Three patterns cover most cases: a video, a service done by hand, or a service faked by hand.
- Build for early adopters. They forgive rough edges and tell you the truth.
The two guesses
| Guess | The question | If it fails |
|---|---|---|
| Value hypothesis | Does this actually create value for the people using it? | Nothing else matters. Growth would only spread something people do not want |
| Growth hypothesis | How will new customers find this, and keep coming? | You have a good product with no path to more customers |
Test the value guess first. Growth applied to a product nobody values only spreads the failure faster.
What an MVP actually is
The smallest thing you can build that produces real feedback from the market. Not a prototype for internal review, and not version one with fewer features.
The test of an MVP is what you learn from it, so anything that does not contribute to the answer should not be in it.
If releasing it does not feel slightly embarrassing, it is probably not minimum. The instinct to polish is the same instinct that produces six months of unvalidated work.
Three patterns
Video. Record what the product would do and show it to the people you think want it. Dropbox did this before the sync engine existed. It answers desire without answering feasibility.
Concierge. Deliver the service by hand for a few customers. Food on the Table did the meal planning manually before automating it. Slow, unscalable, and the fastest way to learn what people actually need. Use it when the product is complex enough that guessing would be expensive.
Wizard of Oz. The product looks finished and automated. Behind it, people do the work by hand. Aardvark's early users thought they were querying a system; humans were routing their questions and relaying the answers. It tests whether anyone wants the automation before you build it.
Go and see for yourself
Genchi Genbutsu is a Toyota practice: go to the actual place and look, rather than relying on reports. For a founder that means sitting with customers yourself, not reading a summary of what they said.
Interviews are the cheapest version of this. Watch what people do rather than what they say they would do.
Early adopters
Build for the people who already feel the problem badly enough to try something unfinished. They will use a rough product, and their feedback is specific.
Mainstream customers at this stage will tell you the product needs to be more complete, which is true and useless. It sends you toward polish before you know the thing is worth polishing.
Write down the one guess your current build is meant to test, and what result would prove it wrong. If you cannot, you are building a product, not an experiment.