Last spring, a founder showed me his "MVP." He'd spent five months and about $40,000 building it. It had user roles, an admin panel, a payment integration, and a settings page nobody had asked for. When I asked how many people had tried it, he said four. Three were friends.
That's not a minimum viable product. That's a full product, built blind, for an audience he never met. And here's the uncomfortable part: I've done the same thing. Twice.
Building a minimum viable product that customers love sounds like a contradiction. How do you earn love with the smallest possible thing? The answer is less romantic than it sounds, and it's the reason most MVPs die in silence while a handful of crude, half-finished products become companies.
Key takeaways
- An MVP is a test of one assumption, not a stripped-down version of your whole vision.
- "Customers love it" is measurable: retention, repeat use, referrals, and unsolicited praise.
- The most famous MVPs were embarrassingly small — a video, a landing page, a manual concierge.
- Speed matters, but the quality you can't compromise is the core value, never the polish.
- A "zombie MVP" — one nobody uses but you keep improving — is the most expensive mistake in the discipline.
Why most minimum viable products fail the love test
Ask a room of founders what an MVP is and you'll hear about scope reduction. Fewer features. Ship faster. That definition is half right and mostly dangerous.
The real definition is narrower: an MVP is the smallest experiment that can prove or disprove one belief about your customer. Not "does the app work" — you can test that yourself. The belief is usually something like "people who run small bakeries will pay to stop chasing invoices by hand."
The assumption you actually need to test
Nine times out of ten, the assumption that kills a product isn't technical. It's behavioral. Will people change what they already do? That question has nothing to do with your codebase and everything to do with whether the pain is sharp enough.
When I built my first paid tool — a small scheduling helper for freelance trainers — I assumed the pain was "double bookings." It wasn't. After three weeks of watching people use it, the real frustration was chasing clients for payment after a no-show. The booking feature I'd spent most of my time on got used twice. The ugly little reminder template I threw in at the last minute got used every day.
Lesson burned in: I tested the feature I found interesting, not the assumption that mattered.
What is an example of a minimum viable product?
A textbook example: the founder of Zappos wanted to know whether people would buy shoes online, a category everyone assumed required trying them on. Instead of building a store, inventory, and warehouse, he photographed shoes in local shops, posted them on a simple site, and bought the pair from the shop only after someone ordered. No inventory, no risk. The test answered one question: will strangers pay for shoes they can't touch?
They did. The lesson isn't "sell shoes." It's that the MVP tested the risky belief and skipped everything that wasn't in question.
What are the top 10 examples of minimum viable products?
I'll give you ten, but read them for the pattern, not the legend. What each one stripped away tells you more than the success story.
- Zappos — a photo site and manual purchasing, no stock.
- Dropbox — a short demo video before a working product existed, to test demand.
- Airbnb — air mattresses in a living room during a conference.
- Buffer — a landing page with pricing tiers; interested users were onboarded by hand.
- Groupon — a WordPress blog posting one daily deal.
- Spotify — early builds streamed from a small licensed catalog, not the whole industry.
- Foursquare — a single-city check-in game with badges.
- Amazon — books only, with orders fulfilled manually at first.
- Twitch (as Justin.tv) — one person streaming his life from a backpack.
- Zappos' cousin: a manual concierge — some of the best MVPs are a human doing the job behind a form.
Notice what's missing from every one: settings pages, admin dashboards, notification preferences. None of those appear in a single origin story, because none of them test anything a customer cares about.
How to build a minimum viable product
Here's the process I actually use now, after the scheduling disaster.
Step one: write the belief as a falsifiable sentence
"Freelance trainers will pay $15 a month to automate payment reminders." That's testable. "Trainers want a better scheduling experience" is not — it can't fail, so it teaches nothing. If your sentence can't be wrong, rewrite it.
Step two: pick the cheapest honest test
Cheapest isn't always a landing page. If your belief is about repeat use, a landing page can't test it — you need something people come back to. If it's about willingness to pay, a "coming soon" form proves nothing. Match the test to the question, and be honest about what each channel can and cannot show you.
| Test type | What it can prove | What it hides | Typical build effort |
|---|---|---|---|
| Landing page + waitlist | Demand and message resonance | Whether anyone returns | Days |
| Concierge (manual behind the scenes) | Real willingness to pay and use | Whether it scales | 1–2 weeks |
| Clickable prototype | Whether the flow confuses people | Actual commitment | Days |
| Working slice of one feature | Retention and repeat use | Wider appeal | Weeks |
Step three: define success and failure before you launch
This is where most teams cheat. Write the numbers down first. In my last test I set two thresholds: at least a third of trial users would return in week two, and at least five would pay without a discount. I missed the first by a wide margin and hit the second. Honest reading: the value was real, the everyday habit wasn't forming yet. That's a design problem, not a demand problem — and I'd never have known the difference if I'd written the goalposts after seeing the data.
Step four: decide pivot or persist, out loud
Ambiguity here is how zombie MVPs are born. Either the belief held and you invest, or it didn't and you change one variable. Say which, in writing, to someone who'll hold you to it.
What is the purpose of creating a minimum viable product?
To buy information cheaply. That's the whole purpose, and it reframes everything else. An MVP isn't a marketing release, a beta to show investors, or a "lite version" of the plan. It's a purchase of knowledge about your customer, made at the lowest price you can negotiate.
Which means: the value of an MVP is proportional to how wrong it could prove you. If failing costs you almost nothing and teaches you the one thing you needed to know, you won. Even — especially — when the answer is no.
The teams that suffer are the ones who treat the MVP as a promise. They ship something thin, customers shrug, and instead of reading the shrug they add features. Six months later the product is heavy, the audience is gone, and nobody can point to the moment they should have stopped.
Build the smallest thing that can be wrong. Then listen hard, because "customers love it" is never a feeling you project onto silence — it's a pattern you can point to in the numbers, and in the emails you didn't ask for.
