Paul Graham Essays Y Combinator Companies

A lot of the advice we give startups is tactical; meant to be helpful on a day to day or week to week basis. But some advice is more fundamental. We’ve collected here what we at YC consider the most important, most transformative advice for startups. Whether common sense or counter-intuitive, the guidance below will help most startups find their path to success.

The first thing we always tell founders is to launch their product right away; for the simple reason that this is the only way to fully understand customers’ problems and whether the product meets their needs. Surprisingly, launching a mediocre product as soon as possible, and then talking to customers and iterating, is much better than waiting to build the “perfect” product. This is true as long as the product contains a “quantum of utility” for customers whose value overwhelms problems any warts might present.

Once launched, we suggest founders do things that don’t scale (Do Things That Don’t Scale by Paul Graham). Many startup advisors persuade startups to scale way too early. This will require the building of technology and processes to support that scaling, which, if premature, will be a waste of time and effort. This strategy often leads to failure and even startup death. Rather, we tell startups to get their first customer by any means necessary, even by manual work that couldn’t be managed for more than ten, much less 100 or 1000 customers. At this stage, founders are still trying to figure out what needs to be built and the best way to do that is talk directly to customers. For example, the Airbnb founders originally offered to “professionally” photograph the homes and apartments of their earliest customers in order to make their listings more attractive to renters. Then, they went and took the photographs themselves. The listings on their site improved, conversions improved, and they had amazing conversations with their customers. This was entirely unscalable, yet proved essential in learning how to build a vibrant marketplace.

Talking to users usually yields a long, complicated list of features to build. One piece of advice that YC partner Paul Buchheit (PB) always gives in this case is to look for the “90/10 solution”. That is, look for a way in which you can accomplish 90% of what you want with only 10% of the work/effort/time. If you search hard for it, there is almost always a 90/10 solution available. Most importantly, a 90% solution to a real customer problem which is available right away, is much better than a 100% solution that takes ages to build.

As companies begin to grow there are often tons of potential distractions. Conferences, dinners, meeting with venture capitalists or large company corporate development types (Don’t Talk to Corp Dev by Paul Graham), chasing after press coverage and so on. (YC co-founder Jessica Livingston created a pretty comprehensive list of the wrong things on which to focus [How Not To Fail by Jessica Livingston .]) We always remind founders not to lose sight that the most important tasks for an early stage company are to write code and talk to users. For any company, software or otherwise, this means that in order to make something people want: you must launch something, talk to your users to see if it serves their needs, and then take their feedback and iterate. These tasks should occupy almost all of your time/focus. For great companies this cycle never ends. Similarly, as your company evolves there will be many times where founders are forced to choose between multiple directions for their company. Sam Altman always points out that it is nearly always better to take the more ambitious path. It is actually extraordinary how often founders manage to avoid tackling these sorts of problems and focus on other things. Sam calls this “fake work”, because it tends to be more fun than real work (The Post YC Slump by Sam Altman).

When it comes to customers most founders don’t realize that they get to choose customers as much as customers get to choose them. We often say that a small group of customers who love you is better than a large group who kind of like you. In other words, recruiting 10 customers who have a burning problem is much better than 1000 customers who have a passing annoyance. It is easy to make mistakes when choosing your customers so sometimes it’s also critical for startups to fire their customers. Some customers can cost way more than they provide in either revenue or learning. For example, Justin.tv/Twitch only became a breakout success when they focused their efforts toward video game broadcasters and away from people trying to stream copy written content (Users You Don’t Want by Michael Seibel.)

Growth is always a focus for startups, since a startup without growth is usually a failure. However, how and when to grow is often misunderstood. YC is sometimes criticised for pushing companies to grow at all costs, but in fact we push companies to talk to their users, build what they want, and iterate quickly. Growth is a natural result of doing these three things successfully. Yet, growth is not always the right choice. If you have not yet made something your customers want – in other words, have found product market fit, it makes little sense to grow (The Real Product Market Fit by Michael Seibel). Poor retention is always the result. Also, if you have an unprofitable product, growth merely drains cash from the company. As PB likes to say, it never makes sense to take 80 cents from a customer and then hand them a dollar back. The fact that unit economics really matter shouldn’t come as a surprise, but too many startups seem to forget this basic fact (Unit Economics by Sam Altman).

