Искусство, конечно, заключается в том, чтобы знать, какие пожары оставить гореть. Определение приоритетов обычно зависит от сочетания различных факторов. Первый — срочность. Какие пожары способны разрушить или погубить ваш бизнес раньше остальных? Их число не должно ограничиваться теми, что непосредственно угрожают существованию бизнеса; для стартапа огонь, который губит способность к росту, в перспективе почти так же смертелен, как и тот, который угрожает завтра же вывести вас из игры. Обычно первое, что вы должны сделать, это решить, можно ли попросту забить на эту проблему и справиться с ней позднее. Когда Селина Тобакковала приступила к работе в SurveyMonkey, одним из первых пожаров, с которым она решила бороться, был дизайн продукта. Это было нечто уродливое, старомодное и, если уж откровенно, вызывало некоторую неловкость. Но вместе с тем продукт был невероятно эффективным и успешным — вовлеченность пользователей была на хорошем уровне, клиенты были довольны. Селина решила отложить редизайн продукта в пользу более срочных пожаров. Это решение затруднило привлечение разработчиков-эстетов, но не погубило компанию.

В некоторых случаях, если пожары в вашем стартапе сжигают деньги, но не касаются ваших потребителей и если вы можете позволить себе эти убытки, то лучше в буквальном смысле купить время и не принимать их во внимание. Часто привлечение большего капитала является простым (хотя, как правило, дорогим) способом сдерживания второстепенных пожаров.

Второй фактор, на который вам следует обратить внимание, — результативность. Какие пожары у вас есть возможность погасить прямо сейчас, а какие будет легче погасить позже (и наоборот)? Если пожар срочный, а вы не можете эффективно справиться с ним в этот момент, следует оставить его без внимания и надеяться, что внешние условия сделают работу за вас. Аналогично этому, если пожар не срочный, но в перспективе может посеять хаос, вам проще будет спасти себя от тяжелого испытания в будущем, погасив огонь в зародыше.

Заключительный фактор — взаимозависимость. Сможет ли тушение пожара А облегчить тушение пожаров В и С? Этот эффект домино бывает крайне существенен, так как пожаров всегда оказывается больше, чем времени, которое у вас есть на борьбу с ними.

Для большинства быстро развивающихся стартапов можно построить некое подобие пирамиды Маслоу по пожарам, где на вершине будет расположен самый серьезный пожар, с которым следует бороться в первую очередь:

Дистрибуция

Продукт

Модель получения дохода

Деятельность

Конкуренция

Что дальше?

Это значит, что для большинства потребительских стартапов в интернете наиболее важным фактором является дистрибуция; если вашу дистрибуцию поглотило пламя, то компания обречена. Однако, если вы способны сдержать этот пожар, борьба с другими пожарами пойдет гораздо легче. Обретение новых пользователей обеспечивает вам обратную связь, которая дает понять, как улучшить продукт. Обретение миллионов пользователей или тысяч клиентов облегчает получение дохода. Получение дохода упрощает оплату расходов на инфраструктуру и персонал, необходимых для расширения вашей организации как за счет денежного потока, так и за счет привлечения инвестирования. А уж если у вас есть преуспевающий и растущий бизнес, тогда имеет смысл беспокоиться о конкуренции.

В случае с LinkedIn, после того как мы решили проблему дистрибуции, настроив вирусность и получив внушительную базу пользователей, появились те, кто стал твердить о горящей модели получения дохода. Если бы в то время я получал цент всякий раз, как кто-нибудь спрашивал меня: «Ну и как LinkedIn собирается зарабатывать деньги?» — мне, вероятно, и не понадобилась бы никакая модель получения дохода! Но я знал, что нам не следует обращать внимание на этот пожар, потому что 1) отсутствие дохода не станет непосредственной причиной гибели, если только не помешает нам привлекать деньги, и 2) пожар, охвативший продукт, был куда более срочным и требовал нашего пристального внимания. Если бы нам не удалось наладить дистрибуцию, чтобы привлечь критическую массу по крайней мере в миллион пользователей, и создать продукт, который понравился бы им настолько, чтобы превратить пользователей в постоянных (или хотя бы в отвечающих на запросы LinkedIn), модель получения дохода не имела бы никакого значения.

В то время потенциальные инвесторы Серии А хотели видеть бизнес-модель, которая бы показала, как LinkedIn собирается выйти на рентабельность. Я объяснял им, что мы не собираемся получать доход до следующего раунда финансирования и потому это не должно иметь для них значения. Инвесторы продолжали настаивать, поэтому мы с командой сформировали финансовую модель, которая включала в себя источники дохода. Я уж и не помню, что мы там указали! Не тратя на это время, мы просто выделили один вечер, выпили пару бокалов вина и нарисовали модель (пусть меня несколько раздражало, что на это приходится тратить целый вечер, но вино было хорошим, поэтому время было потрачено не впустую).

Эта история наглядно показывает, почему вам нужны люди, устойчивые к хаосу, риску и неопределенности. Большинство из нас готовы бороться с пожарами; но я говорю о людях, которые вблизи ревущего пламени, способного вскоре отрезать им путь эвакуации, продолжают хладнокровно и прицельно тушить еще более срочный пожар. Членов команды LinkedIn устраивала такая неопределенность и они работали с полной эффективностью, пусть даже мы и не определились с моделью получения дохода. К тому же, если ваши сотрудники не могут оставить в покое второстепенные пожары, они истратят все время на борьбу с ними, вместо того чтобы заниматься поиском прорывных возможностей для бизнеса.

Правило №6: ДЕЛАЙТЕ ТО, ЧТО НЕ ПОДДАЕТСЯ МАСШТАБИРОВАНИЮ (РАЗОВАЯ АКЦИЯ)

Пол Грэм, основатель YCombinator, написал знаменитое эссе, в котором дал предпринимателям совет делать то, что не поддается масштабированию. Этот совет будто создан для ранних стартапов, но еще большую важность он имеет для стартапов, проводящих блиц-масштабирование.

Разработчики ненавидят выполнять одноразовую работу. Не только потому, что это нерационально, но и потому, что это оскорбляет их чувство эффективности. Они твердо верят общепринятой мудрости, согласно которой лучше сразу создать хороший продукт, чтобы не пришлось его пересоздавать. Но когда вы проводите блиц-масштабирование, неэффективность — это правило, а не исключение. Чтобы повысить приоритет скорости, вы можете меньше инвестировать в безопасность, писать код, который нельзя масштабировать, и ожидать, пока все начнет ломаться еще до того, как вы создадите инструменты и процессы контроля качества (QA). Все эти решения в дальнейшем действительно приведут к проблемам, но у вас может просто не быть этого «в дальнейшем», если вы слишком затянете с созданием продукта. Разрубить узел, что занимает в десять раз меньше времени, может быть более полезным, чем вырабатывать элегантное решение, как его развязать, даже если позже придется исправлять последствия.

Практически та же самая логика подходит для большинства аспектов вашего бизнеса. Нередко вам придется делать то, что не поддается масштабированию, когда дело будет касаться продаж (например, основатель Марк Бениофф привлек в Salesforce.com первого клиента, Blue Martini Software, попросив об услуге их генерального директора Монте), операций (например, Пол Инглиш указал номер личного мобильного телефона в качестве исходной линии обслуживания клиентов Kayak) и так далее.