|  
  
|  **Want to start a startup?** Get funded by Y Combinator.  
  
---  
  
July 2013  
  
One of the most common types of advice we give at Y Combinator is to do things
that don't scale. A lot of would-be founders believe that startups either take
off or don't. You build something, make it available, and if you've made a
better mousetrap, people beat a path to your door as promised. Or they don't,
in which case the market must not exist.   
  
Actually startups take off because the founders make them take off. There may
be a handful that just grew by themselves, but usually it takes some sort of
push to get them going. A good metaphor would be the cranks that car engines
had before they got electric starters. Once the engine was going, it would
keep going, but there was a separate and laborious process to get it going.  
  
**Recruit**  
  
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.  
  
Stripe is one of the most successful startups we've funded, and the problem
they solved was an urgent one. If anyone could have sat back and waited for
users, it was Stripe. But in fact they're famous within YC for aggressive
early user acquisition.  
  
Startups building things for other startups have a big pool of potential users
in the other companies we've funded, and none took better advantage of it than
Stripe. At YC we use the term "Collison installation" for the technique they
invented. More diffident founders ask "Will you try our beta?" and if the
answer is yes, they say "Great, we'll send you a link." But the Collison
brothers weren't going to wait. When anyone agreed to try Stripe they'd say
"Right then, give me your laptop" and set them up on the spot.  
  
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. But for a startup to succeed, at least one
founder (usually the CEO) will have to spend a lot of time on sales and
marketing.   
  
The other reason founders ignore this path is that the absolute numbers seem
so small at first. 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. 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.   
  
Airbnb is a classic example of this technique. Marketplaces are so hard to get
rolling that you should expect to take heroic measures at first. In Airbnb's
case, these consisted of going door to door in New York, recruiting new users
and helping existing ones improve their listings. When I remember the Airbnbs
during YC, I picture them with rolly bags, because when they showed up for
tuesday dinners they'd always just flown back from somewhere.  
  
**Fragile**  
  
Airbnb now seems like an unstoppable juggernaut, but early on it was so
fragile that about 30 days of going out and engaging in person with users made
the difference between success and failure.  
  
That initial fragility was not a unique feature of Airbnb. Almost all startups
are fragile initially. And that's one of the biggest things inexperienced
founders and investors (and reporters and know-it-alls on forums) get wrong
about them. 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."  
  
It's harmless if reporters and know-it-alls dismiss your startup. They always
get things wrong. It's even ok if investors dismiss your startup; they'll
change their minds when they see growth. The big danger is that you'll dismiss
your startup yourself. I've seen it happen. I often have to encourage founders
who don't see the full potential of what they're building. Even Bill Gates
made that mistake. He returned to Harvard for the fall semester after starting
Microsoft. He didn't stay long, but he wouldn't have returned at all if he'd
realized Microsoft was going to be even a fraction of the size it turned out
to be.   
  
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?" And the right things often seem both laborious and
inconsequential at the time. Microsoft can't have seemed very impressive when
it was just a couple guys in Albuquerque writing Basic interpreters for a
market of a few thousand hobbyists (as they were then called), but in
retrospect that was the optimal path to dominating microcomputer software. And
I know Brian Chesky and Joe Gebbia didn't feel like they were en route to the
big time as they were taking "professional" photos of their first hosts'
apartments. They were just trying to survive. But in retrospect that too was
the optimal path to dominating a big market.  
  
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. For
example, Ben Silbermann noticed that a lot of the earliest Pinterest users
were interested in design, so he went to a conference of design bloggers to
recruit users, and that worked well.   
  
**Delight**  
  
You should take extraordinary measures not just to acquire users, but also to
make them happy. For as long as they could (which turned out to be
surprisingly long), Wufoo sent each new user a hand-written thank you note.
Your first users should feel that signing up with you was one of the best
choices they ever made. And you in turn should be racking your brains to think
of new ways to delight them.  
  
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. You're supposed to build
things that are robust and elegant, not be slavishly attentive to individual
users like some kind of salesperson. Ironically, part of the reason
engineering is traditionally averse to handholding is that its traditions date
from a time when engineers were less powerful — when they were only in charge
of their narrow domain of building things, rather than running the whole show.
You can be ornery when you're Scotty, but not when you're Kirk.  
  
Another reason founders don't focus enough on individual customers is that
they worry it won't scale. But when founders of larval startups worry about
this, I point out that in their current state they have nothing to lose. Maybe
if they go out of their way to make existing users super happy, they'll one
day have too many to do so much for. That would be a great problem to have.
See if you can make it happen. And incidentally, when it does, 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.  
  
I have never once seen a startup lured down a blind alley by trying too hard
to make their initial users happy.  
  
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. 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.   
  
Once you realize that existing conventions are not the upper bound on user
experience, it's interesting in a very pleasant way to think about how far you
could go to delight your users.  
  
**Experience**  
  
I was trying to think of a phrase to convey how extreme your attention to
users should be, and I realized Steve Jobs had already done it: insanely
great. Steve wasn't just using "insanely" as a synonym for "very." He meant it
more literally — that one should focus on quality of execution to a degree
that in everyday life would be considered pathological.  
  