Startup founders’ intuition will always be to do more whereas usually the best strategy is almost always to do less, really well. For example, founders are frequently tempted to chase big deals with large companies which represent amazing, company validating relationships. However, deals between large companies and tiny startups seldom end well for the startup. They take too long, cost too much, and often fail completely. One of the hardest things about doing a startup is choosing what to do, since you will always have an infinite list of things that could be done (Startup Priorities by Geoff Ralston). It is vital that very early a startup choose the one or two key metrics it will use to measure success, then founders should choose what to do based nearly exclusively on how the task will impact those metrics. When your early stage product isn’t working it’s often tempting to immediately build new features in order to solve every problem the customer seems to have instead of talking to the customer and focusing only on the most acute problem they have.

Founders often find it surprising to hear that they shouldn’t worry if their company seems badly broken. It turns out that nearly every startup has deep, fundamental issues, even those that will end up being billion dollar companies. Success is not determined by whether you are broken at the beginning, but rather what the founders do about the inevitable problems. Your job as a founder will often seem to be continuously righting a capsized ship. This is normal.

It is very difficult as a new startup founder not to obsess about competition, actual and potential. It turns out that spending any time worrying about your competitors is nearly always a very bad idea. We like to say that startup companies always die of suicide not murder. There will come a time when competitive dynamics are intensely important to the success or failure of your company, but it is highly unlikely to be true in the first year or two.

A few words on fundraising (A Guide to Seed Fundraising by Geoff Ralston). The first, best bit of advice is to raise money as quickly as possible and then get back to work. It is often easy to actually see when a company is fundraising by looking at their growth curve and when it flattens out they are raising money. Equally important is to understand that valuation is not equal to success or even probability of success (Fundraising Rounds are not Milestones by Michael Seibel). Some of Y Combinator’s very best companies raised on tiny initial valuations (Airbnb, Dropbox, Twitch, are all good examples). By the way, it is vital to remember that the money you raise IS NOT your money. You have a fiduciary and ethical/moral duty to spend the money only to improve the prospects of your company.

It is also important to stay sane during the inevitable craziness of startup life. So we always tell founders to make sure they take breaks, spend time with friends and family, get enough sleep and exercise in between bouts of extraordinarily intense, focused work. Lastly, a brief word on failure. It turns out most companies fail fast because founders fall out. The relationships with your cofounders matter more than you think and open, honest communications between founders makes future debacles much less likely. In fact, it turns out that one of the best things you can do to make your startup successful, in fact, to be successful in life, is to simply be nice (Mean People Fail by Paul Graham.)

The Pocket Guide of Essential YC Advice

• Launch now
• Build something people want
• Do things that don’t scale
• Find the 90 / 10 solution
• Find 10-100 customers who love your product
• All startups are badly broken at some point
• Write code – talk to users
• “It’s not your money”
• Growth is the result of a great product not the precursor
• Don’t scale your team/product until you have built something people want
• Valuation is not equal to success or even probability of success
• Avoid long negotiated deals with big customers if you can
• Avoid big company corporate development queries – they will only waste time
• Avoid conferences unless they are the best way to get customers
• Pre-product market fit – do things that don’t scale: remain small/nimble
• Startups can only solve one problem well at any given time
• Founder relationships matter more than you think
• Sometimes you need to fire your customers (they might be killing you)
• Ignore your competitors, you will more likely die of suicide than murder
• Most companies don’t die because they run out of money
• Be nice! Or at least don’t be a jerk
• Get sleep and exercise – take care of yourself


References

Do Things That Don’t Scale by Paul Graham ↩
Don’t Talk to Corp Dev by Paul Graham ↩
How Not To Fail by Jessica Livingston ↩
The Post YC Slump by Sam Altman ↩
Users You Don’t Want by Michael Seibel ↩
The Real Product Market Fit by Michael Seibel ↩
Unit Economics by Sam Altman ↩
Startup Priorities by Geoff Ralston ↩
A Guide to Seed Fundraising by Geoff Ralston. ↩
Fundraising Rounds are not Milestones by Michael Seibel ↩
Mean People Fail by Paul Graham ↩


Recommended Reading

1.A Fundraising Survival Guide by Paul Graham
2.How to Raise Money by Paul Graham
3.Taking Advice by Aaron Harris

Sign up for weekly updates from Y Combinator.

Twice a year Y Combinator takes applications for funding. I thought it might help applicants if I explained what we look for when we read them.

