Paul Graham is a renowned programmer, writer and venture capitalist.
Startups in 13 Sentences
Pick good cofounders
Launch fast
Let your idea evolve (most ideas appear in implementation)
Understand your users (many successful startups make something the founders needed)
Better to make a few users love you than a lot ambivalent
Offer surprisingly good customer service
You make what you measure (measuring something has an uncanny tendency to improve it)
Spend little
Get ramen profitable (just enough to pay the founders’ living expenses)
Avoid distractions (the worst type are those that pay money like day jobs and consulting)
Don’t get demoralized
Don’t give up
Deals fall through
How to Get Startup Ideas
The very best startup ideas tend to have three things in common: they’re something the founders themselves want, that they themselves can build, and that few others realize are worth doing.
It sounds obvious to say you should only work on problems that exist. And yet by far the most common mistake startups make is to solve problems no one has.
You can either build something a large number of people want a small amount, or something a small number of people want a large amount. Choose the latter.
If Mark Zuckerberg had built something that could only ever have appealed to Harvard students, it would not have been a good startup idea. Facebook was a good idea because it started with a small market there was a fast path out of. Colleges are similar enough that if you build a Facebook that works at Harvard, it will work at any college.
It’s even better when you’re both a programmer and the target user, because then the cycle of generating new versions and testing them on users can happen inside one head.
You’re doubly likely to find good problems in another domain: (a) the inhabitants of that domain are not as likely as software people to have already solved their problems with software, and (b) since you come into the new domain totally ignorant, you don’t even know what the status quo is to take it for granted.
It’s exceptionally rare for startups to be killed by competitors — so rare that you can almost discount the possibility. If you have something that no competitor does and that some subset of users urgently need, you have a beachhead.
A crowded market is actually a good sign, because it means both that there’s demand and that none of the existing solutions are good enough.
Do Things that Don’t Scale
The most common unscalable thing founders have to do at the start is to recruit users manually. Nearly all startups have to. You can’t wait for users to come to you. You have to go out and get them.
We encourage every startup to measure their progress by weekly growth rate. If you have 100 users, you need to get 10 more next week to grow 10% a week. And while 110 may not seem much better than 100, if you keep growing at 10% a week you’ll be surprised how big the numbers get. After a year you’ll have 14,000 users, and after 2 years you’ll have 2 million.
You’ll be doing different things when you’re acquiring users a thousand at a time, and growth has to slow down eventually. But if the market exists you can usually start by recruiting users manually and then gradually switch to less manual methods.
How do you find users to recruit manually? If you build something to solve your own problems, then you only have to find your peers, which is usually straightforward. Otherwise you’ll have to make a more deliberate effort to locate the most promising vein of users. The usual way to do that is to get some initial set of users by doing a comparatively untargeted launch, and then to observe which kind seem most enthusiastic, and seek out more like them.
Tim Cook doesn’t send you a hand-written note after you buy a laptop. He can’t. But you can. That’s one advantage of being small: you can provide a level of service no big company can.
A consulting-like technique for recruiting initially lukewarm users is to use your software yourselves on their behalf. We did that at Viaweb. When we approached merchants asking if they wanted to use our software to make online stores, some said no, but they’d let us make one for them. Since we would do anything to get users, we did. We felt pretty lame at the time. Instead of organizing big strategic e-commerce partnerships, we were trying to sell luggage and pens and men’s shirts. But in retrospect it was exactly the right thing to do, because it taught us how it would feel to merchants to use our software. Sometimes the feedback loop was near instantaneous: in the middle of building some merchant’s site I’d find I needed a feature we didn’t have, so I’d spend a couple hours implementing it and then resume building the site.
