MVP (Minimum Viable Product)

How to build the smallest thing that actually tests your idea.

Build · 6 min

What is this?

An MVP (minimum viable product) is the smallest version of your product that lets real customers use it and gives you real evidence about whether your idea works — not a stripped-down version of your final vision.

It's a learning tool first, a product second. Its job is to answer your biggest open question as cheaply as possible.

Why it matters

Building the "full" version before anyone has used anything is the single most common way founders waste months on the wrong features. An MVP forces you to learn from real usage early, when changing course is still cheap.

What you're trying to learn

Learn whether real users get real value from your specific approach — with the least amount of building possible.

Before you start

Write down the one unknown this test is for, in a single sentence, before building anything.
Decide, in writing, what result would count as "this works" versus "this doesn't" — before you have a result to be attached to.
Consider whether you need to build software at all yet: a concierge test (you personally deliver the outcome by hand, no product) or a manual/Wizard-of-Oz test (it looks automated, you're doing it manually behind the scenes) often answers the same question faster and cheaper.
Line up a small number of real users willing to actually use it, not just look at it.

Step by step

1Identify the single biggest unknown about your idea — usually "will people actually use/pay for this," not "can we build every feature."
2Design the smallest thing that tests that specific unknown — sometimes a real (even manual) service before any software at all.
3Cut every feature that isn't required to test the core unknown, even ones that feel important.
4Get it in front of real users as fast as possible, not a polished version months later.
5Decide in advance what result would tell you "this is working" versus "this isn't" — before you're emotionally invested in the answer.

What to ask / do

Can a stranger complete the core task without you sitting next to them explaining it?
Did they come back and use it again without being asked to?
Where exactly did they hesitate, get confused, or give up?
What did they do that you didn't expect?
Would they be disappointed if this went away? (Ask directly, and watch what they actually do, not just what they say.)

What the signal looks like

Good signal

Users complete the core task on their own, without you explaining or rescuing them.
Some of them come back and use it again without a reminder from you.
They ask when they can use it more, or ask for a specific extension of it.
You learn something real about their behavior you couldn't have predicted from a conversation alone.

Weak or negative signal

"This looks cool" or "nice idea" with no actual usage.
People try it once, out of politeness to you, and never come back.
The only usage is you demoing it to them, not them using it themselves.
Validating based on how many features shipped rather than whether anyone got real value.

Common mistakes

Treating "MVP" as an excuse to ship something low-quality with no real test attached to it.
Adding "just one more feature" before launching, repeatedly.
Building for scale (thousands of users) before proving anyone wants it at all.
Skipping the step of deciding what success/failure looks like ahead of time.

Checklist

You can name the one specific unknown this version is meant to test.
A stranger could use it without you sitting next to them explaining it.
You defined, in advance, what result would count as a positive signal.
You've cut at least one feature you originally assumed was necessary.

You're done when: A stranger has used your smallest possible test on their own, you know whether they got real value from it (not just whether they were polite about it), and you can name a specific, concrete thing you learned.

What to do next

If people got real value and came back: move toward Pricing & Willingness-to-Pay or Early Traction, depending on what you're most uncertain about next.
If they didn't: figure out whether the problem was validated wrong, the approach was wrong, or the test itself was unclear — before building more.
Use Record What I Learned on the related Mission. Building or shipping this test does not, by itself, change anything in your model.