Interview with YC Founder: Exploring Factors Behind Startup Success and Failure
TechFlow Selected TechFlow Selected
Interview with YC Founder: Exploring Factors Behind Startup Success and Failure
Act boldly and seize opportunities promptly, or you may miss your chance.
Navigating Web3 tides with focused insightsCompiled by: TechFlow
Note: This article is part of the TechFlow special series "YC Startup Class Chinese Notes" (updated daily), dedicated to collecting and organizing Chinese translations of YC course content. This third installment features Paul Graham, founder of YC, in his online lecture "A Conversation with Paul Graham".
Geoff Ralston:
Paul Graham founded Y Combinator in 2005. Paul, back in the mid-90s—long before SaaS became a thing—you envisioned something people would want that was related to what we now call SaaS. How did you come up with the idea that eventually led Yahoo to acquire your startup?
Paul Graham:
In the mid-90s, there was a general assumption that writing software meant writing software for client machines. For those who remember that era, "client" usually meant Windows.
But we didn't want to learn how to write software for Windows—we were only familiar with Unix. So we were desperately looking for a way to write software without having to target the Windows platform.
We started experimenting on our own. Initially, we tried sending website updates via email. But then we realized—if we can use SMTP, why not use HTTP to update websites? By running software on a server and controlling it through links in a browser, we finally found a solution.
This idea initially seemed very strange—even we weren’t sure it would work. But we went ahead and built a clunky website builder that operated via clickable links. It was rough, but it worked and could actually build websites.
At that point, we had successfully avoided the need to write software for Windows.
Geoff Ralston:
Of course, innovation often comes from thinking differently. I mean, today many websites follow similar workflows, so they lack innovation. But if you can build an entirely new website or product from scratch, that's real innovation. Do you have plans like that?
Paul Graham:
That idea is very common, but it’s often a retrospective analysis by historians—they can see all the twists and turns in hindsight, making things look obvious.
I always hate it when people describe startup ideas as light bulbs going off. Not only is it the most clichéd metaphor, it's also wrong.
It's not like you just get this idea and realize it, right? More often, you have this sense... you're doing something no one else has done before, which might be a bad idea, but you’re too lazy to learn otherwise, so you go ahead anyway. Like Zuckerberg starting Facebook.
It’s more like, let’s see what happens, right? That will always be a startup—it's truly incredible.
Geoff Ralston:
That’s good for everyone. Hopefully some of your ideas seem really unbelievable.
Paul Graham:
I love it when an idea seems unbelievable. This happened frequently during my hacker days, but even more so in recent years working with startups. Just yesterday, I talked to some people who mentioned two things they could do.
One of them felt a bit... mischievous.
Not abusive to anyone, but exploiting something that seems impossible, right? Like running software on a server while users feel like it’s running on their own machine—interacting solely through a browser.
That kind of idea does feel a bit cheeky.
But I advised them to go with that idea precisely because it seems so outlandish and absurd.
Geoff Ralston:
There seem to be many ways to talk about a good idea, but when you try to match the idea with reality, it always gets complicated... like whether the idea feels a bit cheeky, or whether it’s counterintuitive or non-obvious. Also, it's hard to take any specific idea and say, “This has potential.”
Paul Graham:
Actually, you don’t know that at another level. The future of startups is hard to predict—it’s inherently uncertain. Even though Y Combinator is pretty good at selecting startups, maybe only five out of every 150 will become giants or something similar.
What counts as a "giant" depends on your perspective. Regardless, even if you could pick perfectly, you couldn’t guarantee only five startups per batch—you might need to select 20.
Being a hacker helps because business opportunities are hard to predict, but if you’re a hacker, you can just try things for fun.
Sometimes laziness actually helps, but the meme has escaped into the wild and is considered bad—which might be better because laziness leads people to do good things, even if they think it’s bad.
Geoff Ralston:
Yet sometimes people do things silently for certain reasons. Though we tend to call it laziness, it’s not exactly that. We often avoid doing things that seem meaningless, which makes us more elegant—especially for those naturally averse to pointless actions. That’s why in 1995, I tried building my own web business using every idea I had and did everything myself. The situation was terrifying because I didn’t know what I was doing, so I looked for others to help—but I wasn’t sure if they’d make good co-founders.
Hearing your story reminded me of when you slept on Robert’s floor. You met Trevor Blackwell and Robert Morris online—how did you decide to bring them on as co-founders? What was that process like? When did you commit to making them partners?
Paul Graham:
They were extremely capable co-founders with exceptional programming skills. Still, I recall Robert didn’t stay fully involved throughout the entire startup journey. Whenever he attended board meetings or we received acquisition offers, the board had to seriously consider whether to accept. That meant we faced some shady acquisition proposals.
For example, “We’ll offer you two million dollars in stock, how about it?” Robert would often say: “Let’s vote—I have to be honest, at least we could stop working.” Yet, we still ended up accepting those deals. I once made a deal with Robert: if he earned $1 million online, I’d give him a pair of earrings as a reward.
But Robert didn’t like wearing earrings, so after the deal, Trevor “Frog” and I took him to Harvard Square to buy a pair. Robert ended up wearing new earrings. There are already photos of Robert with earrings online—it won’t be long before people notice. While I never intended to highlight this, I think he looks good with earrings.
The reason I chose Robert as a partner was because he was my accomplice in everything—not because I was the leader and he was just my deputy. When he took on tasks, I became his accomplice too—just like during the 1988 internet worm crisis.
Geoff Ralston:You know, Robert Morris is famous all on his own?
Paul Graham:
He invented buffer overflow. I remember when he told me the idea, I said, “Wow, cool idea—you should totally do it.”
He was the first famous hacker to really get into trouble—prosecuted in 1986, becoming the first felony conviction under the Computer Fraud and Abuse Act.
So, if you're looking for a co-founder, check out people who’ve been prosecuted for their work. Interestingly, for the FBI and law enforcement, motives like sex, drugs, money, and revenge are common, but Robert did it purely out of curiosity—outside that list. In fact, authorities struggled to understand what happened, even within the government. That’s why I chose Robert as a partner—I’d do anything with him. We had many plans, and he was an outstanding programmer who could type as fast as possible.
Even though C code is verbose, he could quickly edit source files and recompile to achieve what he wanted.
At Harvard, undergraduates could only have accounts on the official undergraduate computing system at the Science Center, while the actual powerful computers were in Aiken Lab’s CS department. So when Robert wanted to set up his own account on proper machines, he’d switch to a separate user as superuser on a machine, then switch back. He was deeply curious and wanted access to the right machines.
Throughout all this, Robert was central. He’s a fascinating figure—he got expelled for reconnecting Harvard to the internet. When Robert was an undergrad, Harvard was an early internet node but lost connectivity due to bit decay. RTM spent an entire semester getting Harvard back online. Despite poor academic performance and being expelled for a year, we later saw this experience as a hiring advantage.
We posted a flyer around campus asking if anyone had ever been expelled for a project because we wanted to hire them. Eventually, we found an excellent programmer who profited greatly since we were acquired that year. He’s now enjoying life and probably won’t return before age 25.
A month later, after working at the company for a full month, Robert turned rebellious. He said, “We’ve been working here a whole month, but haven’t finished.” I started wondering what kind of world we’d entered—maybe we needed more programmers.
So I asked, “Okay Robert, who’s the smartest person you know in grad school?” He replied, “Trevor.” I was surprised—“Really? Trevor?” Because Trevor didn’t seem like the brilliant type.
But Trevor turned out to be exceptionally smart, so we recruited him. He joined quickly and demonstrated super-efficient hacking skills. If Robert said he was the smartest, he absolutely was.
But this taught a profound lesson: when hiring or choosing partners, find someone you trust, then find someone they trust. Some qualities matter more than others. Smart people can judge other smart people, but trustworthy people cannot judge other trustworthy people. In fact, trustworthy people are often fooled by untrustworthy ones.
Like our architect Kate—she’s highly trustworthy but constantly tricked by scheming manipulators. So if you want such people as trusted co-founders, you must prioritize this judgment.
The whole internet operates this way—there must be someone responsible for judging trustworthiness. That’s not my strength. At Y Combinator, social radar Jessica handles this.
Finally, I also hired employees through the via website.
Geoff Ralston:
What lessons did you learn from hiring in your first startup? You know, if they don’t perform well because they’re working on a project, it’s understandable. That feels counterintuitive.
At YC, we often take counterintuitive approaches.
Paul Graham:
Generally speaking, startups are extremely, profoundly counterintuitive. That’s why YC exists. If it were obvious what to do in startups, we wouldn’t have so much to teach, right? So our job is to tell founders what to ignore. We advise against rushing to hire, yet they often impulsively hire and later reflect, “Oh, I wish we’d listened.” But all our advice goes against intuition—it’s not obvious.
Something counterintuitive sounds like it’s wrong. So they follow their instincts and do the wrong thing, hoping to catch and fix it early.
You know, writing an article about why startups are so counterintuitive would be very meaningful. It’s worth writing.
Why are startups so counterintuitive? I don’t know.
I could theorize, but I suspect the answer is complex and interesting enough that I’m unlikely to find a simple explanation.
Geoff Ralston:
I mean, even discussing you writing such an article feels counterintuitive.
When you started your venture, you felt great—you wrote extensively about software that helped you grow, and you even wrote an article telling people not to do things that couldn’t scale.
Paul Graham:
Yes, I believe you’ve all read Paul’s essays. But there’s a crucial point particularly relevant to the challenges most face in early-stage startups. It’s YC’s motto: “Don’t do too much at first—instead, do things that don’t scale.”
“Yes, oh yes, absolutely correct.” We might think we’re doing something wrong or our idea sucks, but actually not. We once built software for creating online stores. You could use it to build your own e-commerce site and start selling. When we pitched to potential customers, they’d typically reply, “Do you want to use our simple online store builder?” Most said no. But they still needed an online store, so we’d ask, “Would you like to have an online store?” Then they’d say, “Yes.” Finally, we’d say, “Okay, if we use our software to create an online store for you, you’ll own it. Sounds good?”
Though awkward, it proved effective—a direct marketing method. We were even members of the Direct Marketing Association (DMA). In every industry, businesses have internal names not used externally. Fast food is called “fast casual.” Catalog businesses are “direct mail.” So we were DMA catalog members, logging every mailing. You know those catalogs in the mail? We just sent a letter and got more. Now we have a shelf full of catalogs.
Geoff Ralston:
Yes, it seems like you’re trying to build a new search engine. In that case, you’d set up your servers, manually run all searches, and present results. This helps you deeply understand every step of the search process.
I think about our early work on email services—we started manually too.
We had a manual ad server—no real ad tech. We just coded and added ads to the server. Imperfect, but it taught us a vital lesson: if you think you’ve found a solution and built a lot around it, you’re likely wrong because you don’t yet know all the details and problems.
Therefore, doing things manually helps you deeply understand the process and discover better solutions.
Paul Graham:
I’d use our software to build others’ websites, helping me better understand its performance. Actually, I was the author of that website builder.
So I’d use the software to think through issues, but sometimes found it inconvenient. While building sites for others, I’d modify the software as needed—just like running server-based software. For instance, I’d use the “ship” command (Unix mv) instead of CP.
This allowed me to improve the software while building websites, refining it continuously. So when choosing co-founders, pick people you trust completely. This advice helps many, especially founders going solo.
Geoff Ralston: Why is being a sole founder so difficult?
Paul Graham:
There are many reasons, but I think the hardest part is morale. No one can maintain high spirits when things go badly—even with a team, they can’t keep you happy all the time. Especially for startups, most companies either fail or succeed.
If you succeed, you get rich.
But in the beginning, you only have 10 customers, aiming for 20% growth. Next week you want 10% more. Growing 10% weekly is ambitious. But we just need one more customer. You can go get it yourself, right? Then next week you’ll have 11 customers—you must have 1.1 customers, right?
That’s basically one customer, right? As long as you persist and maintain growth, the exact number doesn’t matter—consistent growth means exponential growth, and the base will soon solve itself.
Geoff Ralston:
What factors drive a company to succeed, and what causes failure? Perhaps we can discuss issues like how employees understand their roles and performance. In startup land, thousands of companies are trying to figure out their next move—whether they’re heading in the right direction or stuck in failure.
Paul Graham:
The main reason companies fail is poor execution by founders. As a startup, we often talk to people obsessed with competitors. One advantage of YC funding many companies is access to a large dataset. Do you know how many companies are defeated by competitors? Since 1900, how many times? I tell startups that protection from competitors is like light aircraft avoiding collisions in clouds. You know what that protection means? Space is vast. Small Cessnas have no radar and can’t see in clouds. It’s like suddenly encountering someone on another track in a 100-meter race.
So what should you do? Run as fast as possible—because if they’re stronger, they’ll win; otherwise, you will. I wouldn’t try founding alone because I think it’s impossible. You need a solid, cohesive founding team that knows and collaborates with each other.
We can give two types of answers. For investors, we can explain how to pick startups, but only some advice helps founders. We can tell investors to choose smart people, but founders are already as smart as anyone. If they’re already smart, how do we help them get smarter? Actually, intelligence isn’t key—determination is.
Suppose someone scores 100 IQ points and 100 determination points. If you lose determination, you quickly become a useless smart person. But if you partner with someone super-determined, you can gradually become smarter. Eventually, you might meet someone with many taxi medals but still wealthy, or doing garbage collection, yet you can learn smart things from them.
Geoff Ralston:
It depends on how closely tied you are to that person—you must be able to move forward together. Otherwise, they’ll leave.
But I think another important factor is your ability to play a role in the team, because your ideas might be bad—and get worse. So you must be able to think about where we should head.
You need some creativity to make the right choices, and...
Paul Graham:
Actually, you may not need much creativity. If you pay enough attention to users, you can satisfy their needs like a scientist seeking truth. Ultimately, your product ideas evolve organically, almost without deliberate thought—it’s evolution. So either you’re like Steve Jobs, intuitively knowing what customers need, or you just need the skill to talk to customers and understand their needs, which aren’t always obvious.
Well, you know Steve Jobs succeeded partly because he was also a customer—with deep insight into user needs.
For example, he might think phone jacks are outdated and no longer necessary for everyone.
Steve Jobs’ success may simply stem from his ordinary desires—common to everyone. He lived in the future. But apart from reading the New York Times, he didn’t like the internet much, so he never truly mastered it.
In business, determination is critical—but not necessarily in early stages. A common mistake is not paying enough attention to users. Sometimes an idea forms in your head—that’s your vision.
You spend hours alone in cafes thinking and building your vision, writing elaborate documents. But if you don’t talk to potential users, you’ll likely hit sales problems—the main reason many give up. Instead, find anyone with a need willing to pay to solve it, and help them find more like them.
Better yet, if you have the problem yourself. But you must launch quickly—otherwise, delayed feedback will embarrass you. When users tell you your product isn’t as good as expected, you might feel shame and discomfort, but only through this can you continuously improve. So moving forward, actively engage users to refine your product.
Geoff Ralston:
I remember when I joined Y Combinator, they launched Imagine K12—the education-tech version of YC. When I spoke with Paul, he asked, “How’s Imagine K12 going?” Since he’d helped us a lot, I said, “Going well…”
Then he asked, “When are you launching?” I replied, “We’re finalizing PR plans and software development—probably around February.” But he suggested launching immediately—why not start now? I hesitated, yet his words moved me.
Eventually, we launched within a week.
That’s the mistake you make—waiting too long brings embarrassment. You must act boldly and seize opportunities—otherwise, you’ll miss them.
Paul Graham:
We launched the YC website in under a week. Of course, we had no software initially—just an ASCII form people filled out and emailed to us. The first two batches applied via email. We printed the emails, passed them to partners, and scored them on paper—that was our application process.
Geoff Ralston:
We once discussed doing things that don’t scale, but now we’re trying to do this with thousands of applications—it’s harder. So we need scalable software systems, which is exactly what we’ve been building.
Paul Graham:
Ultimately, once you know what software to build, you build it. While it’s fun to talk about how YC started, I don’t think that’s the most important thing.
Speaker A:As a co-founder, how do you handle differing commitment levels? And if you must fire a co-founder, how should you do it?
Paul Graham:
To handle differing commitment levels, ask yourself: Would I rather have 30% of someone, or 100% of someone else? Personally, I’d prefer 10% of Robert Morris’s brain over nearly anyone else’s entire brain.
So it’s a relatively simple decision.
One approach is ensuring someone holds more equity than others. Usually equity is equal, but sometimes not—for example, 51% vs. 49%, giving the majority holder control.
Speaker B: How many people should you release a private beta to?
Paul Graham:
Some might think releasing a private beta is sufficient, no need to go public. For me, I prefer releasing privately to just a few people—it’s closer to a full launch than sitting in a cafe pondering your idea.
Speaker C: What do you think of current fundraising and project structures? Are some projects overfunded, or fundamentally underfunded relative to their goals?
Paul Graham:
I know nothing about cryptocurrency, but I hear massive amounts are circulating. So if money is flowing, startups trying to raise funds is usually a good idea. Beyond that, I don’t know much. But one thing we often see at Y Combinator is that raising too much money isn’t always right.
Even if you don’t need much, sitting on large sums creates gravitational pull—you’ll spend it fast, possibly making foolish decisions. For example, some companies raised $1 billion in ICOs, but I’m unsure they can become real companies. Or you might get a bunch of LPs, raise $1 billion, then hire far more people than needed. That’s often unfair—that’s how ICOs differ from other methods.
Of course, having $1 billion with almost no idea is unwise—like Theranos raising $2.3 billion yet seemingly achieving nothing.
Speaker D: What’s your best advice for conducting excellent user interviews?
Paul Graham:
The best technique is not just understanding their thoughts, but why they might be mistaken. Ask what’s missing in their lives, then propose hypotheses—what if they could do X or Y? This reveals deeper intentions and needs. Finally, the author suggests discussing these insights with others.
Speaker E: You said launch early, right? How do you justify the financial risk and turmoil from launching a bad product?
Paul Graham:
Delaying launch carries risk, but launching too late carries greater risk. So you need a heuristic or rule for when to launch. This describes the characteristics of a minimum viable product, but usefulness is the metric. Once your product reaches a certain utility level—when at least one person is delighted and can do something previously impossible—you can launch. If your product generates no interest or reaction, you’re not ready. Paul Buchheit says if 10 people truly love your product, that’s a good start. As long as those 10 are passionate, you can launch—others’ opinions don’t matter.
Speaker F: Can you discuss the difference between building what they want versus what customers need? Often needs are short-sighted, while real needs might be what people want—but with unforeseen consequences. So how do you balance building what customers truly need versus what they truly want?
Paul Graham:
Ideally, we want to build something people choose to use, buy, or become users of. But sometimes people buy what they don’t truly need—so there’s a gap between need and want.
For example, people need healthy food, but often buy unhealthy options. As entrepreneurs, we must balance fulfilling needs versus desires. We want our products to meet needs and be attractive. But we can’t greedily cater only to market demand at the expense of customer well-being. Nor can we impose our assumptions—thinking we know their needs better than they do.
Therefore, we must clarify whether our product genuinely meets customers’ needs and wants—not just chase market trends. We must carefully balance both to successfully build a popular product.
Speaker G: How do you become a good founder?
Paul Graham:
As a founder, seeing multiple solutions is normal. When choosing, pick the one you believe will be used fastest. This requires combining positive and negative traits.
Positively, it involves determination and willingness to try new things. But there are negative aspects too. For example, if you’ve worked at a big company for 20 years, unless visa issues force you, you’re unlikely to be a good founder. If you had the potential, you wouldn’t have stayed so long.
In fact, we’ve noticed alumni from certain companies often become less successful founders. Because to be a great founder, you couldn’t have worked long-term at those companies. So when choosing, seek the best path and avoid excessive negativity.
Speaker H: Is there a pricing strategy when launching a product, and how should you price during launch?
Paul Graham:
If you understand your business, you usually know what to charge—just guess. To be more scientific, talk to potential users about pricing. You’ll have some tame customers—real users who are also friends, acquaintances, or family—ask them.
Sure, there’s a cost. But you can always change prices later. Lowering prices draws no complaints. Raising prices affects only a small portion of existing users—and if your user base grows exponentially, it won’t matter. So don’t stress. Start with a price that attracts customers—they’ll teach you valuable lessons. Change prices later. Never start high—you need customers first, not high prices. Customers educate you and provide feedback—early customers don’t just give money, they help you grow.
Speaker I: How do you find angel investors and work with them?
Paul Graham:
Fundraising is an important consideration for founders, but often overrated. Don’t spend all your time on it—it distracts. If you don’t know how to find angels, attend startup events, though those angels may not be ideal. Actually, organizations like Y Combinator help startups attract angels.
If you can’t find angels, what then? It’s like asking a pilot how to walk on the ground. Angels usually come to you—go out and meet them. Best is finding someone working at a startup who can introduce you to their investors.
Speaker J: In Silicon Valley, there’s a trend of companies hiring people without college degrees. Is YC considering funding high school students?
Paul Graham:
Whether to fund high schoolers—I’m not sure, since I no longer represent YC’s thinking. But I don’t think it’s a good idea. While some high schoolers might succeed, they shouldn’t do it. Just because you can start a successful company doesn’t mean you should. Starting a successful company ends the free, imaginative days of your life. I think in high school or college, you should explore your options—not randomly pick one and stick with it. Those who drop out to start companies, like Harvard dropouts, are extremely rare. Most need breadth, need fallbacks—not to become startup founders.
We’ll fund people giving 100% in college—or even high school. Otherwise, we won’t fund them. Though the trend is to go straight to work, between ages 18–22, you’re still growing personally, humanly. Doing many different things together is great at that age. But starting a startup is like grabbing a dragon’s tail—if it works. So be careful at any stage of life and make wise decisions.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
深潮TechFlow
