Why Your MVP Should Embarrass You: The Case for Launching Badly and Fast
Emrah · Michael Seibel's advice to Y Combinator founders comes down to one uncomfortable idea: if you are not a little embarrassed by your first version, you waited too long to ship it.
The Story
In the early days of Justin.tv, before it became Twitch, the entire product was one person streaming his own life, all day, in mediocre video quality. There was no editorial plan, no polished interface, no roadmap slide explaining the vision. There was just a camera, a stream, and a small group of people curious enough to watch.
Stripe's origin story is less well known but just as instructive. When Patrick and John Collison signed their first customers, there was no self-serve dashboard, no automated onboarding flow, none of the infrastructure that now defines the company. The founders sat down next to the customer and wired up the payment integration themselves, by hand, on the spot. This approach later earned a name inside startup circles: the "Collison installation."
Neither of these was a product in any conventional sense. Both were closer to a live experiment, run at the smallest possible scale, designed to answer one question as cheaply as possible: does this actually solve a real problem for a real person?
This is the frame Michael Seibel, General Partner at Y Combinator and co-founder of Justin.tv and Socialcam, brings to a piece of advice that has become something of a mantra inside YC's Startup Library: launch something bad quickly.
The Idea
The term "MVP" gets thrown around so often in startup culture that it has drifted from its original meaning. Many founders now treat it as a synonym for "an incomplete product we are a little ashamed of." Seibel pushes back on that framing directly. An MVP is not a lesser version of your real product. It is a learning instrument, built specifically to test whether your central hypothesis holds, using the least amount of time and effort possible.
That distinction matters more than it sounds. A founder who thinks of their MVP as a rough draft of the final product will keep polishing it, adding features, delaying the moment a real user touches it. A founder who thinks of their MVP as an experiment will ship something narrow, watch what happens, and decide the next step based on evidence instead of intuition.
The psychological pull runs in the opposite direction of what good execution requires. Founders are, almost by temperament, perfectionists about their own creation. The market does not reward that instinct in the earliest days. It rewards speed to signal.
How Founders Should Read This
For a founder, the practical implication is to cut scope aggressively and build in weeks, not months. The Collison installation is the extreme version of this: skip the automation entirely, solve the problem manually for a handful of customers, and only build the scalable version once you know, with real evidence, that the underlying need is there.
This creates a specific trap worth naming. A founder can fall in love with the manual process itself. It feels productive, the early customers are happy, and there is a comforting illusion of traction. Weeks turn into months, and the question of when to actually build the product keeps getting deferred because "it's working."
The opposite trap is just as common: narrowing scope so far that the MVP tests nothing meaningful. A demo that no real user would ever pay for, wrapped in the language of an MVP, teaches you almost nothing. The discipline Seibel is describing sits between these two failure modes. Pick a real, narrow problem. Solve it completely, even if manually, for a small number of real users. Let the evidence, not the founder's taste, decide what happens next.
Practically, this means every founder should be able to answer a version of this question at any point: what is the single riskiest, least-tested assumption behind what we are building right now, and what would it take to test it this week rather than this quarter?
How Investors Should Read This
Investors read the exact same story through a different lens, and the difference is not stylistic. It is structural, rooted in how venture funds are built.
A seed fund operates on a limited fund life and needs signal early to make follow-on and portfolio construction decisions with any confidence. From that vantage point, the speed at which a founder resolves the single most expensive uncertainty in their business (does anyone actually want this) is a direct proxy for capital efficiency. A founder who spends four months refining an MVP nobody has used yet is, from the fund's perspective, burning runway on an untested hypothesis rather than de-risking it.
This reframes what looks like scrappy hustle from the founder's side into something a VC evaluates more coldly: is this manual process a deliberate, temporary bridge to a scalable product, or is it quietly becoming the business itself? A "concierge MVP," done well, is a founder buying cheap information. Done poorly, over many months, with no plan to systematize it, it starts to look like a services business wearing a startup's valuation multiple.
Investors also read speed-to-first-user as a signal about the founder, not just the product. Bias to action, comfort operating without complete information, and willingness to be seen doing something unglamorous (streaming badly, installing payments by hand) all correlate with the kind of execution founders who beat power-law odds tend to display. A founder who insists on perfecting the MVP before anyone sees it is often signaling something less flattering: discomfort with the ambiguity that defines the earliest stage of any company.
Where the Two Views Collide
Here is the friction point, and it is worth sitting with rather than smoothing over.
The founder looking at a manual, ugly first version sees exactly what they are supposed to see: it works, someone is getting value, we are learning fast. From inside the company, this is unambiguously good news.
The investor looking at the same scene can ask a genuinely uncomfortable question: is this a product company, or a service business that happens to have a pitch deck? Both readings can be correct simultaneously, because they are answering different questions on different time horizons. The founder is asking "are we solving a real problem." The investor is asking "will this scale into venture-style returns."
The founders who navigate board meetings and diligence calls well are the ones who have already done this thinking themselves, before anyone asks. They can say, plainly: this manual step is intentional and temporary, and here is the exact signal, the exact number of repeat customers or usage pattern, that tells us when to systematize it. That answer converts a potential red flag into evidence of judgment.
The founders who get caught flat-footed by the question usually have not asked it of themselves yet. That gap, more than the manual process itself, is what erodes investor confidence in a room.
The Takeaway
The real skill Seibel is teaching is not "build fast." It is knowing precisely which uncertainty you are testing at every stage, and being able to say so out loud, to yourself and to anyone else in the room. A rough, embarrassing first version aimed at the riskiest untested assumption is a sign of good judgment. The same rough version, aimed at nothing in particular, is just an excuse dressed up in startup language.
The question worth carrying into your next product decision: what is the single riskiest, least-tested assumption in what you are building right now, and what would you decide about it today, with the incomplete information you already have?
Source: Michael Seibel, "How to Plan an MVP," Y Combinator Startup Library — ycombinator.com/library/6f-how-to-plan-an-mvp
