Do things that don't scale

By Paul Graham

Actually startups take off because the founders make them take off (Location 9)

You can't wait for users to come to you. (Location 12)

There are two reasons founders resist going out and recruiting users individually. One is a combination of shyness and laziness. They'd rather sit at home writing code than go out and talk to a bunch of strangers and probably be rejected by most of them. (Location 18)

This can't be how the big, famous startups got started, they think. The mistake they make is to underestimate the power of compound growth. (Location 21)

We encourage every startup to measure their progress by weekly growth rate. (Location 22)

And that's one of the biggest things inexperienced founders and investors (and reporters and know-it-alls on forums) get wrong about them. (Location 32)

They unconsciously judge larval startups by the standards of established ones. They're like someone looking at a newborn baby and concluding "there's no way this tiny creature could ever accomplish anything." (Location 33)

The big danger is that you'll dismiss your startup yourself. (Location 36)

The question to ask about an early stage startup is not "is this company taking over the world?" but "how big could this company get if the founders did the right things? (Location 39)

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. (Location 45)

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. (Location 47)

You should take extraordinary measures not just to acquire users, but also to make them happy. (Location 50)

Your first users should feel that signing up with you was one of the best choices they ever made. (Location 51)

Why do we have to teach startups this? Why is it counterintuitive for founders? Three reasons, I think. One is that a lot of startup founders are trained as engineers, and customer service is not part of the training of engineers. (Location 52)

Another reason founders don't focus enough on individual customers is that they worry it won't scale. (Location 57)

But when founders of larval startups worry about this, I point out that in their current state they have nothing to lose. (Location 58)

you'll find that delighting customers scales better than you expected. Partly because you can usually find ways to make anything scale more than you would have predicted, and partly because delighting customers will by then have permeated your culture. (Location 60)

But perhaps the biggest thing preventing founders from realizing how attentive they could be to their users is that they've never experienced such attention themselves. (Location 63)

Their standards for customer service have been set by the companies they've been customers of, which are mostly big ones. 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. [ (Location 64)

It's not the product that should be insanely great, but the experience of being your user. (Location 75)

For a big company it's necessarily the dominant one. But you can and should give users an insanely great experience with an early, incomplete, buggy product, if you make up the difference with attentiveness. (Location 76)

Note: Awesome

Even if you start the way most successful startups have, by building something you yourself need, the first thing you build is never quite right. (Location 79)

In software, especially, it usually works best to get something in front of users as soon as it has a quantum of utility, and then see what they do with it. (Location 81)

Perfectionism is often an excuse for procrastination, and in any case your initial model of users is always inaccurate, even if you're one of them. (Location 82)

The feedback you get from engaging directly with your earliest users will be the best you ever get. (Location 84)

Any startup that could be described as a marketplace usually has to start in a subset of the market, but this can work for other startups as well (Location 91)

Most startups that use the contained fire strategy do it unconsciously. They build something for themselves and their friends, who happen to be the early adopters, and only realize later that they could offer it to a broader market. (Location 93)

Among companies, the best early adopters are usually other startups. (Location 97)

advantages of the YC model (and specifically of making YC big (Location 99)

But even so I'd advise startups to pull a Meraki initially if they can. That's what Pebble did. The Pebbles assembled the first several hundred watches themselves. (Location 106)

Like paying excessive attention to early customers, fabricating things yourself turns out to be valuable for hardware startups. (Location 108)

Sometimes we advise founders of B2B startups to take over-engagement to an extreme, and to pick a single user and act as if they were consultants building something just for that one user (Location 111)

The initial user serves as the form for your mold; keep tweaking till you fit their needs perfectly, and you'll usually find you've made something other users want too. (Location 112)

As long as you can find just one user who really needs something and can act on that need, you've got a toehold in making something people want, and that's as much as any startup needs initially. (Location 114)

So long as you're a product company that's merely being extra attentive to a customer, they're very grateful even if you don't solve all their problems. (Location 117)

But when they start paying you specifically for that attentiveness — when they start paying you by the hour — they expect you to do everything. (Location 118)

Another consulting-like technique for recruiting initially lukewarm users is to use your software yourselves on their behalf. (Location 119)

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. (Location 122)

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. Manual (Location 123)

When you only have a small number of users, you can sometimes get away with doing by hand things that you plan to automate later. This lets you launch faster, and when you do finally automate yourself out of the loop, you'll know exactly what to build because you'll have muscle memory from doing it yourself. (Location 125)

Some startups could be entirely manual at first. If you can find someone with a problem that needs solving and you can solve it manually, go ahead and do that for as long as you can, and then gradually automate the bottlenecks. (Location 130)

It would be a little frightening to be solving users' problems in a way that wasn't yet automatic, but less frightening than the far more common case of having something automatic that doesn't yet solve anyone's problems. (Location 131)

I occasionally meet founders who seem to believe startups are projectiles rather than powered aircraft, and that they'll make it big if and only if they're launched with sufficient initial velocity. (Location 133)

How well you're doing a few months later will depend more on how happy you made those users than how many there were of them. (Location 137)

do founders think launches matter? A combination of solipsism and laziness. They think what they're building is so great that everyone who hears about it will immediately sign up (Location 138)

even if what you're building really is great, getting users will always be a gradual process — partly because great things are usually also novel, but mainly because users have other things to think about. (Location 141)

It's not enough just to do something extraordinary initially. You have to make an extraordinary effort initially. Any strategy that omits the effort — whether it's expecting a big launch to get you users, or a big partner — is ipso facto suspect. (Location 145)

The need to do something unscalably laborious to get started is so nearly universal that it might be a good idea to stop thinking of startup ideas as scalars (Location 147)

Instead we should try thinking of them as pairs of what you're going to build, plus the unscalable thing(s) you're going to do initially to get the company going. (Location 148)

But in most cases the second component will be what it usually is — recruit users manually and give them an overwhelmingly good experience — and the main benefit of treating startups as vectors will be to remind founders they need to work hard in two dimensions. (Location 150)

In the best case, both components of the vector contribute to your company's DNA: the unscalable things you have to do to get started are not merely a necessary evil, but change the company permanently for the better. If you have to be aggressive about user acquisition when you're small, you'll probably still be aggressive when you're big. If you have to manufacture your own hardware, or use your software on users's behalf, you'll learn things you couldn't have learned otherwise. (Location 152)

And most importantly, if you have to work hard to delight users when you only have a handful of them, you'll keep doing it when you have a lot. (Location 156)