All the most successful startups we've funded have, and that probably doesn't
surprise would-be founders. What novice founders don't get is what insanely
great translates to in a larval startup. When Steve Jobs started using that
phrase, Apple was already an established company. He meant the Mac (and its
documentation and even packaging — such is the nature of obsession) should be
insanely well designed and manufactured. That's not hard for engineers to
grasp. It's just a more extreme version of designing a robust and elegant
product.  
  
What founders have a hard time grasping (and Steve himself might have had a
hard time grasping) is what insanely great morphs into as you roll the time
slider back to the first couple months of a startup's life. It's not the
product that should be insanely great, but the experience of being your user.
The product is just one component of that. 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.  
  
Can, perhaps, but should? Yes. Over-engaging with early users is not just a
permissible technique for getting growth rolling. For most successful startups
it's a necessary part of the feedback loop that makes the product good. Making
a better mousetrap is not an atomic operation. 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. And except in domains with big penalties
for making mistakes, it's often better not to aim for perfection initially. 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.
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.   
  
The feedback you get from engaging directly with your earliest users will be
the best you ever get. When you're so big you have to resort to focus groups,
you'll wish you could go over to your users' homes and offices and watch them
use your stuff like you did when there were only a handful of them.  
  
**Fire**  
  
Sometimes the right unscalable trick is to focus on a deliberately narrow
market. It's like keeping a fire contained at first to get it really hot
before adding more logs.  
  
That's what Facebook did. At first it was just for Harvard students. In that
form it only had a potential market of a few thousand people, but because they
felt it was really for them, a critical mass of them signed up. After Facebook
stopped being for Harvard students, it remained for students at specific
colleges for quite a while. When I interviewed Mark Zuckerberg at Startup
School, he said that while it was a lot of work creating course lists for each
school, doing that made students feel the site was their natural home.  
  
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. It's
always worth asking if there's a subset of the market in which you can get a
critical mass of users quickly.   
  
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.
The strategy works just as well if you do it unconsciously. The biggest danger
of not being consciously aware of this pattern is for those who naively
discard part of it. E.g. if you don't build something for yourself and your
friends, or even if you do, but you come from the corporate world and your
friends are not early adopters, you'll no longer have a perfect initial market
handed to you on a platter.  
  
Among companies, the best early adopters are usually other startups. They're
more open to new things both by nature and because, having just been started,
they haven't made all their choices yet. Plus when they succeed they grow
fast, and you with them. It was one of many unforeseen advantages of the YC
model (and specifically of making YC big) that B2B startups now have an
instant market of hundreds of other startups ready at hand.  
  
**Meraki**  
  
For hardware startups there's a variant of doing things that don't scale that
we call "pulling a Meraki." Although we didn't fund Meraki, the founders were
Robert Morris's grad students, so we know their history. They got started by
doing something that really doesn't scale: assembling their routers
themselves.  
  
Hardware startups face an obstacle that software startups don't. The minimum
order for a factory production run is usually several hundred thousand
dollars. Which can put you in a catch-22: without a product you can't generate
the growth you need to raise the money to manufacture your product. Back when
hardware startups had to rely on investors for money, you had to be pretty
convincing to overcome this. The arrival of crowdfunding (or more precisely,
preorders) has helped a lot. 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. If they hadn't gone through that phase,
they probably wouldn't have sold $10 million worth of watches when they did go
on Kickstarter.  
  
Like paying excessive attention to early customers, fabricating things
yourself turns out to be valuable for hardware startups. You can tweak the
design faster when you're the factory, and you learn things you'd never have
known otherwise. Eric Migicovsky of Pebble said one of the things he learned
was "how valuable it was to source good screws." Who knew?  
  
**Consult**  
  
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. 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. Even if there aren't
many of them, there are probably adjacent territories that have more. 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.   
  
Consulting is the canonical example of work that doesn't scale. But (like
other ways of bestowing one's favors liberally) it's safe to do it so long as
you're not being paid to. That's where companies cross the line. 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. But when
they start paying you specifically for that attentiveness — when they start
paying you by the hour — they expect you to do everything.  
  
Another 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.  
  
**Manual**  
  
There's a more extreme variant where you don't just use your software, but are
your software. 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.  
  
When manual components look to the user like software, this technique starts
to have aspects of a practical joke. For example, the way Stripe delivered
"instant" merchant accounts to its first users was that the founders manually
signed them up for traditional merchant accounts behind the scenes.  
  
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. 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.  
  
**Big**  
  
I should mention one sort of initial tactic that usually doesn't work: the Big
Launch. 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. They want to launch
simultaneously in 8 different publications, with embargoes. And on a tuesday,
of course, since they read somewhere that's the optimum day to launch
something.  
  
It's easy to see how little launches matter. Think of some successful
startups. How many of their launches do you remember? All you need from a
launch is some initial core of users. 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.   
  
So why 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. Plus it would be so much less work if you
could get users merely by broadcasting your existence, rather than recruiting
them one at a time. But 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.  
  
Partnerships too usually don't work. They don't work for startups in general,
but they especially don't work as a way to get growth started. It's a common
mistake among inexperienced founders to believe that a partnership with a big
company will be their big break. Six months later they're all saying the same
thing: that was way more work than we expected, and we ended up getting
practically nothing out of it.   
  
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.  
  
**Vector**  
  
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. 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.  
  
It could be interesting to start viewing startup ideas this way, because now
that there are two components you can try to be imaginative about the second
as well as the first. 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.   
  
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. 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.  
  
  
  
  
  
  
  
**