A minimum viable product is the smallest thing you can put in front of a real user that produces a real decision — a sign-up, a payment, a next session — and therefore a real signal for you. The classic MVP mistakes are aesthetic: teams polish a full product nobody asked for, or they launch a landing page that measures applause instead of commitment. The boring versions — a spreadsheet you update by hand, a service you deliver manually behind a form, one end-to-end flow with everything else done off-stage — generate the same learning in a fraction of the build time. The purpose is not a small product; it is a fast, trustworthy answer to "will anyone pay for this?"
This is a build-process guide, not product consulting; adapt everything to your market's real constraints.
What makes a product test viable rather than just small?
Viability is about the commitment the test extracts. A waitlist email costs a user nothing, so it measures curiosity; a pre-order, a completed onboarding with real data, or repeated weekly use measures intent. Before building, write down the decision the MVP exists to inform — "do clinics pay $200/month for automated intake?" — and the evidence threshold: how many paying users, at what price, would make you continue. Without the threshold written first, every result becomes interpretable in retrospect, which is how teams spend a year "iterating" on a product the market already declined. The U.S. Census Bureau's Annual Survey of Entrepreneurs consistently shows most young firms fail from lack of market demand rather than product defects, which is exactly the risk a decision-grade MVP is built to retire.
Which MVP formats work for which questions?
| Format | Best for answering | Time to first signal |
|---|---|---|
| Landing page + paid ad traffic | Does the message pull clicks and sign-ups? | Days |
| Concierge MVP (manual service) | Will users value the outcome enough to pay? | 1–2 weeks |
| Wizard-of-Oz prototype | Does the core workflow hold up with humans behind it? | 2–4 weeks |
| Single-flow functional product | Do users complete the one job and return? | 4–8 weeks |
Order matters: run the cheap formats first, and only build the functional version once the cheaper tests cleared their thresholds. Reversing the order is how seed money becomes a monument to skipped validation.
How do you scope the one flow?
Pick the single job your product does that users would name in their own words, then cut everything that serves any other job. Concretely: one user type, one trigger, one outcome, no settings page, no integrations, no dark-mode toggle. Every removed feature gets written on a "later" list with the assumption it depended on — this list becomes your post-launch roadmap, ordered by which assumption the launch disproved hardest. A useful discipline is the pre-mortem: before shipping, write the two most likely reasons users won't complete the flow, instrument both, and watch the actual drop-off within the first fifty sessions. Fifty real sessions of one flow beat five hundred survey responses about a mock-up.
How do you read MVP results honestly?
Define the metrics before launch and in units of commitment: activation (completed the core job), retention (returned to do it again un-prompted), and revenue where applicable. Beware the three flatterers: compliments ("cool!" costs nothing), investor enthusiasm (a different product), and vanity cohorts (launch-week spike from your network). The honest read of a weak MVP result is a fork, not a funeral: either the value proposition is wrong (change the promise) or the artifact is too crude to carry the promise (fix the top drop-off and re-test). One re-test per fork; a third unsignificant rebuild of the same idea is the market answering. Kill criteria set in advance are what let you believe a negative result instead of negotiating with it.
When is an MVP the wrong tool?
- Regulated or safety-critical categories — healthcare, finance infrastructure — where a crude artifact can't legally or ethically carry the promise; scope a compliance-aware pilot instead.
- Markets where the buying decision requires the full product experience, like enterprise platforms evaluated by committees.
- When you already have validated demand — repeat customers asking for more — building the MVP of what they asked for is stalling.
In those cases the discipline transfers even if the artifact doesn't: write the decision, the threshold, and the deadline, then build the smallest compliant thing that meets them.
What happens after the MVP clears its bar?
You upgrade the artifact toward the promise, one bottleneck at a time, keeping the manual back-stage parts as long as they're cheaper than code. The transition to a real product is complete when users stop noticing — which usually means the second flow shipped, not the fortieth. Ship the boring version, read the commitment it extracts, and let the roadmap be written by evidence instead of imagination. Then stop building and go watch session fifty-one.
For more context, read The 7 Signs It's Time to Pivot Your Startup (and 3 Signs It Isn't).
For more context, read hire first startup engineers.
For more context, read open source business model.