Probably the biggest thing people don't understand about the process is the importance of expressing yourself clearly. Every year we get some applications that are obviously good, some that are obviously bad, and in the middle a huge number where we just can't tell. The idea seems kind of promising, but it's not explained well enough for us to understand it. The founders seem like they might be good, but we don't get a clear enough picture of them to say for sure.

I suspect for every group we invite to interviews, there are one or two more that are just as good but that we pass over because they don't manage to convey how good they are. If that's true, another way to say it is that, of groups good enough to make it to interviews, more than half blow the application.

If we get 1000 applications and have 10 days to read them, we have to read about 100 a day. That means a YC partner who reads your application will on average have already read 50 that day and have 50 more to go. Yours has to stand out. So you have to be exceptionally clear and concise. Whatever you have to say, give it to us right in the first sentence, in the simplest possible terms.

All the YC partners read applications. We each do it separately, to avoid groupthink, so I'm not sure exactly what the others do, but it's probably similar to what I do.

The first question I look at is, "What is your company going to make?" This isn't the question I care most about, but I look at it first because I need something to hang the application on in my mind.

The best answers are the most matter of fact. It's a mistake to use marketing-speak to make your idea sound more exciting. We're immune to marketing-speak; to us it's just noise.1. So don't begin your answer with something like

We are going to transform the relationship between individuals and information.

That sounds impressive, but it conveys nothing. It could be a description of any technology company. Are you going to build a search engine? Database software? A router? I have no idea.

One test of whether you're explaining your idea effectively is to ask how close the reader is to reproducing it. After reading that sentence I'm no closer than I was before, so its content is effectively zero. Another mistake is to begin with a sweeping introductory paragraph about how important the problem is:

Information is the lifeblood of the modern organization. The ability to channel information quickly and efficiently to those who need it is critical to a company's success. A company that achieves an edge in the efficient use of information will, all other things being equal, have a significant edge over competitors.

Again, zero content; after reading this, the reader is no closer to reproducing your project than before. A good answer would be something like:

A database with a wiki-like interface, combined with a graphical UI for controlling who can see and edit what.

I'm not convinced yet that this will be the next Google, but at least I'm starting to engage with it. I'm thinking what such a thing would be like.

One reason founders resist giving matter-of-fact descriptions is that they seem to constrain your potential. "But it's so much more than a database with a wiki UI!" The problem is, the less constraining your description, the less you're saying. So it's better to err on the side of matter-of-factness.

We advise startups presenting at Demo Day to do the same. Better to start with an overly narrow description of your project than try to describe it in its full generality and lose the audience completely. If there's a simple one-sentence description of what you're doing that only conveys half your potential, that's actually pretty good. You're halfway to your destination in just the first sentence.

One good trick for describing a project concisely is to explain it as a variant of something the audience already knows. It's like Wikipedia, but within an organization. It's like an answering service, but for email. It's eBay for jobs. This form of description is wonderfully efficient. Don't worry that it will make your idea seem "derivative." Some of the best ideas in history began by sticking together two existing ideas no one realized could be combined.

After spending 20 seconds or so trying to understand the idea, I skip down to look at the founders. My initial goal is to figure out what kind of group I'm dealing with.

Three friends about to graduate from college? Two colleagues who work together at a big company and want to jump ship? Are they all programmers? A mix of programmers and business people? There are maybe 20 or 30 different configurations of founders.

Once I know what type of group I have, I try to figure out how good an instance of that type it is. The most important question for deciding that is

Please tell us in one or two sentences about something impressive that each founder has built or achieved.

To me this is the most important question on the application. It's deliberately open-ended; there's no one type of answer we're looking for. It could be that you did really well in school, or that you wrote a highly-regarded piece of software, or that you paid your own way through college after leaving home at 16. It's not the type of achievement that matters so much as the magnitude. Succeeding in a startup is, in the most literal sense, extraordinary, so we're looking for people able to do extraordinary things.

As with all questions on the application, the best answers are the most specific. A surprising number of people answer with something like:

Jordan is an exceptionally dedicated person who gives 100% effort to every project he undertakes.

This kind of generic claim carries no weight. A single, specific example would be much more convincing. You probably shouldn't list the startup itself as your most impressive achievement. We already know you've created that. Why waste the opportunity to brag about something else?

