Reid Hoffman, the founder of LinkedIn, gave the software world its most quoted piece of launch advice, the idea that if you're not embarrassed by your first version, you shipped too late.
Business owners hear that and flinch. Embarrassed? In front of customers? In a market where reputation is everything?
But the line isn't a joke about low standards. It's a precise statement about where knowledge comes from, and misunderstanding it is the most expensive mistake in software. So let's take it seriously.
The mistake the MVP exists to prevent
Here's the default path, the one instinct chooses: spend months (and, as we covered in what apps actually cost, real millions) building the complete vision, every feature, every screen, polished, then launch.
Now count what you actually know on launch day about the only question that matters: will people use this and pay for it? Nothing. Everything so far has been assumption wearing a suit. The complete build is the maximum possible bet placed at the moment of minimum possible knowledge, and that inversion, not bad code, is why most failed software fails. The product worked. The guess didn't.
The MVP, minimum viable product, the core idea of Eric Ries's The Lean Startup, flips the bet: build the smallest thing that lets real users answer the real question, learn from what they do, and let evidence (not imagination) decide what gets built next. The embarrassment Hoffman means is the gap between your grand vision and your small first step. Feeling it means you actually took the small step. Not feeling it means you gambled the vision.
What "minimum" actually means (and the two ways people ruin it)
Ruin #1: minimum without viable. The MVP is not permission to ship broken things. "Viable" is half the name: the one core thing must work, end to end, reliably. A delivery app whose deliveries fail isn't an MVP, it's a reputation incident. The discipline is narrowness, not sloppiness: one problem, solved completely, for one type of user. Everything else waits.
Ruin #2: the everything-MVP. The politician's version: start minimal, then "while we're at it" your way back to the full build with a humbler name. The test that keeps you honest: what question is this feature answering? If launching without it still answers your core question, will people use and pay for the core?, it's not MVP material. It's decoration on a hypothesis.
The scoping tool we use in real projects: write the one sentence, "[This user] can [do the one thing] and [the money/value moves]." Everything required by that sentence is in. Everything else, the dashboard, the referral system, the dark mode, is a card in the "proven-demand" pile, waiting for evidence.
Why this is really about knowledge, not thrift
The budget benefit is obvious. The deeper one is epistemological, and it's the actual point: users will tell you things no amount of planning can. They'll ignore the feature you were sure was the hook, break your flow in ways you never imagined, and beg for something you'd dismissed as trivial.
Every one of those surprises is worth money, if it arrives before you've built the wrong thing. The MVP is a machine for making surprises arrive early and cheap instead of late and catastrophic. We felt this on our own skin with our own product build: the features users actually leaned on were not the ones we'd have bet the roadmap on, and only launching small let us find that out while changing course was still cheap.
That's also why the embarrassment fades so fast in practice: version one is embarrassing for weeks. The full-build mistake is embarrassing forever, and it comes with invoices.
The sequence, start to finish
- Write the one sentence. One user, one action, value moves. Argue about the sentence, not the feature list, the sentence is the product.
- Cut everything the sentence doesn't require. Physically list the cuts. This pile is your roadmap-in-waiting, not your failure.
- Build viable. The narrow thing works completely, including the boring invisible parts (payments that fail gracefully, data that survives).
- Launch to real users and watch behavior, not compliments. People are polite in feedback and honest in usage. Trust the usage.
- Let evidence promote features from the pile. Build next what users demonstrated they need. This is the whole loop: build small, learn, build the right next thing, repeat.
Run that loop and something quietly wonderful happens to the economics: the terrifying total-vision quote dissolves into a sequence of small, survivable, evidence-funded steps, each one de-risked by the last. The vision still gets built. It just gets built correct, in the order reality voted for.
Slightly embarrassed, fully informed, and still solvent. That's the mindset.
It's the same principle behind why the ₦20,000 logo isn't the mistake, skipping structure is, small and structured beats big and premature in branding too. The size was never the problem in either story. The missing structure was.