Блиц-масштабирование

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

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

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

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

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

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

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

Точно так же мир нельзя четко разделить на то, что не поддается масштабированию, и то, что поддается, да так, чтобы первое всегда уступало место последнему. Код или процесс, которые масштабируются на одной стадии, уже на следующей могут сломаться, и то, чем вы их замените, заработает тоже не сразу. Подумайте над тем, как основатели Airbnb решили проблему с хозяевами, которые выкладывали фотографии своей недвижимости в плохом качестве: они просто стали фотографами. Как рассказывал Брайан Чески: «Мы одолжили камеры у наших друзей из RISD  в Бруклине, а потом в буквальном смысле ходили и стучали в двери всех наших арендодателей».