Блиц-масштабирование: Как создать крупный бизнес со скоростью света - Крис Йе

Остерегайтесь того, что Эрик Рис назвал «тщеславными параметрами», — значений, которые показывают радужную картину бизнеса, но на деле не отражают ключевых факторов роста. Надо отметить, что тщеславный параметр одной компании может быть фактором роста другой. Например, количество просмотров страницы представляет собой тщеславный параметр для большинства стартапов, но является фактором роста для медиакомпаний. В интервью для подкаста Рида Masters of Scale Эван Уильямс, основатель Blogger, Twitter и Medium, сообщил, что на раннем этапе существования Twitter его команда попалась на особенно вредный тщеславный параметр. Пресса расхваливала Twitter за стимулирование разработчиков к созданию продуктов на базе его интерфейса прикладного программирования (API), и команда Эвана воспевала стремительный рост числа вызовов API, которые ежедневно обрабатывал Twitter. К сожалению, они обнаружили, что число вызовов API на самом деле не было связано с успехом бизнеса. На самом деле все было ровно наоборот; большое число вызовов API перегружало инфраструктуру Twitter и вызывало проблемы в вопросах масштабирования и производительности. «Мы обнаружили, что многие разработчики, создававшие свои продукты на основе нашего API, очень неэффективны, — вспоминал он. — Была одна мексиканская радиостанция, у которой был такой плохой JavaScript на веб-странице, что одна только эта веб-страница вгоняла нас в тоску!» Twitter следовало ужесточить правила доступа к своему API, чтобы сократить этот объем вызовов.

Какой бы параметр вы ни выбрали, данные в малочисленной организации, как правило, распространяются между отдельными сотрудниками по принципу осмоса, к которому можно добавить регулярный обзор информации во время еженедельных совещаний. Вам даже не нужны ни затейливые инструменты для бизнес-анализа (business intelligence, BI), ни спецотдел.

Тем не менее, как только ваша организация достигнет стадии Деревни, осмос перестанет работать. Ваши сотрудники теперь осваивают множество направлений, организация (которая уже превысила число Данбара) стала слишком велика, чтобы все были знакомы друг с другом. Использование общей панели мониторинга позволит вам не только видеть, как переплетаются нити, но и координировать работу различных групп. Через такую панель каждая группа может показать другим: «Вот над чем мы работаем; вот как мы это делаем; а вот как мы работаем вместе со всеми вами».

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

На стадиях Города и Государства вам наверняка потребуется специализированная команда бизнес-аналитиков (BI), чтобы гарантировать поступление всей необходимой информации людям, которые принимают ключевые решения. Ставки настолько высоки, а цена за ошибочное решение так велика, что значимость такой команды не поддается сравнению.

Марк Пинкус сделал крупные вложения в свою команду BI в Zynga, что позволило компании отслеживать каждый клик в своих играх, а не полагаться на Google Analytics, как это делали многие конкуренты. «Люди говорили, что нам не нужны пятьдесят аналитиков, ведь в других компаниях их не более десяти, — вспоминал Марк во время интервью для подкаста Рида Masters of Scale. — Но Zynga сделала все по-своему. На самом деле сбор этих данных позволяет нам быстрее делать и оценивать ставки».

Вдобавок к тому, чтобы просто доводить до сведения бизнес-подразделений данные и собирать соображения по разным вопросам, многие наиболее эффективные компании создают специальную команду роста, которая сочетает в себе работу над маркетингом, продуктом и проектированием, для того чтобы реагировать на эти соображения конкретными действиями. Большинство компаний, даже в условиях высокой конкуренции потребительского интернета, продолжают думать, что достаточно просто постоянно проводить A/B-тесты и в соответствии с ними продолжать делать то же самое. Это эффективная тактика, но плохая стратегия, так как частные случаи оптимизации не всегда ведут к оптимальному результату в целом. Специальная команда роста может посмотреть на общую картину и увидеть, как взаимодействие продуктовых и маркетинговых решений обеспечивает (или не обеспечивает) достижение желаемого результата. По мнению Джоша Элмана из Greylock: «Лучшие команды роста выявляют основные идеи, которые способны перевести случайных пользователей в статус активных регулярных и так настроить каждую функцию и программу в продукте — в том числе функции, не связанные с программным обеспечением, — чтобы пользователи могли быстрее преодолевать этот барьер».

Кроме того, команда роста помогает сделать рост приоритетом, а не вопросом второстепенной или третьестепенной важности. Элман любит сравнивать традиционную команду специалистов по маркетингу с диккенсовской сироткой, которая выпрашивает ресурсы у специалистов по продукту и инжинирингу: «Пожалуйста, сэр, можно мне еще один лэндинг?» Любые изменения в продукте или инжиниринговая инфраструктура, необходимые для обеспечения роста, независимо от того, насколько они потенциально значимы, в итоге отходят на второй план после дорожных карт самих команд разработчиков. В свою очередь, разработчики из команды роста могут действовать гораздо быстрее, потому что построение масштабируемой и расширяемой инфраструктуры тестирования является частью их работы.

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

Джонатан Розенберг из Google рассказал историю, как управление по слепому ориентированию на цифры завело в тупик Exсite@Home. Exсite@Home измерял число кликов на каждый элемент своей домашней страницы. Если элемент не выполнял свою цель по кликам, Exсite@Home делал этот элемент визуально более заметным. Другими словами, пытаясь достичь своих целей в числовом выражении, команда, занимавшаяся ведением домашней страницы, акцентировала внимание на менее привлекательных элементах, пытаясь переключить его с более привлекательных!

Вот почему вам может понадобиться смесь количественного и качественного анализа. Наш друг Джон Лилли любит повторять, в чем заключается разница между разработкой продукта «на основе таланта» (например, Apple) и разработкой «на основе данных» (например, Google). У обоих подходов есть свои сильные и слабые стороны. Разработка на основе данных отлично подходит для оптимизации продуктов при постепенных изменениях, однако с ее помощью вы сможете взобраться лишь на вершину местного холма, а не самой высокой горы. Разработка на основе таланта может быть единственным способом создать революционный продукт, но зачастую его дорабатывают на основе данных.