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