The Hardest Lessons for Startups to Learn

[The Hardest Lessons for Startups to Learn]

****

****

****

****

****

****

****

****

****

****

| April 2006(This essay is derived from a talk at the 2006
Startup School.)The startups we've funded so far are pretty quick, but they seem
quicker to learn some lessons than others. I think it's because
some things about startups are kind of counterintuitive.We've now
invested
in enough companies that I've learned a trick
for determining which points are the counterintuitive ones:
they're the ones I have to keep repeating.So I'm going to number these points, and maybe with future startups
I'll be able to pull off a form of Huffman coding. I'll make them
all read this, and then instead of nagging them in detail, I'll
just be able to say: number four!
1. Release Early.The thing I probably repeat most is this recipe for a startup: get
a version 1 out fast, then improve it based on users' reactions.By "release early" I don't mean you should release something full
of bugs, but that you should release something minimal. Users hate
bugs, but they don't seem to mind a minimal version 1, if there's
more coming soon.There are several reasons it pays to get version 1 done fast. One
is that this is simply the right way to write software, whether for
a startup or not. I've been repeating that since 1993, and I haven't seen much since to
contradict it. I've seen a lot of startups die because they were
too slow to release stuff, and none because they were too quick.
[1]One of the things that will surprise you if you build something
popular is that you won't know your users. Reddit now has almost half a million
unique visitors a month. Who are all those people? They have no
idea. No web startup does. And since you don't know your users,
it's dangerous to guess what they'll like. Better to release
something and let them tell you.Wufoo took this to heart and released
their form-builder before the underlying database. You can't even
drive the thing yet, but 83,000 people came to sit in the driver's
seat and hold the steering wheel. And Wufoo got valuable feedback
from it: Linux users complained they used too much Flash, so they
rewrote their software not to. If they'd waited to release everything
at once, they wouldn't have discovered this problem till it was
more deeply wired in.Even if you had no users, it would still be important to release
quickly, because for a startup the initial release acts as a shakedown
cruise. If anything major is broken-- if the idea's no good,
for example, or the founders hate one another-- the stress of getting
that first version out will expose it. And if you have such problems
you want to find them early.Perhaps the most important reason to release early, though, is that
it makes you work harder. When you're working on something that
isn't released, problems are intriguing. In something that's out
there, problems are alarming. There is a lot more urgency once you
release. And I think that's precisely why people put it off. They
know they'll have to work a lot harder once they do.
[2]
2. Keep Pumping Out Features.Of course, "release early" has a second component, without which
it would be bad advice. If you're going to start with something
that doesn't do much, you better improve it fast.What I find myself repeating is "pump out features." And this rule
isn't just for the initial stages. This is something all startups
should do for as long as they want to be considered startups.I don't mean, of course, that you should make your application ever
more complex. By "feature" I mean one unit of hacking-- one quantum
of making users' lives better.As with exercise, improvements beget improvements. If you run every
day, you'll probably feel like running tomorrow. But if you skip
running for a couple weeks, it will be an effort to drag yourself
out. So it is with hacking: the more ideas you implement, the more
ideas you'll have. You should make your system better at least in
some small way every day or two.This is not just a good way to get development done; it is also a
form of marketing. Users love a site that's constantly improving.
In fact, users expect a site to improve. Imagine if you visited a
site that seemed very good, and then returned two months later and
not one thing had changed. Wouldn't it start to seem lame?
[3]They'll like you even better when you improve in response to their
comments, because customers are used to companies ignoring them.
If you're the rare exception-- a company that actually listens--
you'll generate fanatical loyalty. You won't need to advertise,
because your users will do it for you.This seems obvious too, so why do I have to keep repeating it? I
think the problem here is that people get used to how things are.
Once a product gets past the stage where it has glaring flaws, you
start to get used to it, and gradually whatever features it happens
to have become its identity. For example, I doubt many people at
Yahoo (or Google for that matter) realized how much better web mail
could be till Paul Buchheit showed them.I think the solution is to assume that anything you've made is far
short of what it could be. Force yourself, as a sort of intellectual
exercise, to keep thinking of improvements. Ok, sure, what you
have is perfect. But if you had to change something, what would
it be?If your product seems finished, there are two possible explanations:
(a) it is finished, or (b) you lack imagination. Experience suggests
(b) is a thousand times more likely.
3. Make Users Happy.Improving constantly is an instance of a more general rule: make
users happy. One thing all startups have in common is that they
can't force anyone to do anything. They can't force anyone to use
their software, and they can't force anyone to do deals with them.
A startup has to sing for its supper. That's why the successful
ones make great things. They have to, or die.When you're running a startup you feel like a little bit of debris
blown about by powerful winds. The most powerful wind is users.
They can either catch you and loft you up into the sky, as they did
with Google, or leave you flat on the pavement, as they do with
most startups. Users are a fickle wind, but more powerful than any
other. If they take you up, no competitor can keep you down.As a little piece of debris, the rational thing for you to do is
not to lie flat, but to curl yourself into a shape the wind will
catch.I like the wind metaphor because it reminds you how impersonal the
stream of traffic is. The vast majority of people who visit your
site will be casual visitors. It's them you have to design your
site for. The people who really care will find what they want by
themselves.The median visitor will arrive with their finger poised on the Back
button. Think about your own experience: most links you
follow lead to something lame. Anyone who has used the web for
more than a couple weeks has been trained to click on Back after
following a link. So your site has to say "Wait! Don't click on
Back. This site isn't lame. Look at this, for example."There are two things you have to do to make people pause. The most
important is to explain, as concisely as possible, what the hell
your site is about. How often have you visited a site that seemed
to assume you already knew what they did? For example, the corporate
site that says the
company makes

enterprise content management solutions for business that enable
organizations to unify people, content and processes to minimize
business risk, accelerate time-to-value and sustain lower total
cost of ownership.

[...]

Original source