Launching an MVP: Why You Should Ship Before You're Ready

Launching an MVP is the moment most product people quietly dread. Not because the work is hard, but because the work is visible. So we polish. We add the settings panel nobody asked for, the empty states for edge cases that may never occur, the second onboarding flow "just in case." We call it quality. Usually it's fear wearing a nicer coat.

I've shipped enough first versions — and sat on a few too long — to believe this: perfectionism is the most expensive habit in product. It feels responsible. It is actually a slow, comfortable way to avoid the one thing that teaches you anything, which is contact with a real user.

Why launching an MVP early beats polishing in the dark

The argument for shipping before you're ready isn't "move fast and break things." It's narrower and more honest: you do not know what you're building yet. Not really. You have a model of your user in your head, and that model is wrong in ways you cannot see from the inside. The only instrument precise enough to find the error is a stranger using the thing.

Reid Hoffman put the discomfort into a sentence that's followed founders around for a decade. As Eric Ries recounts it, "Reid often says: If you're not embarrassed by your first product release, you've released too late." The embarrassment isn't a bug in the plan. It's the receipt. It means you shipped while you still had open questions — which is the only time shipping actually buys you information.

Paul Graham says the quiet part even more plainly. In "Do Things That Don't Scale," he writes that "perfectionism is often an excuse for procrastination, and in any case your initial model of users is always inaccurate, even if you're a user yourself." Read that twice. Even if you're a user yourself. The thing you're certain about is the thing most likely to be wrong.

The math of waiting

Here's the trade nobody puts on the whiteboard. Every extra week before launch is a week of building on guesses. You're not de-risking — you're compounding risk, because you're stacking decisions on top of an untested foundation. If your core assumption is off, you don't find out in week two. You find out in week twelve, after you've built three features that all depend on the broken one.

Polishing in the dark feels like progress because the artifact gets better. But the artifact was never the asset. The asset is validated learning — and you can't manufacture that internally at any price. A real user clicking the wrong button tells you more in thirty seconds than a month of internal review, because your team shares your blind spots. That's what makes it your team.

So the expensive part of perfectionism isn't the extra polish. It's the delayed feedback, and the work you'll throw away once feedback finally arrives.

Embarrassing is not the same as broken

This is where the "ship it ugly" crowd loses people, and fairly so. There's a real difference between an MVP that's embarrassing and one that's junk, and conflating them is how teams justify shipping garbage.

The cleanest definition still comes from Eric Ries, who calls the MVP "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort" — or, in plainer language, "the smallest version of a product you can use to start the process of learning from customers." Note what's load-bearing: learning. Not least. The minimum isn't the smallest possible pile of code. It's the smallest thing that produces a real answer.

That gives you a sharp test. Embarrassing means thin, rough, narrow — fewer features, ugly edges, manual seams where automation will go later. Junk means the core promise doesn't hold. If your product says "find a place to stay" and people can't find a place to stay, no amount of polish elsewhere matters and no amount of "it's just an MVP" excuses it. The one thing the product exists to do has to actually work. Everything around it gets to be embarrassing.

Airbnb is the textbook case precisely because it was embarrassing without being broken. The first version was literally three air mattresses on a designer's floor during a sold-out conference, rented to three strangers at $80 a night. No reviews, no payments system, no map. But the core promise — you can stay in a stranger's home and it'll be fine — was fully delivered. The slice was tiny. The promise was whole.

How to scope a launchable slice

So the real skill isn't deciding whether to ship early. It's scoping a slice that's small enough to ship this week and complete enough to teach you something true. Here's how I cut it.

Name the one assumption you're betting the company on. Not five. One. "People will let strangers sleep in their home." "PMs will trust an AI-generated draft enough to edit it instead of starting over." Write it as a sentence you could be wrong about. Your MVP has exactly one job: test that sentence.

Build only the path that tests it. Draw the single user journey from "lands" to "gets the value." Everything on that line ships. Everything off it waits. Settings, account management, the second use case, the admin dashboard — off the line. They feel necessary because they're familiar, not because this experiment needs them.

Fake the expensive parts. The whole point of doing things that don't scale is that early on you can replace systems with people. Do the matching by hand. Send the email yourself. Stripe's founders famously onboarded users by walking over and setting up the integration on their laptops. Manual is not a failure to automate — it's a way to learn what to automate before you spend a quarter building it.

Pick the metric that proves the promise. One number that means "the core thing works." Bookings, not signups. Edited drafts, not page views. If the slice can't move that number, the slice is incomplete and you should add to it — not to the surrounding polish.

Set a ship date and let it cut scope for you. A real date is the best scoping tool there is, because it forces the conversation perfectionism keeps avoiding: what actually has to be true on day one? Almost always, less than you think.

The takeaway

Launching an MVP before you feel ready isn't recklessness dressed up as a virtue. It's the recognition that your most confident assumptions are exactly the ones a real user will dismantle — and the sooner that happens, the cheaper it is. Ship the embarrassing version. Keep the core promise whole, make everything around it thin, and let the people you're actually building for tell you what to do next. They will. They always do. The only question is whether you hear it in week two or week twelve.

If you want the other half of this — why even well-built features go unused once they're live — I wrote about that in feature adoption and why most features go unused.

Sources

Eric Ries, "The Entrepreneur's Greatest Asset: Embarrassment" (Next Big Idea Club) — Reid Hoffman's "if you're not embarrassed by your first product release, you've released too late" quote, in Ries's words.
Paul Graham, "Do Things That Don't Scale" — "perfectionism is often an excuse for procrastination" and the unreliability of your initial model of users.
Eric Ries, "The Minimum Viable Product: A Primer" — the MVP definition centered on validated learning with the least effort.
Product Habits, "How Two Designers Created Airbnb" — Airbnb's first version: air mattresses, a sold-out conference, three guests at $80/night.