Чтобы достичь «блицскалинга», вы должны идти против здравого смысла
Речь идет о стартапах, есть рост и ультра-быстрый рост-= то что я хотел бы назвать «blitzscaling
Blitzscaling компании не прост, если бы это было так, все бы это сделали.
Как и большинство ценностей в этом мире, блицскейлинг не логичен. Чтобы добиться успеха, вам придется нарушать многие «правила» управления, разработанные для минимизации эффективности и риска. На самом деле, чтобы достичь своих целей агрессивного роста в условиях неопределенности и перемен, вам необходимо следовать новому набору правил, которые противоречат тому, чему учат в бизнес-школах, и они совершенно противоречат принятым «лучшим практикам».
Правило № 1: Объять хаос
Годовые планы. Руководство по доходам. Традиционный бизнес стремится к порядку и регулярности в управлении, операциях и финансовых результатах. Такое стремление к порядку и регулярности имеет смысл, потому что оно позволяет компаниям оттачивать свой подход настолько эффективно, насколько это возможно, и дает акционерам приятное чувство стабильности. Но когда вы молниеносны, вы явно предпочитаете жертвовать эффективностью ради скорости, а это означает, что традиционное внимание к порядку и регулярности должно быть заменено уникальной готовностью принять уровень хаоса, который ужаснул бы большинство Гарвардских MBA и их профессоров.
Все же простое поднятие рук вряд ли принесет успех, пассивно поддаваться хаосу не является выигрышной стратегией. Принятие хаоса с другой стороны, означает принятие существующей неопределенности и, следовательно, принятие мер для ее преодоления.
Если вы знаете, что будете совершать ошибки, ответ не в том, чтобы сидеть сложа руки и ждать ошибок, при этом не стоит забегать вперед без подготовки или продуманной работы. Вы по-прежнему можете принимать разумные решения, основываясь на своей оценке вероятностей, даже без уверенности, и, возможно, самое главное, вы можете убедиться, что у вас есть возможность исправлять свои ошибки.
Правило № 2: нанимайте нужного человека в нужный момент
На протяжении большей части истории Силиконовой долины общепринятым подходом при найме руководителей для стартапа было быстрое привлечение руководителя, способного масштабироваться.
Это означало наем кого-то, кто имел опыт работы с более крупными организациями, идея состояла в том, чтобы их опыт пригодился на более позднем этапе.
Наем кого-то, кто управлял 1000 человек для управления компанией из 10 человек, на самом деле контрпродуктивен.
В современном мире стартапов это правило больше не применяется. Дарвиновская конкуренция настолько жестока, что ваша организация должна идти ва-банк на нынешней стадии масштабирования.
Вам нужны менеджеры и руководители, которые «просто правы» для текущей фазы роста, в конце концов, вам не придется беспокоиться об этом следующем этапе, если ваша команда не сможет туда добраться. Наем кого-то, кто управлял 1000 человек для управления компанией из 10 человек, на самом деле контрпродуктивен, потому что навыки, необходимые для достижения успеха на этих двух этапах, очень разные.
Правило № 3: терпеть «плохое» управление
При блиц-масштабировании скорость важнее, чем хорошо организованная компания. В нормальных условиях вы должны стремиться к организационной согласованности и стабильности. Хаотичные, нестабильные организации заставляют сотрудников нервничать и снижать моральный дух. Но когда вы расширяетесь с молниеносной скоростью, вам, возможно, потребуется реорганизовать компанию три раза в течение одного года или многократно использовать членов вашей управленческой команды. Когда ваша организация растет на 300 процентов в год, вам, возможно, придется продвигать людей до того, как они будут готовы, а затем менять их, если они тонут, а не плавают. У вас нет времени набраться терпения и ждать, пока что-то получится. Вы должны действовать быстро и решительно. Всегда есть много изменений, и большая их часть не является добровольной. Вы одновременно строите команды и компанию. В интересах скорости.
Рассмотрим пример PayPal. В то время как PayPal имел большой успех, компания плохо управлялась - и я пишу это заявление как один из ее старших менеджеров. Мы сделали несколько хороших вещей, например, удостоверившись, что у каждого сотрудника была четкая основная работа, и сосредоточились на работе над определенными важными проектами, но по большей части управление PayPal было недостатком управления. Не было никаких разговоров о развитии карьеры с сотрудниками. Не было никакой работы по формированию команд, кроме простого выбора того, кто будет принадлежать к ним.
Но «плохое» управление PayPal обеспечило ряд противоречивых преимуществ, в то время как мы были молниеносны. В критические времена, когда PayPal разрабатывал и расширял свои инновации в бизнес-моделях, нам приходилось преодолевать ряд непростых задач, или, как мне нравится называть их, «О, дерьмо!».
- Вот дерьмо, у нас проблема с мошенничеством, и мы теряем миллионы долларов, которых у нас нет.
- О, дерьмо, Visa говорит, что мы должны изменить продукт, иначе нас закроют.
- О, дерьмо, eBay, наш самый важный деловой партнер, только что начал свое собственное предприятие, чтобы напрямую конкурировать с нами.
Из-за нашего «плохого» управления у нас не было никаких предвзятых представлений о том, «что именно так должна выглядеть компания через три года». Хаотичный характер нашего управления фактически удерживал нас ловкими перед лицом этого минного поля. Когда у всех в организации есть роли, которые не определены и постоянно меняются, легче сказать:
«Я знаю, что это то, над чем вы работали последние четыре дня, но сейчас мы делаем что-то другое».
Внутренний хаос имел эффект нормализации радикальных изменений для наших людей, что означало, что они были лучше приспособлены к радикальным изменениям.
Правило № 4: Запустите продукт, который вас смущает
Это не значит, что вы должны стремиться производить плохой продукт. Скорее, если вам нужно выбрать между быстрым выходом на рынок с несовершенным продуктом или медленным выходом на рынок с «совершенным» продуктом, выбирайте несовершенный продукт почти каждый раз.
Быстрый выход на рынок позволяет вам начать получать отзывы, необходимые для его улучшения. Любой продукт, который вы тщательно доработали, основываясь на своих инстинктах, а не на реальных реакциях пользователей и данных, скорее всего, не достигнет цели и в любом случае потребует значительных итераций. Скорость действительно имеет значение, а ранний запуск позволяет быстрее подняться по кривой обучения к отличному продукту.
Я усвоил этот урок, когда работал в своем первом стартапе SocialNet. Я не хотел смущаться нашим первым выпуском, поэтому мы решили завершить весь продукт, прежде чем отодвинуть занавес и позволить людям зарегистрироваться. Этот подход задержал запуск SocialNet на год, и когда мы наконец запустили, мы быстро поняли, что половина функций, которые мы кропотливо реализовали, были не важны, а половина важных вещей, без которых наш сервис был бы бесполезен, отсутствовали, потому что мы не думали о них. Хотя были и другие причины, по которым SocialNet потерпел неудачу, преждевременный запуск и повторение на основе отзывов рынка, вероятно, могли бы исправить ситуацию.
После моего опыта в PayPal и успеха, которого мы достигли благодаря быстрому запуску и итерации продукта, я решил запустить LinkedIn как можно скорее. Наша команда определила список функций, которые, по нашему мнению, были минимальными для выхода на рынок. Спустя годы Стив Бланк и Эрик Рис назовут этот продукт «минимально жизнеспособным» (MVP). Для LinkedIn MVP включал профессиональный профиль пользователя, возможность подключаться к другим пользователям, функцию поиска для поиска других пользователей и механизм отправки сообщений друзьям.
Незадолго до запуска мы начали беспокоиться о том, будет ли LinkedIn полезен без критической массы профилей. Если пользователь вошел в LinkedIn, как мы можем сделать его полезным, даже если никто из друзей этого пользователя еще не зарегистрировался?
Мы решили, что нам не хватало Contact Finder, версии поиска, которая позволила бы пользователю LinkedIn найти потенциальных поставщиков. Наша команда инженеров подсчитала, что на создание этой функции у нас уйдет месяц. Нам был поставлен трудный выбор - отложить запуск на месяц или запустить без функции, которая, по нашему мнению, может иметь важное значение для нашего успеха. Работая по принципу смущения, мы запустили без Contact Finder. И быстро мы обнаружили гораздо большую проблему: в отличие от пользователей персональных социальных сетей, таких как Friendster, которые быстро развивались, поскольку новые пользователи приглашали своих друзей присоединиться, Пользователи LinkedIn не отправляли никаких приглашений. Наш рост пользователей был остановлен. Наш базовый продукт был плох, потому что никто не использовал его! Если бы мы откладывали запуск на месяц для создания Contact Finder, людей по-прежнему не хватало бы, чтобы использовать его, а это означало бы, что мы потеряли бы месяц, создавая функцию, которая не решала бы основную проблему. Мы подсчитали, что нам понадобится как минимум 1 миллион пользователей, прежде чем поиск (и Contact Finder) будет полезен, и решение этой проблемы было главным приоритетом. Это означает, что мы потеряли бы месяц, создавая функцию, которая не решала бы основную проблему.
Основываясь на данных о запуске, мы сосредоточились на том, чтобы попытаться увеличить вирусность, и именно поэтому мы стали первой социальной сетью, которая позволяет вам загружать адресную книгу. Эта функция помогла LinkedIn получить критическую массу более 1 миллиона профилей пользователей, а остальное - история.
Имейте в виду, что вы должны быть смущены вашим первоначальным запуском! Стремление к скорости - не повод, чтобы срезать опасные повороты. Если вы вызываете судебные процессы это означает , что вы начали слишком рано.
Правило № 5: пусть горят огни
На каждом этапе блиц-масштабирования всегда есть гораздо больше проблем, требующих вашего внимания, чем у вас есть ресурсов для решения. Вы можете чувствовать себя как пожарный, за исключением того, что вместо того, чтобы пытаться потушить пламя в одном месте, вы можете увидеть отдельные пожары вокруг вас - и у вас нет времени потушить их все. Один из способов выжидания молниеносных предпринимателей состоит в том, что они решают позволить гореть определенным пожарам, чтобы они могли сосредоточиться на тех пожарах, которые, если им будет позволено свирепствовать, действительно разрушат компанию. Мой коллега из Грейлока Джозеф Ансанелли говорит: «То, чему вы говорите «нет», важнее, чем то, что вы говорите «да» »
Вы не можете игнорировать эти пожары навсегда - они на самом деле опасны и в конечном итоге потребуют внимания, но они не актуальны в большинстве точек во время блиц-масштабирования, потому что их тушение не приводит к ожидаемому исходу.
Правило № 6: Делайте вещи, которые не масштабируются (разовая работа)
Пол Грэм, соучредитель Y Combinator, написал знаменитое эссе, в котором он советовал предпринимателям делать вещи, которые не масштабируются. Этот совет актуален для молодых стартапов, но он еще важнее для блиц-стартапов.
Взлом, который занимает десятую часть времени, может быть более полезным, чем элегантно разработанное решение.
Инженеры ненавидят делать одноразовую работу. Это не только расточительно, но и оскорбляет их чувство эффективности. Они твердо верят в общепринятую мудрость, которая гласит, что лучше создать свой продукт с первого раза, так что его нужно создавать только один раз.
Но когда вы молниеносны, неэффективность - это правило, а не исключение.
Чтобы расставить приоритеты по скорости, вы можете меньше инвестировать в безопасность, писать код, который не масштабируется, и ждать, пока что-то не сломается, прежде чем создавать инструменты и процессы QA.
Это правда, что все эти решения позже приведут к проблемам, но у вас может не быть позже, если вы будете слишком долго строить продукт.
Хак, который занимает десятую часть времени, может оказаться более полезным, чем элегантно спроектированное решение, даже если его придется сделать позже.
Практически та же логика применима почти ко всем аспектам вашего бизнеса. Вам часто приходится делать вещи, которые не масштабируются, когда речь идет о продажах (например, основатель Марк Бениофф привел первого клиента Salesforce.com, Blue Martini Software, позвонив в услугу своего генерального директора, Монте Цвебена), операции ( Пол Инглиш указал свой личный номер мобильного телефона в качестве исходной линии обслуживания клиентов для Kayak) и так далее.
И при этом мир не разделен аккуратно на «вещи, которые не масштабируются» и «вещи, которые масштабируются», причем первые плавно - и навсегда - уступают место последним.
Код или процесс, который масштабируется во время одного этапа блиц-масштабирования, может сломаться на следующем этапе, и то, чем вы его замените, может не масштабироваться поначалу.
Посмотрите, как основатели Airbnb решили проблему с размещением на Airbnb.com некачественных фотографий своих объектов аренды: они стали фотографами.
Как сказал мне Брайан Чески : «Мы брали камеры у наших друзей из RISD [Школа дизайна Род-Айленда] в Бруклине, а затем буквально стучали в двери всех наших хозяев».
Вместе Брайан и соучредитель Джо Геббиа могли фотографировать около 10 домов в день. (Соучредителю Натану Блечарчику пришлось остаться в квартире, которая служила их офисом, чтобы убедиться, что сайт не рухнет) Поговорите о вещах, которые не масштабируются!
Когда Airbnb взлетел, функцию фотографии пришлось значительно расширить. Поэтому основатели наняли фотографов из Craigslist, своих друзей из RISD и даже наняли хозяев Airbnb, которые называли фотографию хобби. Используя эти источники, компания смогла построить отдел из пяти-десяти фотографов, которым платили 50 долларов за дом и отслеживали их, используя сложный инструмент управления в виде таблицы, в которой перечислены фотографы и их задания.
Довольно скоро эта система была перегружена. Поэтому они наняли Элли Тиле из Сиракузского университета в качестве летнего стажера и сделали управление фотографами его постоянной работой.
Сосредоточившись исключительно на управлении фотографией, Элли удалось увеличить количество активных фотографов примерно до 50. Только в этот момент Airbnb перешел к действительно масштабируемому решению: программному обеспечению.
Натан написал код, добавив две кнопки на сайт: одну для хостов, чтобы запросить фотографа, а другую для Элли, чтобы инициировать платеж, когда фотограф закончил назначение.
В конце концов, основатели наняли Джо Заде на должность инженера начального уровня и попросили его поработать с Элли, чтобы полностью автоматизировать процесс фотосъемки.
Airbnb прошел через три различных способа обработки фотографий, прежде чем создавать какой-либо код, и с тех пор несколько раз переписывал систему фотографии. Для Airbnb не имело бы смысла начинать с создания масштабируемой системы автоматической фотографии в тот момент, когда компания начала этот путь, сайт получал всего 10 посетителей в день, и единственным инженерным ресурсом был Натан Блечарчик.
Любая работа, которую он делал бы над этой проблемой, задержала бы все другие инженерные работы, необходимые Airbnb для развития своего бизнеса. Делая вещи, которые не масштабировались, компания могла расти, несмотря на нехватку ресурсов и «потраченную впустую» работу по созданию электронных таблиц, которые потом пришлось бы выбросить.
Правило № 7: игнорируйте своих клиентов
Фундаментальное правило обслуживания клиентов долгое время звучало так: «клиент всегда прав». Но для многих компаний, занимающихся блиц-масштабированием, ключевое правило заключается в том, чтобы «предоставлять вам любую услугу, которую нужно, до тех пор, пока она не замедлит вас - и это может означать, - нет»
Многие стартапы Blitzscaling будут предлагать только поддержку по электронной почте или вообще не поддерживать, полагаясь на то, что пользователи будут находить и помогать друг другу на дискуссионных форумах.
В абсолютном масштабе игнорирование ваших клиентов редко будет положительным. Клиентам нравится, когда их слышат, и их игнорирование в конечном итоге приведет к истощению доброжелательности к вашей компании. Но для компаний, занимающихся блицскалингом, позволить клиентам чувствовать себя игнорируемыми - это часто один из пожаров, который легче зажечь, пока вы не закончите бороться с большими, более смертоносными пожарами.
Подписывайтесь на наш канал и делитесь в комментариях согласны ли вы с этой статьей?