The Hardest Lessons for Startups to Learn
Эссе Пола Грэма от апреля 2006 года (по мотивам выступления на Startup School 2006) рассказывает о самых трудных для стартапов уроках — тех, что противоречат интуиции и которые автору приходится повторять снова и снова основателям, профинансированным через Y Combinator. Грэм нумерует эти пункты, чтобы вместо подробных нравоучений просто говорить «номер четыре!». Первый и самый часто повторяемый совет: «Выпускайте рано» — быстро сделать версию 1 и улучшать её на основе реакции пользователей. Под ранним выпуском имеется в виду не релиз с кучей багов, а минимальная версия: пользователи ненавидят баги, но не против минимального продукта, если скоро будет продолжение. Грэм видел много стартапов, погибших из-за слишком медленного релиза, и ни одного — из-за слишком быстрого.
April 2006
Апрель 2006
(This essay is derived from a talk at the 2006
Startup School.)
(Это эссе основано на выступлении на Startup School 2006 года.)
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.
1. Выпускайте рано.
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.
То, что я, наверное, повторяю чаще всего, — это такой рецепт стартапа: быстро выпустите версию 1, а затем улучшайте её на основе реакции пользователей.
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.
Под «выпускайте рано» я не имею в виду, что нужно выпускать что-то, полное багов, а что нужно выпускать что-то минимальное. Пользователи ненавидят баги, но, похоже, не против минимальной версии 1, если скоро ожидается продолжение.
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
Есть несколько причин, почему выгодно быстро сделать версию 1. Одна из них в том, что это попросту правильный способ писать программы — для стартапа или нет. Я повторяю это с 1993 года и с тех пор не видел особых опровержений. Я видел множество стартапов, погибших из-за того, что слишком медлили с релизом, и ни одного — из-за того, что выпускали слишком быстро. [1