The Hardest Lessons for Startups to Learn
Эссе Пола Грэма от апреля 2006 года (по мотивам выступления на Startup School 2006) рассказывает о самых трудных для стартапов уроках — тех, что противоречат интуиции и которые автору приходится повторять снова и снова основателям, профинансированным через Y Combinator. Грэм нумерует эти пункты, чтобы вместо подробных нравоучений просто говорить «номер четыре!». Первый и самый часто повторяемый совет: «Выпускайте рано» — быстро сделать версию 1 и улучшать её на основе реакции пользователей. Под ранним выпуском имеется в виду не релиз с кучей багов, а минимальная версия: пользователи ненавидят баги, но не против минимального продукта, если скоро будет продолжение. Грэм видел много стартапов, погибших из-за слишком медленного релиза, и ни одного — из-за слишком быстрого.
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