There is a persistent delusion in the startup world that the first version of a product needs to be impressive. That customers will reject anything below a certain quality threshold. That launching too early does permanent brand damage.
Y Combinator has funded more than 5,000 startups since its founding in 2005, producing over 80 unicorns and generating more than $800 billion in combined portfolio valuation. The pattern the accelerator sees repeatedly is the opposite of what most founders assume: the founders who launch something embarrassingly simple, put it in front of real users, and iterate aggressively outperform the founders who spend months building a polished product in isolation.
Michael Seibel, a YC partner and co-founder of Twitch, has delivered this message to thousands of startup founders through YC’s Startup School program. His core thesis: your MVP should take weeks to build, not months. It should have limited functionality. And it should target a small group of users who desperately need what you are building. Everything else is a distraction.
This is not a new insight. But it remains one of the most ignored pieces of startup advice, because it requires founders to confront a deep psychological fear — that their work will be judged and found lacking. Understanding why that fear is irrational, and what a good MVP actually looks like in practice, is the difference between startups that learn and startups that build in the dark.
The Overthinking Trap
YC uses a memorable illustration of the MVP paradox. On one end, the inexperienced founder who does not know any better — they build something basic and ship it. On the other end, the most experienced founder who has seen enough to know that speed matters more than polish — they also build something basic and ship it.
In the middle sits the dangerous founder: smart enough to know what a great product should look like, ambitious enough to want to build it, and disciplined enough to spend months trying. This founder does extensive surveys, conducts dozens of user interviews, and contacts every potential customer before writing a line of code. They are doing everything that business school and startup blogs tell them to do. And they are losing to the founders on either side who just built something and shipped it.
The mistake is not in wanting quality. The mistake is in believing that quality can be designed in isolation from users. The only way to build something users love is to let them interact with something real — even something embarrassing — and learn from their behavior. Surveys tell you what people say they want. Products tell you what people actually do.
Paul Buchheit, a YC partner and the creator of Gmail, frames this as seeking the “90/10 solution” — a solution that gets you 90 percent of the value with 10 percent of the effort. It may not be perfect, but it is good enough to put in front of users and start learning. The remaining 90 percent of effort should be directed by what those users actually need, not by what you imagine they might want.
Why Your Fear of Launching Is Irrational
The biggest psychological barrier to shipping an MVP is a non-specific fear: “If people see my product and don’t like it, my company dies.” YC has seen this fear paralyze thousands of founders. It is almost always irrational, for three reasons.
Your company does not die from a bad MVP. A negative first impression does not bankrupt you. You have not run out of money. You have not exhausted your market. You have simply learned what does not work. That information is more valuable than another month of building in isolation. The history of successful technology companies is littered with terrible first versions that nobody remembers.
The people who reject your MVP were never your customers. Users who try an early product, see it break, and never return are not early adopters. They are mainstream users who would not have tried your product in the first place until it was recommended by someone they trust. You cannot lose customers you never had. Your early users are the desperate ones — the ones whose problem is so painful that they will tolerate a broken solution if it addresses even part of their need.
You learn nothing without real users. The gap between what you think users want and what they actually need is enormous. Every week spent building without user feedback is a week of accumulating wrong assumptions. The faster you get something into users’ hands, the faster you correct course. Eric Migicovsky, YC partner and founder of Pebble, teaches an entire Startup School module on this point: the best founders maintain a direct connection to their users throughout the lifespan of their entire company, extracting information at every stage to guide product decisions.
What Great MVPs Actually Looked Like
The companies most associated with product excellence did not start with excellent products. Their first versions would be unrecognizable — and in some cases barely functional — by today’s standards.
Airbnb
In 2007, Brian Chesky and Joe Gebbia were struggling to pay rent on their San Francisco apartment. When they noticed that attendees of a sold-out industrial design conference were having trouble finding affordable accommodation, they bought three air mattresses, set them up in their living room, and put up a basic website offering “AirBed & Breakfast” to conference-goers.
The site was extremely basic — no sophisticated booking flow, no robust search, no review system. The offering was limited to one location (their apartment), one type of accommodation (air mattresses on their floor), and one occasion (a single conference). They charged $80 per night with a minimal payment process that bore no resemblance to the seamless transaction system Airbnb uses today.
By any reasonable product standard, this was primitive. But it was enough to test the core hypothesis: will strangers pay to stay in someone else’s home? Three guests said yes, and everything else could be built later.
Twitch
Twitch started as Justin.tv — a platform featuring co-founder Justin Kan live-streaming his life 24 hours a day using a webcam strapped to a baseball cap. When it launched on March 19, 2007, there was no way for other people to broadcast. The entire product was a single video feed of one person’s daily life.
By October 2007, Justin.tv opened to the public, letting anyone create a channel. The gaming category emerged organically and grew fastest, eventually overtaking every other content type. In June 2011, the company spun off the gaming content into its own platform called TwitchTV. Amazon acquired Twitch for $970 million in August 2014.
The team had no idea their product would become the dominant gaming live-stream platform. They only discovered that use case because they launched something minimal and watched what users did with it.
Stripe
Patrick and John Collison conceived of Stripe in late 2009, frustrated by how difficult it was for developers to accept payments online. Their first prototype, built during a month in Buenos Aires, was called “/dev/payments” — an API that let developers embed a payment system into their website with just a few lines of code.
The backend was held together with manual processes. When someone signed up to use Stripe, Patrick would call a friend who would manually set up a merchant account for that new user. It was a solution that could not scale, but early-stage startups did not need a sophisticated payment infrastructure. They needed to accept credit card payments from their customers without spending weeks integrating with legacy payment processors.
Stripe’s first customers came from the YC network — about 20 startups that the Collison brothers knew personally. Their very first user, Ross Boucher, had a simple request: actually transfer money to his bank account. The brothers kept iterating based on this kind of direct feedback. Stripe officially launched in September 2011, nearly two years after the initial prototype, by which point the product had evolved dramatically from where it started.
Finding “Hair on Fire” Customers
Not all users are equal for an MVP. The users who matter are the ones whose problem is so urgent, so painful, that they will use any solution — even a broken one — to address it.
YC calls these “hair on fire” customers. The analogy is vivid: if your hair is on fire and someone offers you a solution, you do not ask whether it is elegantly designed. You do not check the reviews. You use whatever is available. Your early customers should be this desperate.
This has a practical implication that many founders miss: the right MVP is not determined by what you can build, but by who you are building for. If your target customer has a mild inconvenience, they will wait for a polished solution. If your target customer has an urgent, painful problem with no good existing solution, they will tolerate anything that partially solves it.
The exercise is straightforward: identify the most desperate potential user of your product. What is the minimum you can build that addresses their most urgent need? That is your MVP. Everything else is version two.
Chesky and Gebbia’s “hair on fire” customers were conference attendees who literally could not find a hotel room. Kan’s early viewers were people curious enough about life-streaming to watch anything. The Collison brothers’ first users were YC startups that needed payments working yesterday and did not care whether the backend was held together manually.
Advertisement
The “Fake Steve Jobs” Trap
A common objection to the MVP approach invokes Steve Jobs: “Jobs would never have shipped something ugly. He cared about product quality above everything else. I should do the same.”
This fundamentally misunderstands what Jobs actually did. The first iPhone shipped in June 2007 without an App Store — that came a full year later with iPhone OS 2.0 in July 2008. The camera could not take video. It only supported EDGE (2G) connectivity — painfully slow internet even by 2007 standards, when 3G was already widely available. There were no third-party apps whatsoever.
Apple Maps launched with iOS 6 in September 2012 with notoriously inaccurate directions and missing data. The backlash was so severe that Tim Cook published a public apology on September 28, 2012 — a highly unusual move for Apple — and went so far as to recommend competitors like Google Maps, Bing Maps, and Waze as alternatives until Apple could improve its own product.
The iPod went through six generations of its Classic line alone, plus the Nano, Shuffle, and Touch variants. Each iteration added features, improved battery life, and refined the interface. The first iPod was not the iPod that conquered the market — it was the iPod that proved people would carry their music library in their pocket.
The lesson from Jobs is not “build perfect products.” The lesson is “identify the one thing that matters most, ship it, and iterate relentlessly.” That is exactly the MVP philosophy.
How to Build Your MVP in Days, Not Months
The practical framework from YC’s Startup School is simple:
Step 1: Write down every feature you think your product needs. Be exhaustive. Include everything you have imagined, every feature a potential user has mentioned, every capability you think differentiates you.
Step 2: Identify the core value proposition. Ask yourself: if my product only did one thing, what would it be? What is the single capability that, if it worked, would make a desperate user’s life better? That capability is your MVP.
Step 3: Cut ruthlessly. Go through every feature on your list and ask: does a truly desperate customer need this feature to start using my product? You will be surprised at how many features you can defer to version two, three, or four. Authentication? Maybe you start with a shared password. Search? Maybe you start with a manually curated list. Payments? Maybe you start with manual invoicing.
Step 4: Pick your launch format. Not every MVP needs to be working software. Seibel points out that an MVP can be a simple website, a landing page, a spreadsheet, or even a manual process that simulates the product experience. The Collison brothers’ “manual merchant account” setup was effectively a human-powered backend. Do whatever gets you in front of users fastest.
Step 5: Do not fall in love with your MVP. This is the most important step. Your MVP is a learning tool, not a product. It will change dramatically — potentially beyond recognition — as you iterate with users. Founders who fall in love with their first version resist the changes that user feedback demands. Fall in love with your users and their problems. The product is just the current best guess at a solution.
Spec, build, and ship in weeks. Not months. Not quarters. The goal is to start the feedback loop as fast as possible. Every day without user feedback is a day of building on assumptions.
The Iteration Engine
The MVP is not the product. It is the starting point of a learning cycle:
- Ship the MVP to a small group of desperate users
- Talk to those users — not through surveys, but through direct conversation. Watch them use your product. Ask what frustrated them. Ask what they wished it could do. The key, as Migicovsky teaches, is to ask about their behavior and their problems, not about hypotheticals. “Would you use this feature?” is a bad question. “Tell me about the last time you encountered this problem” is a good one.
- Iterate — fix the most critical problem they identified. Add the one feature they most desperately need.
- Ship the update and repeat
Paul Graham’s famous essay “Do Things That Don’t Scale” reinforces this cycle. Graham writes that the most common unscalable thing founders have to do at the start is recruit users manually — one by one, through personal outreach, through showing up where their users are. Stripe’s founders would tell potential users to hand over their laptop, then set up Stripe on the spot. This does not scale. But it creates an initial user base that feeds the iteration engine.
After five, six, seven iterations, your product will be very different from where you started. You will have learned things about your users’ needs that no amount of pre-launch research could have revealed. And your users — the ones who stuck with you through the rough early versions — will be your most loyal advocates, because they watched you build something for them.
This cycle is the entire job of a startup in its early stages. Not fundraising. Not hiring. Not marketing. Build, ship, learn, iterate. Everything else is a distraction until this loop is producing a product that users demonstrably need.
When the MVP Approach Fails
It is worth acknowledging the situations where the standard MVP advice needs adaptation. Some products have a genuinely high minimum quality bar — a medical device, a financial trading platform, or anything where failure carries safety or regulatory consequences. In these cases, the MVP is not “ship something broken” but “find the smallest safe version of the product you can test with real users.”
The principle still holds: get to real user feedback as fast as possible. But “as fast as possible” might mean months of regulatory work before you can put anything in a patient’s hands. The mistake is using this as an excuse in industries where it does not apply. Most software startups do not have a genuine minimum quality constraint. They have a perceived quality constraint rooted in the founder’s ego.
The other common failure mode is building an MVP, shipping it, and then ignoring user feedback. The MVP is only valuable as the first step of an iteration cycle. If you ship and do not talk to users, you have merely built a bad product instead of no product. The learning loop is non-negotiable.
Conclusion
The MVP philosophy is not about shipping bad products. It is about recognizing that the fastest path to a great product runs through a series of imperfect versions, each informed by real user behavior. The founders who embrace this — who overcome the fear of judgment, who resist the urge to polish, who fall in love with their users instead of their product — consistently outperform the founders who try to get it right on the first attempt.
Build it fast. Ship it early. Talk to users. Iterate. This is the playbook that built Airbnb, Twitch, and Stripe. It works because reality is a better product designer than any founder working alone.
Frequently Asked Questions
How do I know if my MVP is too minimal?
If your MVP addresses the single most urgent need of a desperate user, it is not too minimal. The threshold is not feature completeness — it is whether the product delivers enough value for one specific user segment to keep using it despite its flaws. If your first users try it and never come back, the problem is usually that you targeted the wrong users (not desperate enough), not that the product needs more features. Remember that Airbnb started with three air mattresses in a living room, and Stripe’s first backend was a person manually setting up merchant accounts.
What if my competitors already have better products?
Your competitors’ products are better for their existing users. Your MVP should target users that competitors are not serving well — typically the most underserved segment with the most urgent unmet need. Airbnb did not compete with hotels on amenities. It competed on a use case hotels could not serve: affordable accommodation during sold-out conference weekends. Find the gap where existing solutions fail, and build the simplest thing that fills it. Your advantage as a startup is speed and focus, not feature parity.
Should I charge for my MVP from day one?
If possible, yes. Charging even a small amount validates that users find real value in your solution. Free users give you usage data but not revenue signal. However, if charging creates friction that prevents you from getting your first users, start free and add pricing in a later iteration. The Collison brothers gave Stripe away to their first 20 users from the YC network to gather feedback before building a revenue model. The primary goal of your MVP is learning, not monetization — but willingness to pay is one of the strongest signals you can learn.
Sources & Further Reading
- How to Plan an MVP — Y Combinator Startup School (Michael Seibel)
- How to Build an MVP — Y Combinator Startup School
- Do Things That Don’t Scale — Paul Graham
- How to Talk to Users — Y Combinator Startup School (Eric Migicovsky)
- How to Get Your First Customers — Y Combinator Startup School
- Tim Cook Apologizes For Apple Maps — TechCrunch
🔗 Related Intelligence
Product Engineering: When the Line Between PM and Developer Disappears
Multi-Model Fluency: The Career Skill of Knowing Which AI to Use When
How to Find and Evaluate Startup Ideas That Actually Work
The New Startup Playbook: Lessons from Founders Who Built Billion-Dollar Companies in
