Building a minimum viable product that customers love (not just tolerate)
The first version of my product was ugly. No onboarding, no empty states, no explanations. I shipped it in eleven days and fully expected a round of polite "interesting, let me think about it" replies.
Two users asked me the same question within an hour of signing up: "Is this thing broken, or am I doing it wrong?" That question told me more about my product than any analytics dashboard ever did. It also told me the MVP wasn't the problem. The missing love was.
Building a minimum viable product gets you functional. Building one that people actually care about gets you a business. Those are two different jobs, and most founders only do the first one.
Key Takeaways
- A minimum viable product is the smallest thing that lets you test a real assumption with real users — not the smallest thing you can physically ship.
- Viable and lovable are not opposites. The minimum lovable product keeps the emotional core (one moment of delight) and cuts everything else.
- Airbnb, Zappos, Dropbox, and Buffer all started with MVPs that looked nothing like their finished products. In each case, the founders focused on one narrow promise and executed it manually before automating.
- Scope creep, not build speed, is what kills most early products. Every added feature is a delayed learning signal.
- A four-to-eight-week window is enough for most first versions — if you stay honest about what you're cutting.
- Your go/no-go decision should hinge on whether users come back unprompted, not on whether they say they like it.
What is a minimum viable product, really?
A minimum viable product is the smallest version of your idea that lets you test one core assumption with real users. Not the smallest version that looks complete. Not the cheapest version you can produce. The one that gives you the truest reading on whether the underlying idea has legs.
That word "viable" is where most people trip. It doesn't mean "works." It means "capable of survival." A product survives when someone uses it, gets value, and comes back without being bribed. Everything else — branding, polish, marketing, integrations — can come later.
The portable chair test
I use a simple test when I plan an MVP, borrowed from the physical world. Imagine you want to sell portable chairs. You could spend a year designing fabric, weight distribution, and hinges, then build a factory. Or you could weld together a rough frame over a weekend, hand it to five people, and watch them sit on it.
The welded chair is your MVP. It's not the chair you want to sell. It's the chair that answers the question "do people want a chair they can carry?" The answer arrives in a week instead of a year.
Here's the thing: the welded chair will also fail visibly. People will complain about the weight, the height, the edges digging into their thighs. Those complaints are the product roadmap. You don't need to guess what to build — you just listen and rebuild.
Why "viable" is often not enough
Shipped viable products tend to get the same reaction: mild interest. Users try them once, shrug, and drift. The founders take this as a validation problem when it's really an emotional one.
People return to products that make them feel something — smart, fast, in control, ahead of the game. A tool that does its job competently but gives no feeling is forgotten. That's the gap between viable and lovable, and it's worth naming clearly.
What is a minimum lovable product?
A minimum lovable product (MLP) is an MVP whose emotional core has been preserved. The scope is still minimal, but one specific experience inside the product is treated as non-negotiable: the thing that makes users smile, tell a friend, or open the app just to see it work.
I'll be honest, I used to think "lovable" was startup poetry. Then I watched the difference between two products I built, back to back. The first one was a comparison tool. Features worked. Nobody recommended it. The second was a scheduling tool that sent users a beautifully short message the moment a meeting was confirmed. Same scale, same development time. The second one got shared unprompted by roughly a third of new users in the first month.
The only real difference: in the second product, I cared about one specific moment more than the feature list.
How to keep the love while cutting scope
You don't need to love every part of the product. You need to pick one moment and make it the best it can possibly be. Here's how I decide which one:
- Which interaction do users describe first when they explain the product to a friend?
- Where does the value become visible — the moment where the user says "oh, that's nice"?
- What's the single feature that, if removed, would make the product feel like nothing?
Take that one, and pour every hour of polish you have into it. Let the rest be plain. Users can forgive a boring settings page. They will not forgive a lukewarm core.
What are some examples of minimum viable products?
Reading about MVP theory is fine; seeing real ones is better. The pattern is almost always the same — the founders found a way to deliver the core promise before they had the infrastructure to deliver it automatically.
| Product | The MVP as it actually shipped | What was deliberately cut |
|---|---|---|
| Airbnb | The founders rented out air mattresses in their own apartment and took photos of the first listings themselves | Payments, reviews, host profiles, search |
| Zappos | Nick Swinmurn photographed shoes in local stores and bought them at retail when someone ordered | Inventory, warehouse, supplier deals |
| Dropbox | A three-minute demo video before the product existed | Essentially everything — the product was a promise |
| Buffer | A single landing page describing the value, plus a pricing page to test willingness to pay | An actual working scheduler |
The pattern that repeats: nothing automatable was automated until demand was proven. Zappos' founder literally walked to a store and bought the shoes after each order. That's not a business; that's an experiment. But it answered the only question that mattered at that stage.
How to build a minimum viable product (step by step)
The methodology isn't complex. It's just easy to abandon under pressure. Here's the sequence I use, and the one I recommend to founders I work with.
Step 1 — write the assumption you're testing
One sentence. Not "people want a better X." Something falsifiable, like "freelancers will pay $12 a month to stop chasing invoices." If you can't write a sentence that could be proven wrong, you don't have an MVP — you have a hunch with a website.
Step 2 — define the go/no-go metric before you build
Pick your number first. Mine for the scheduling tool was: at least 40% of users schedule a second meeting within seven days. I chose that before writing a line of code, so I couldn't move the goalposts later. That's the point.
Step 3 — cut everything that doesn't touch the core
This is where discipline pays off. Every feature you can't justify in one sentence gets pushed to a "v2" list. Sign-up flows, notifications, settings panels, pricing tiers — cut. Not because they don't matter eventually, but because they delay the signal you need right now.
Step 4 — ship within four to eight weeks
How long should an MVP take to build? For a solo founder, four to eight weeks is a reasonable target for most software tools. If you're consistently past twelve weeks, you're not building an MVP — you're building v1 with extra pressure.
Step 5 — watch what people do, not what they say
This is the discipline that separates products that get loved from products that get politely praised. Ask a user if they like your product, and they'll usually say yes because they don't want to hurt your feelings. Watch whether they come back on Tuesday without an email reminder, and you'll learn the truth.
The mistakes that kill most MVPs
I've made two of these, watched other founders make the third, and I'd bet money you or someone near you is about to make the fourth.
Mistake 1: building for everyone
The first version of my comparison tool was pitched at "anyone who needs to compare services." That's not an audience; it's a group photo where nobody is recognizable. I rebuilt the messaging around one specific role — small agency owners renewing software subscriptions — and the conversion rate went from 2.3% to 4.1% in four months, without touching a single feature.
Narrow beats broad every time at this stage. You can widen later, once you have a tribe.
Mistake 2: treating "minimum" as an excuse for sloppy
There's a difference between few features and bad craft. Users will forgive a product that does one thing. They will not forgive a product that looks broken. My ugly first build lost me three quarters of early signups, and I know this because I could see the drop-off on the very first screen.
Mistake 3: confusing feature shipping with validation
Sprinting from feature to feature feels like progress. It isn't, unless a user has changed their behavior because of what you shipped. I once spent three weeks building an export feature nobody had asked for. Nobody used it. That was the last time I built from a feature list instead of a conversation.
Mistake 4: finishing before you're ready to listen
Half of the value of an MVP comes after launch, in the first four weeks of conversations with users. If you've shipped and gone quiet — no calls, no interviews, no reading support emails yourself — you've done the hard part and skipped the useful part.
How to plan an MVP without overengineering it
Planning is where good intentions go to die. You open a document, you start sketching flows, and four hours later you've designed a version that would take six months to build. I've done this. More than once.
What works for me is brutally simple: a one-page plan that answers four questions.
- Who is the exact person this is for, described in one sentence?
- What is the single job the product does for them?
- What is the one moment of delight inside the product?
- What number tells me this worked?
If those four answers don't fit on one page, the plan is too big. Rewrite it.
Related question — Y Combinator's advice on how to get your first customers overlaps with this almost entirely: don't build for a market, build for a handful of people you can talk to this week. The first hundred users of any product are always recruited manually. Nobody finds you through a search bar on day one.
When to call it lovable and move on
The signal you're looking for isn't applause. It's a specific pattern of behavior — users coming back unprompted, users asking for more because they've already worn out what you gave them, users describing your product to a friend in a way that matches your own description.
When that pattern shows up consistently across a handful of people, you don't have an MVP anymore. You have a product. The next phase isn't about adding features — it's about finding more people who need exactly what you have, and building the second version only for them.
The trap is thinking you'll know the moment it happens. You usually don't. I missed the signal for two weeks because I was too busy planning v2 features nobody had asked for. The users were already telling me. I just wasn't listening with the right ears.
So: what would you cut today if you knew the whole product was going to live or die on one moment? Whatever your answer is, that's probably the moment worth building around.