If there's no one thing about you that you feel stands out, what should you list? I'd go with whatever you've done that was the hardest—-preferably (though not necessarily) the hardest intellectually. It doesn't matter if it's not the sort of thing you'd put on a resume. We're not looking for the same things as HR departments.

If the founders seem promising, I'll now spend more time trying to understand the idea. I care more about the founders than the idea, because most of the startups we fund will change their idea significantly.

If a group of founders seemed impressive enough, I'd fund them with no idea. But a really good idea will also get our attention—-not because of the idea per se, but because it's evidence the founders are smart.

Just as what we look for in founders is not the type of achievement but the magnitude, what we look for in ideas is not the type of idea but the level of insight you have about it. You're going to start an auction site? That could be a good idea or a bad idea. What matters is how you're going to hold your own against eBay. What's going to be distinctive about your solution?

It's a common mistake to say the distinctive thing about your solution will be that it's well-designed and easy to use. That is not an insight. You're just claiming you're going to execute well. Whoever wrote the current software was presumably also trying to. So you have to be more specific. Exactly what are you going to do that will make your software easier to use? And will that be enough? The reason a lot of big companies' software sucks is that they have some kind of natural monopoly. Unless you have a plan for cracking it, it won't make any difference if yours is better.

We don't mind if you're doing something that will face serious obstacles. In fact, we like that. The best startup ideas are generally outliers that seem crazy to most people initially. But we want to see that you're aware of the obstacles, and have at least a theory about how to overcome them. We'd be delighted to get an application that answered the question "What are you going to make?" with

A new search engine to compete with Google.

so long as this was followed by

We know that sounds impossible, but we think we can get a toehold initially by...

Wouldn't you be interested at this point? Even if the plan had only a 1% chance of working, it would be worth backing. 2.

Whereas if we can see obstacles to your idea that you don't seem to have considered, that's a bad sign. This is your idea. You've had days, at least, to think about it, and we've only had a couple minutes. We shouldn't be able to come up with objections you haven't thought of.

Paradoxically, it is for this reason better to disclose all the flaws in your idea than to try to conceal them. If we think of a problem you don't mention, we'll assume it's because you haven't thought of it. And since we care more about you than the idea, it's a mistake to risk sacrificing yourself to make the idea seem better.

If the founders seem promising and the idea is interesting, I'll now spend a lot more time on the application.

I'll take a look at the video, if there is one. (Statistically we're much more likely to interview people who submit a video.) I'll check out the demo. And I'll look at answers to some of the more mundane questions, like the stock allocation.

If the founders seem promising but the idea doesn't, I check the question near the end that asks what other ideas the founders had. It's quite common for us to fund groups to work on ideas they listed as alternates.

There's one question that acts like a wildcard, at least for me:

Please tell us about the time you most successfully hacked some (non-computer) system to your advantage.

If this wasn't already clear, we're not looking for the sort of obedient, middle-of-the-road people that big companies tend to hire. We're looking for people who like to beat the system. So if the answer to this question is good enough, it will make me go back and take a second look at an application that otherwise seemed unpromising. In fact, I think there are people we've invited to interviews mainly on the strength of their answer to this question.

Generally, the advice I'd give to applicants is: help us out. Investors are optimists. We want to believe you're great. Most people you meet in everyday life don't.

If you go around saying you're going to start the next Google, most people's initial reaction will be skepticism. Partly because the odds of succeeding are low, so skepticism is the safe bet, but also because most people are threatened by ambition: you seem to be trying to put yourself above them, even if that isn't your intention.

Investors are different—-not because they're more generous spirited than other people, but because they get equity. Tell investors you're going to start the next Google and they immediately perk up. They don't default to skepticism, because they like risky bets. And they don't feel like you're trying to put yourself above them, because they hope to be drawn up with you.

Like all investors, we want to believe. So help us believe. If there's something about you that stands out, or some special insight you have into the problem you plan to work on, make sure we see it.

The best way to do that is simply to be concise. You don't have to sell us on you. We'll sell ourselves, if we can just understand you. But every unnecessary word in your application subtracts from the effect of the necessary ones. So before submitting your application, print it out and take a red pen and cross out every word you don't need. And in what's left be as specific and as matter-of-fact as you can.


Example Application

Here's an example of a successful application: Dropbox's Summer 2007 application

One thought on “Paul Graham Essays Y Combinator Companies

Leave a Reply

Your email address will not be published. Required fields are marked *