Launch early and talk to users: what Paul Graham and YC actually tell founders
Paul Graham wrote in 2006 that launching too slowly has killed far more startups than launching too fast, because you only understand your idea once real users touch it. YC’s version is short: the most important early tasks are to write code and talk to users. Launch something small within weeks, win a few users who love it, and keep learning from them.
Unofficial. Not affiliated with or endorsed by Paul Graham or Y Combinator. Every teaching links to the original essay or talk.
- 1
Why does slowness in launching kill so many startups?
In "The 18 Mistakes That Kill Startups" (October 2006), Paul Graham lists slowness in launching as mistake number 8. Under the next mistake, launching too early, he is blunt about which is worse: "Launching too slowly has probably killed a hundred times more startups than launching too fast."
His reasons: nothing is truly finished until it is released, and it is only by bouncing your idea off users that you fully understand it. He names what slows founders down, including fear of dealing with users, fear of being judged and excessive perfectionism, and says it takes an effort of will to push through and get something released.
Launching too early is a real mistake too, but a much rarer one. The early adopters you need to impress are fairly tolerant. They don’t expect a new product to do everything; it just has to do something.
Key ideaYour product has to do one thing well enough that real people use it. Ship that.
- 2
How fast is fast? Plan a tiny first version
In "Startups in 13 Sentences" (February 2009), "Launch fast" is sentence 2 and "Let your idea evolve" is sentence 3. Graham says the reason to launch fast is not so much that it is critical to get to market early, but that "Launching teaches you what you should have been building." Like an essay, most of the ideas appear while you build.
YC partner Michael Seibel turned this into a method in "How to Plan an MVP" (Startup School, 2019). His line is to launch something bad quickly. Timebox the first version to a few weeks, write the spec down so new features can’t sneak in, and cut features when the deadline slips. Hold the problem and the user tightly; hold the solution loosely.
His examples: Airbnb’s first version had no payments and no map. Twitch began as Justin.tv, a single live channel. Stripe had almost no features, and its founders sometimes went to customers’ offices to integrate it themselves.
A Seibel-style MVP plan on one page Problem: college clubs in Hyderabad lose track of who paid event fees. User: club treasurers. Timebox: 3 weeks. In: a shared list of members, mark paid or unpaid, a UPI link per event. Out (for now): login, reports, reminders, a mobile app. Launch: hand it to 5 treasurers on day 21, whatever state it is in. - 3
Should you aim for many users, or a few who love you?
A few who love you. "Startups in 13 Sentences" opens with a principle Graham credits to Paul Buchheit, Gmail’s creator and later a YC partner: it is better to make a few people really happy than to make a lot of people semi-happy. Sentence 5 says the same: "Better to make a few users love you than a lot ambivalent."
Early on, Graham says, you must choose between meeting all the needs of a small group or some of the needs of everyone. Take the first, because it is easier to expand userwise than satisfactionwise.
YC’s 2017 pocket guide, written up by Geoff Ralston, puts a number on it: "Find 10-100 customers who love your product." He adds that 10 customers with a burning problem are better than 1,000 with a passing annoyance.
Key ideaTen users who would be upset if you shut down beat a thousand who signed up and forgot.
- 4
Why does YC keep saying "talk to users"?
Ralston’s YC pocket guide lists "Write code – talk to users" and explains that the most important tasks for an early stage company are to write code and talk to users. Everything else is secondary until you have something people want.
Graham ends "Startups in 13 Sentences" by asking which one sentence he would keep. His answer: "Understand your users. That’s the key." He pictures the wealth a startup creates as a rectangle: one side is how many users you have, the other is how much you improve their lives, which he says is the side you have most control over.
In "The 18 Mistakes" he says you need a specific user in mind, and you have to be able to talk some specific ones into using what you make; if you can’t, you are on the wrong track. In "What I’ve Learned from Users" (September 2022) he gives a test for founders: would you use this yourself if you hadn’t built it?
- Talk to users
- Write code
- Ship
- Watch them use it
- Talk to users again
- 5
How do you talk to users without fooling yourself?
In YC’s "How To Talk To Users" (Startup School, December 2022), group partner Gustaf Alströmer says a short video call teaches more than thousands of survey responses. Your job in the interview is to listen, not to pitch. Hold back your idea until the end, if you mention it at all.
Ask about what people do today and what is hard about it. Avoid questions that invite polite lies, such as whether they would use your product, or which features they want. He suggests doing five to ten interviews, then grouping your notes by problem and building the smallest thing that fixes the most important one.
Questions from the YC talk, lightly edited 1. Tell me how you do X today. 2. What is the hardest thing about doing X? 3. Why is that hard? 4. How often do you have to do X? 5. Why is it important for you to do X? 6. What do you do to solve this problem today? Follow-ups: "What do you mean by that?", "Can you tell me more about that?" Avoid: "Would you use our product?", "Which features should we add?", and any yes or no question. - 6
Is launch day the big moment? No, you launch again and again
Graham warns in "Do Things that Don’t Scale" (2013) that the Big Launch usually doesn’t work. In "How to Launch (Again and Again)" (Startup School, 2019), YC’s Kat Mañalac treats launching as something you keep doing, not one day you polish for months.
Her practical steps: start with a silent launch, a simple page with your name, a one-line pitch and a way to sign up. Move past friends and family quickly to strangers who match your user. Post in the online communities where those users already are, follow each community’s rules, and write like a person rather than a marketer. Build an email list from everyone you talk to, so each new launch has people ready to hear about it.
- This week: put up a one-page site with a one-line pitch and a signup form.
- Post it in one community your users read, written in plain words.
- Email every signup personally and ask for a 15-minute call.
- Plan your next small launch, a new feature, two to four weeks out.
Straight from the source
What Paul Graham or YC actually wrote or said, taken apart, then what to do with it this week.
- 1 · Understand
- Slowness in launching is one of the most common ways startups die, much more common than launching too early, because you only fully understand your idea once users react to it.
- 2 · Break it down
- Nothing is finished until it is released, so an unlaunched product is an unfinished one.
- The early adopters you need are tolerant: the product just has to do something.
- You need a specific user in mind, and you should be able to talk some of them into using it.
- When deciding whether to change direction, ask your users. If they are excited about the new direction, it is probably a good bet.
- 3 · Use it
- Pick a launch date within weeks, decide the one thing the product must do by then, and cut everything else.
- 1 · Understand
- Launch something bad quickly, get some customers, and improve it by talking to them. The first version is a step, not the product.
- 2 · Break it down
- Timebox the build to a few weeks and write the spec down so features can’t creep in.
- When the date slips, cut features rather than moving the date.
- Keep the problem and the user fixed; change the solution when it fails.
- Airbnb, Twitch and Stripe all started with tiny, rough first versions.
- 3 · Use it
- Write your MVP spec on one page today with an "out for now" list at least as long as the "in" list.
Words to know
- MVP (minimum viable product)
- The smallest first version that real users can use. Michael Seibel’s advice is to timebox it, write the spec down and cut features to ship on time.
- Early adopters
- The first users of a new product. Graham says they are fairly tolerant: the product just has to do something useful.
- Talk to users
- YC’s shorthand for the core early job: alongside writing code, learn directly from the people who have the problem.
- Silent launch
- Kat Mañalac’s term for a first, quiet launch: a simple page with your company name, a short pitch and a way to sign up.
- Expand userwise vs satisfactionwise
- Graham’s point that it is easier to win more users like the ones who love you than to make lukewarm users love you.
Watch
Hand-picked from the people who explain this best. The video loads only when you press play.
A practical launch checklist from YC. Focus on the silent launch and on posting in communities without sounding like an ad.
YC’s Gustaf Alströmer on running user interviews. Write down his questions to ask and to avoid, then use them this week.
Put it into practice
Five user conversations and a three-week launch plan
- 1Pick one specific user, for example "final-year engineering students applying for internships", not "students".
- 2Book five 15-minute calls with people who match. Use your network first, then communities they use.
- 3Ask only the questions from step 5 of this lesson. Do not describe your idea until the last two minutes.
- 4After the calls, group your notes by problem. Circle the problem that came up most and hurt most.
- 5Write a one-page MVP plan: the problem, the user, a three-week timebox, what is in, and what is out.
- 6Put a date on your calendar, three weeks out, when you will hand it to those five people whatever state it is in.
Check yourself
Pick an answer to see if you are right, and why.
Done? Keep going
Mark this lesson complete to keep your place. Progress is saved on this device, no login.
Questions people ask
How early should a startup launch?
As early as the product does one useful thing. Paul Graham says launching too slowly has killed far more startups than launching too fast, and YC’s Michael Seibel suggests timeboxing the first version to a few weeks.
Who said "make a few users love you"?
Paul Graham, in "Startups in 13 Sentences" (2009): "Better to make a few users love you than a lot ambivalent." He credits the idea to Paul Buchheit, who said it is better to make a few people really happy than a lot semi-happy.
What does YC mean by "write code, talk to users"?
YC’s essential advice, written up by Geoff Ralston in 2017, says the most important tasks for an early stage company are to write code and talk to users. Most other work can wait until people want what you make.
Sources and further reading
- Paul Graham: The 18 Mistakes That Kill Startups (October 2006)
- Paul Graham: Startups in 13 Sentences (February 2009)
- Paul Graham: What I’ve Learned from Users (September 2022)
- Paul Graham: Do Things that Don’t Scale (July 2013)
- Geoff Ralston, YC’s Essential Startup Advice (YC blog, September 2017)
- Michael Seibel: How to Plan an MVP (Y Combinator, 2019)
- Kat Mañalac: How to Launch (Again and Again) (Y Combinator, 2019)
- Gustaf Alströmer: How To Talk To Users, Startup School (Y Combinator, 2022)