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.
[1]
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.
[2]
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.
[3]
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.
[4]
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.
[5]
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.
[6]
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.
[7]
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.
[8]
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.
[9] Consulting is the cannical 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.
[10]
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.
[11]
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.
[12]
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.
Source: http://paulgraham.com/ds.html
