Чтобы объяснить, что такое подтверждение фактами, я приведу несколько примеров из своего личного опыта. Я часто рассказываю своим слушателям историю основания IMVU и говорю о тех ошибках, которые мы совершили в процессе разработки первого продукта. Сейчас я хочу рассказать об одной из этих ошибок.

Все мы, основатели компании IMVU, считали себя серьезными стратегами[4]. У каждого за плечами были неудачные попытки создать собственный бизнес, и нам не хотелось повторять печальный опыт. В первые годы нас больше всего волновали следующие вопросы: что мы должны создать и для кого? На какой рынок мы можем выйти? Как занять на нем доминирующие позиции? Как создать стабильную ценность, которой будет не страшна конкуренция?

Мы решили выйти на рынок мгновенных сообщений (IM). В 2004 г. на этом рынке были сотни миллионов активных пользователей со всего мира. Однако большинство людей, которые пользовались IM-сервисом, не платили за это. Крупные медийные компании и интернет-порталы, например AOL, Microsoft и Yahoo! создавали IM-сети в качестве «убыточного лидера» (товара, предлагаемого в убыток ради привлечения покупателей) для других сервисов и зарабатывали небольшие деньги на рекламе.

Рынок IM-сервисов обладает мощными сетевыми эффектами. Считается, что, как и большинство коммуникационных сетей, развитие IM-сервиса следует закону Меткалфа: ценность сети в целом равна половине квадрата количества ее участников. Иначе говоря, чем больше людей в сети, тем ценнее она для каждого пользователя. Это легко понять: ценность для каждого участника определяется прежде всего тем, с каким количеством других людей он может общаться. Что было бы, если бы телефон был только у вас? В нем не было бы никакого смысла. Телефон нужен только тогда, когда он есть и у других людей.

В 2004 г. на рынке IM-сервисов было несколько крупных игроков. Три крупнейшие сети контролировали более 80 % всех пользователей и собирались объединить свои доли рынка за счет множества небольших игроков. Считалось, что без огромных затрат на маркетинг очень сложно вывести на рынок новую IM-сеть.

И это мнение имело под собой основания. Из-за сетевых эффектов у IM-сервисов высокая стоимость переключения. Чтобы перейти из одной сети в другую, пользователям нужно убедить друзей и коллег сделать это вместе с ними. Это создает барьер для выхода на рынок новых IM-сетей: если почти все клиенты пользуются продуктами определенной сети, то просто нет людей, которые могли бы или захотели бы подключиться к другой.

В IMVU мы разработали следующую стратегию: создать продукт, который будет сочетать в себе преимущества традиционных IM-сетей с высоким доходом на одного клиента, характерным для трехмерных (3D) видеоигр и виртуальных миров. Мы не могли быстро вывести на рынок новую IM-сеть и поэтому решили создать дополнение, способное взаимодействовать с уже существующими сетями. Клиенты смогут купить виртуальные товары и коммуникационную технологию «аватаров» IMVU, и при этом им не нужно будет менять провайдера IM-сервиса и осваивать новый пользовательский интерфейс. А самое главное — они приведут с собой друзей.

Мы считали, что этот последний пункт — самый важный. Чтобы такое дополнение было полезным, пользователи должны иметь возможность общаться с его помощью с друзьями. Мы решили, что каждая коммуникация пользователей будет сопровождаться приглашением посетить сайт IMVU. Наш продукт, подобно вирусу, начнет распространяться по всем существующим IM-сетям со скоростью эпидемии. Чтобы добиться такого вирусного роста, было важно, чтобы наше дополнение оказалось совместимо с существующими IM-сетями и с любыми компьютерами.

Итак, мы спланировали стратегию и принялись за дело. Я был техническим директором и среди прочего отвечал за разработку программного обеспечения, совместимого со всеми IM-сетями. Несколько месяцев мы трудились с утра до ночи, пытаясь как можно быстрее создать первый продукт. Мы поставили себе жесткие сроки: шесть месяцев, или 180 дней, на то, чтобы выпустить продукт на рынок и привлечь первых платных клиентов. График был изнурительным, но мы твердо решили уложиться в срок.

Наш продукт был таким сложным, в нем было так много динамичных элементов, что нам приходилось очень спешить, чтобы успеть. Не буду скрывать: первая версия была ужасна. Мы бесконечно спорили о том, какие баги нужно устранить, а какие можно оставить, от каких функций отказаться, а какие лучше сохранить. Это было замечательное и трудное время: мы очень надеялись на успех и при этом боялись, что наш продукт никому не понравится.

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

Близился день «икс», и мы боялись все больше и больше. В такой ситуации предприниматели часто пасуют и откладывают дату запуска. Их можно понять, но мы упорно шли вперед, ведь отложив выпуск продукта, стартап лишил бы себя возможности получить отзывы потребителей, которые были необходимы ему. Прошлые неудачи научили нас тому, что выпустить плохой продукт — это еще не самое худшее. Хуже всего — создать продукт, который никому не нужен. Итак, сжав зубы и заранее приготовившись извиняться, мы представили свое детище широкой публике.

И… ничего не произошло! Оказалось, что нам нечего было бояться, ведь никто даже не попробовал воспользоваться нашим продуктом. Сначала я почувствовал облегчение — по крайней мере никто не узнал, насколько он плох. Но затем я впал в уныние. Мы часами спорили о том, какие опции оставить и какие баги устранить, а наш продукт оказался настолько незаметным, что клиенты даже не потрудились выяснить, каков он. Его не загрузил ни один человек.

Следующие недели и месяцы мы упорно улучшали продукт. Мы добились стабильного притока клиентов благодаря регистрации и загрузке онлайн. Мы считали, что каждый клиент — это еще одна возможность выяснить, хорошо ли мы работаем. В конечном счете мы поняли, как нужно изменить позиционирование продукта, чтобы пользователи хотя бы стали загружать его. Мы каждый день устраняли баги и вводили все новые и новые изменения. Но, несмотря на все наши усилия, платных пользователей у нас почти не было.

Сейчас я понимаю, что тогда мы приняли как минимум одно правильное решение: поставили перед собой четкие финансовые цели на начальный период. В первый месяц мы планировали получить $300 дохода, и нам это удалось — с трудом. Мы просили (ну ладно, умоляли) подписаться на наш продукт друзей и родственников. Каждый месяц мы немного повышали финансовую планку, сначала до $350, а потом — до $400. Но дальше становилось все сложнее. Скоро мы охватили всех знакомых и уже не знали, как быть дальше. Мы каждый день делали все, что могли, а поведение клиентов не менялось: они все равно не хотели пользоваться нашим продуктом. Нам никак не удавалось привлечь их. Поэтому мы стали приглашать пользователей к себе в офис. Мы брали у них интервью и тестировали удобство и простоту использования продукта. Финансовые цели побуждали нас проводить опросы и подсказывали, какие вопросы задавать, — этот паттерн мы еще не раз увидим на страницах книги.

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

В полном отчаянии мы решили пообщаться с представителями нашей целевой аудитории. Мы приглашали их в офис и говорили: «Вот новый продукт. Он называется IMVU». Если перед нами были подростки, пользователи IM-сетей, или ранние последователи технологических инноваций, им нравился продукт и они начинали им пользоваться. А обычные люди часто говорили: «Да? А зачем мне это нужно?» Поэтому с группой «обычных пользователей» мы так ничего и не добились: продукт IMVU казался им слишком странным.

Представьте себе, как 17-летняя девчонка сидит в нашем офисе и смотрит на наш продукт. Она выбирает «аватар» и говорит: «О, это круто». Настраивает «аватар», решает, как он будет выглядеть. Мы говорим: «Хорошо, давай теперь загрузим дополнение для мгновенных сообщений». Она спрашивает: «А что это такое?» — «Ну, это такая штука, которая взаимодействует с IM-клиентом». Она смотрит на нас и думает: «Я никогда об этом не слышала, мои друзья никогда об этом не слышали, почему эти люди хотят, чтобы я это сделала?» Ей нужны объяснения, она не знает, что такое дополнение для IM-клиента.

Но мы сидим рядом, и нам удается уговорить ее загрузить дополнение. Она загружает продукт, и мы говорим: «А теперь пригласи кого-нибудь из своих друзей поболтать». Она отвечает: «Не получится!» Мы спрашиваем: «Почему?» И она говорит: «Ну, я не знаю, достаточно ли крутая эта штука. Вы хотите, чтобы я рискнула пригласить кого-нибудь из моих друзей? Что они обо мне подумают? Если это какая-то фигня, они же решат, что я дура!» И мы говорим: «Но это же неинтересно, если ты не будешь ни с кем говорить. Эта штука предназначена для того, чтобы общаться». Она смотрит на нас, и на ее лице отражается сомнение.

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

Клиенты продолжали говорить: «Я хочу пользоваться этим сам. Я хочу сначала это проверить и посмотреть, достаточно ли это круто, чтобы приглашать друзей». Наши программисты раньше разрабатывали видеоигры, так что мы поняли, что нам нужно: режим «один игрок». Мы создали версию для самостоятельной игры и снова стали приглашать клиентов в офис. Они настраивали «аватар» и загружали продукт, как раньше. Потом переходили в режим «один игрок», и мы говорили: «Поиграйте со своим “аватаром”, выберите ему одежду, посмотрите, как он двигается». А затем добавляли: «Итак, вы можете играть сами. А теперь пригласите кого-нибудь из друзей». Но клиенты отказывались: «Ни за что! Это не круто!» Мы отвечали: «А мы и не говорили, что это круто! Какой смысл в одиночестве пользоваться тем, что предназначено для общения?» Нам казалось, что мы достойны награды лишь за то, что слушаем пользователей. Но им наш продукт все равно не нравился. Все, что мы от них слышали: «Послушайте, дяденьки, вы не понимаете. Я что, дурак? Почему я должен приглашать друзей, не убедившись в том, что это круто?» На этом разговор заканчивался.

В полном отчаянии мы ввели опцию под названием ChatNow, позволяющую нажать кнопку и найти случайного собеседника в любой точке мира. Единственное, что у вас общего, — вы оба одновременно нажали на эту кнопку. И вдруг клиенты стали говорить: «О, это классно!»

Итак, мы приглашали их в офис, они использовали опцию ChatNow и иногда знакомились с кем-то, кто им нравился. Они говорили: «Ого, это отличный парень, я хочу добавить его в свой список контактов. Где мой список контактов?» И мы говорили: «Вам не нужен новый список контактов — вы можете пользоваться своим обычным списком контактов в AOL». Как вы помните, именно так мы собирались использовать наш сервис и надеялись, что это создаст сетевые эффекты и приведет к вирусному росту. Но клиент смотрел на нас и спрашивал: «Что я должен сделать?» И мы говорили: «Просто сообщите новому знакомому свой ник, чтобы внести его в свой список контактов». Тут он делал большие глаза и заявлял: «Вы что, шутите? Незнакомец в моем списке контактов?» На это мы отвечали: «Да, а иначе вам придется загрузить новый IM-клиент и создать новый список контактов». И человек говорил: «Вы хоть представляете себе, сколько IM-клиентов у меня уже есть?» — «Нет. Один? Или два?» Именно столько IM-клиентов использовал каждый из нас. Но подростки отвечали: «Да вы что! У меня их восемь!» Мы понятия не имели, сколько IM-клиентов принято использовать в их мире. Мы думали, что людям сложно осваивать новое программное обеспечение и они не станут перемещать своих друзей в новый список контактов. Оказалось, что это полная ерунда. Мы пытались рисовать диаграммы и показывать им, чем хороша наша стратегия, но клиенты не понимали, что такое сетевые эффекты и затраты на переключение. А когда мы пытались объяснить, почему они должны вести себя так, как мы хотим, они просто в изумлении качали головами.

Наши теоретические представления о том, как люди пользуются программным обеспечением, оказались совершенно устаревшими. В итоге после десятков встреч с клиентами до нас стало доходить, что концепция дополнения для IM-сервисов никуда не годится.

Наших клиентов не интересовало дополнение к IM-сервисам — им нужна была отдельная IM-сеть. Они были готовы осваивать новый IM-сервис. Оказалось, что они одновременно пользовались множеством разных IM-сетей и их не пугала перспектива пригласить своих друзей в новую сеть. Казалось, что им даже нравится преодолевать такие технические трудности. Но что еще более удивительно, наше предположение о том, что клиенты захотят использовать «аватары», чтобы общаться с друзьями, тоже оказалось ошибочным. Они хотели заводить новых друзей. А для этого трехмерные «аватары» подходят как нельзя лучше. Так, шаг за шагом, клиенты уничтожили нашу, на первый взгляд, блестящую первоначальную стратегию.

Возможно, вы посочувствуете нам и простите мне мое упрямство. В конце концов, ведь это результаты моего многомесячного труда предстояло выбросить в мусорную корзину. Я круглыми сутками писал программы, чтобы наше IM-дополнение могло взаимодействовать с другими сетями — ведь именно на этом была основана первоначальная стратегия. Когда пришло время сделать крутой вираж и отказаться от нее, почти всю эту работу — тысячи строк кода — пришлось выбросить. Я чувствовал себя так, будто меня предали. Я был приверженцем гибкой методологии разработки программного обеспечения, позволяющей избежать излишних затрат. Тем не менее моя работа оказалась чрезвычайно затратной: я создал продукт, которым клиенты не стали пользоваться. Меня это ужасно угнетало.

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

Но, как я уже говорил в начале этой главы, у тех, кто хочет оправдать свои неудачи, всегда есть последнее прибежище. Я утешал себя тем, что если бы мы не создали этот первый продукт — со всеми его недостатками, — то никогда не узнали бы важной информации о клиентах. Мы никогда не узнали бы, что наша стратегия никуда не годится. В этом оправдании есть доля правды: то, чему мы научились в те важные первые месяцы, помогло IMVU найти путь, который и привел к последующим грандиозным успехам.

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

Система «экономичный стартап» рассматривает все действия стартапа как эксперименты, тестирующие его стратегию и призванные выяснить, какие элементы этой стратегии обоснованы, а какие — нет. Истинный эксперимент основан на научном подходе. Он начинается с выработки предположения о том, что может произойти. Затем это предположение проверяется опытным путем. Научные эксперименты основаны на теории, а эксперименты стартапа направляет его видение. Цель каждого такого эксперимента — выяснить, как создать жизнеспособный бизнес на основании видения стартапа.

Zappos — самый большой в мире интернет-магазин обуви. Его ежегодный оборот превышает миллиард долларов. Он считается одним из самых успешных и удобных интернет-магазинов в мире, но так было не всегда.

Все началось с того, что основатель компании Zappos Ник Суинмерн не смог найти ни одного крупного магазина с достойным выбором обуви. Он решил, что может предложить покупателям новую и гораздо более приятную альтернативу. Суинмерн мог бы подождать и сперва протестировать свое видение в полном объеме — со складами, партнерами-дистрибьюторами и прогнозируемыми объемами продаж. Многие пионеры электронной коммерции поступали именно так, в том числе и печально известные доткомы-неудачники, например Webvan и Pets.com.

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

Бизнес Zappos начался со скромного и простого сервиса. В первую очередь Суинмерн хотел выяснить одно: существует ли достаточный спрос на удобный интернет-магазин обуви? Однако продуманный эксперимент, такой, с которого начался Zappos, позволяет протестировать не только какой-то отдельный аспект бизнес-плана. В ходе тестирования первого предположения Суинмерн проверял и многие другие гипотезы. Чтобы продавать обувь, компании нужно взаимодействовать с потребителями: принимать оплату, как-то справляться с возвратом товара и создать службу поддержки клиентов. Такой подход решительно отличается от обычных маркетинговых исследований. Если бы Суинмерн полагался на результаты существующих маркетинговых исследований или провел такое исследование сам, он выяснил бы, чего хотят клиенты — по их собственному мнению. Но вместо этого он создал новый продукт, пусть и очень простой, и благодаря этому выяснил гораздо больше.

1. Компания собрала более точные данные о потребительском спросе, потому что смогла наблюдать реальное поведение потребителей, не задавая им теоретических вопросов.

2. Она получила возможность взаимодействовать с реальными клиентами и узнать об их потребностях. Например, в бизнес-плане можно обосновать необходимость скидок, но как повлияет стратегия скидок на восприятие продукта?

3. Клиенты стали вести себя так, как Суинмерн не ожидал, и благодаря этому он узнал то, о чем, возможно, даже не догадался бы спросить. Например, что делать, если клиенты начнут возвращать купленную обувь?

Первый эксперимент Zappos принес ясные, измеримые результаты: он дал ответ на вопрос, привлечет ли интернет-магазин обуви достаточно покупателей или нет. Он также позволил компании наблюдать поведение клиентов и партнеров, взаимодействовать с ними и учиться у них. Такое качественное обучение — необходимое дополнение количественного тестирования. Сначала действия компании имели весьма скромный размах, но это не помешало ей воплотить в жизнь свое грандиозное видение. В 2009 г. ее купил гигант электронной коммерции Amazon.com. По некоторым оценкам, сумма сделки составила $1,2 млрд.

Кэролайн Барлерин — директор подразделения глобальных социальных инноваций международной корпорации Hewlett-Packard (HP). Здесь работает более 300 000 сотрудников, а годовой доход корпорации составляет более $100 млрд. Кэролайн, руководителя проектов по работе с местными сообществами во всем мире, можно назвать социальным предпринимателем. Ее задача — привлекать сотрудников HP к участию в волонтерских проектах компании. Правила корпоративной политики HP поощряют каждого сотрудника тратить до четырех часов рабочего времени в месяц на волонтерские проекты в местном сообществе. Это могут быть самые разные проекты: покрасить забор, построить дом или даже бесплатно предложить кому-то свои профессиональные услуги. Этот, последний вид волонтерской деятельности Кэролайн особенно поощряет. Таланты и общие усилия сотрудников НР могут принести много пользы. Например, если дизайнер поможет некоммерческой организации разработать новый дизайн веб-сайта, а инженеры проложат кабель в школе, чтобы обеспечить детям доступ в Интернет.

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

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

Проект Кэролайн развивается в условиях чрезвычайной неопределенности: раньше НР никогда не проводила волонтерских кампаний такого масштаба. Как же выяснить истинные причины, по которым сотрудники не участвуют в волонтерской деятельности? И что нужно знать Кэролайн, чтобы изменить поведение сотен тысяч людей более чем в 170 странах? Ее цель — вдохновить коллег на то, чтобы делать мир лучше. С этой точки зрения ее план, кажется, полон непроверенных предположений и основан по большей части на ее видении.

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

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

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

Система «экономичный стартап» позволяет проверить все эти предположения с помощью строгих научных методов, быстро и комплексно. Стратегическое планирование занимает месяцы, а к экспериментам можно приступить немедленно. Начав с малого, Кэролайн сможет избежать огромных затрат в будущем, не ставя при этом под угрозу свое видение. Так что может сделать Кэролайн, если отнесется к своему проекту как к эксперименту?

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

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

Эксперимент поможет найти более точные показатели. Можно привлечь нескольких сотрудников к участию в волонтерских проектах, а потом оценить, насколько это их увлечет. Многие ли из них захотят снова участвовать в волонтерских проектах? Если сотрудники будут добровольно тратить время и силы на подобную деятельность — это надежный показатель того, что они считают ее ценной.

Можно провести такой же анализ гипотезы роста и выяснить, как новые клиенты узнают о товаре или услуге. Когда новый проект будет создан и запущен, как информация о нем будет распространяться внутри компании? Скорее всего, это будет «вирусное» распространение. Если так, то важнее всего оценивать поведение: станут ли ранние последователи активно рассказывать о проекте другим сотрудникам?

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

Затем, с помощью метода, который я называю «минимально рабочим продуктом» (MVP, от minimum viable product, подробнее мы поговорим о нем в главе 6), Кэролайн может предоставить первым участникам волонтерских проектов возможность получить как можно более позитивный опыт, в полном соответствии с ее видением. Такой подход кардинально отличается от сбора информации через фокус-группы, потому что позволяет оценить не то, что люди говорят, а то, что они делают. Например, сколько из первых волонтеров доведут свои проекты до конца? Сколько выразят желание снова принять участие в подобных проектах? Сколько из них будут готовы пригласить коллегу в следующий волонтерский проект?

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

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

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

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

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

Многие допущения типичного бизнес-плана вполне заурядны и основаны на знании ситуации в отрасли или на простых логических заключениях. В случае с Facebook изначально было ясно, что рекламодатели будут платить за внимание посетителей сайта. Но среди таких незатейливых предположений есть несколько допущений, требующих определенной смелости и даже нахальства: мы предполагаем, что люди захотят пользоваться нашим продуктом или что супермаркеты с радостью согласятся продавать его. Способность действовать так, будто эти предположения верны, — одна из самых сильных сторон предпринимателей. Такие принципиальные допущения называют «прыжками веры»[7], и это очень точное название, ведь они строятся только на ваших предположениях, а между тем от них зависит успех всего предприятия. Если они соответствуют действительности, перед нами откроются огромные возможности. Если нет — стартап ждет сокрушительный провал.

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

Однако, когда приводятся подобные аналогии, никто не говорит о том, что на самом деле речь идет о «прыжке веры». Но в этом и заключается их цель: сделать так, чтобы бизнес казался менее рискованным, и убедить в этом инвесторов, сотрудников или партнеров. Большинство предпринимателей содрогнулись бы, если бы их «прыжок веры» был описан следующим образом:

В этом описании есть несколько интересных моментов. Во-первых, важно ясно изложить факты. Правда ли, что именно технология прогрессивной загрузки изображений привела к быстрому развитию Интернета или это был всего лишь один фактор из многих? Что еще важнее — действительно ли многие люди уже готовы пользоваться нашим продуктом? Первая аналогия была призвана убедить все заинтересованные стороны в том, что разумно было бы создать новую технологию и посмотреть, станут ли люди ею пользоваться. Второе утверждение показывает, что сначала нужно провести тестирование: давайте выясним, есть ли на рынке достаточно клиентов, готовых пользоваться нашей новой технологией?

Стратегия, основанная на сравнении предложения компании с продуктами других компаний и отраслей, вполне оправдана. Такой подход действительно помогает обнаружить допущения, которые не относятся к «прыжкам веры». Венчурный капиталист Рэнди Комисар обсуждает концепцию «прыжка веры» в книге «Поиск бизнес-модели. Как спасти стартап, вовремя сменив план» (Getting to Plan В)[8]. Для разработки стратегии он предлагает использовать «аналоги» и «антианалоги».

Он объясняет концепцию аналогов-антианалогов на примере iPod. «Если бы мы искали аналоги, то могли бы вспомнить Walkman, — пишет он. — Walkman ответил на важнейший вопрос, который уже не пришлось задавать Стиву Джобсу: будут ли люди слушать музыку в общественных местах через наушники? Сегодня этот вопрос кажется нам абсурдным, но он — самый важный. Когда этот вопрос задала компания Sony, она еще не знала ответа».

У Стива Джобса ответ уже был, ведь аналогом iPod был плеер Walkman компании Sony. Кроме того, Джобсу пришлось считаться с тем, что люди были готовы загружать музыку, но не хотели за это платить. «Сайт Napster был антианалогом. Этот антианалог должен был побудить Джобса развивать бизнес определенным образом, — пишет Комисар. — На основании таких аналогов и антианалогов возникли новые вопросы, на которые еще не было ответа. Это и есть “прыжки веры”, которые я, как предприниматель, совершаю, если собираюсь довести свою затею до конца. От них зависит успех или провал моего бизнеса. В случае с iPod один из “прыжков веры” заключался в том, что люди станут платить за музыку». Конечно, этот «прыжок веры» оказался правильным.

Может показаться, что многие известные предприниматели заработали свои миллионы, потому что просто оказались в нужном месте в нужный момент. Но на каждого успешного предпринимателя, оказавшегося в нужном месте в нужный момент, найдется много других, тоже оказавшихся в том же месте в тот же момент, но однако же потерпевших неудачу. В начале ХХ века следом за Генри Фордом устремились почти 500 других предпринимателей. Представьте себе, что вы хотите создать автомобиль, знакомы с самыми передовыми инженерными методами, и перед вами открывается одна из величайших коммерческих возможностей в истории. Но подавляющему большинству из этих 500 смельчаков не удалось заработать ни цента. Тот же феномен мы наблюдали в случае с Facebook: с самого начала она столкнулась с конкуренцией со стороны других социальных сетей для студентов, но все они в итоге сошли с дистанции.

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

Как мы видели в истории Facebook, есть два самых важных «прыжка веры»: гипотеза ценности и гипотеза роста. Первый шаг в разработке нового товара или услуги — выяснить, создают они ценность или разрушают ее. Я использую экономические термины и говорю о ценности, а не о прибыли, ведь среди предпринимателей есть люди, которые создают некоммерческие социальные проекты, работают в общественном секторе и оценивают свой успех не только деньгами. Кроме того, есть множество организаций, которые быстро становятся прибыльными, но очень скоро разрушают ценность — например, организаторы «пирамид», мошенники или компании, нечистые на руку (вспомните Enron и Lehman Brothers).

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

Такие компании занимаются тем, что я называю «пантомимой успеха». Они создают видимость роста, чтобы всем казалось, будто они успешны. Одна из целей метода учета инноваций, о котором мы подробно поговорим в главе 7, заключается в том, чтобы научиться отличать такие «дутые» стартапы от истинных новаторов. В традиционной стандартной отчетности новые предприятия принято оценивать по тем же стандартам, что используются в крупных стабильных компаниях, но такие критерии не способны надежно прогнозировать будущие перспективы стартапа. Вспомните такие компании, как Amazon.com, пережившие на пути к огромному успеху серьезные неудачи.

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

Цифры — это прекрасно, но я всегда напоминаю предпринимателям, что за любыми цифрами стоят люди. Сколько бы посредников ни находилось между компанией и ее потребителями, в конечном итоге клиенты — это живые, думающие, покупающие люди. Их поведение можно наблюдать, и оно меняется. И даже если вы продаете свои товары не частным потребителям, а организациям, полезно помнить, что в них тоже работают люди. Успех любой модели продаж зависит от того, позволяет ли она увидеть за фасадом организации живых людей.

Стив Бланк уже много лет убеждает предпринимателей в том, что информацию, которую нужно собрать о клиентах, рынках, поставщиках и каналах сбыта, можно найти только «на улице». Стартапу необходимо очень тесно контактировать с потенциальными клиентами, чтобы понять их. Так что вставайте из-за стола и отправляйтесь знакомиться с ними!

Первое, что вы должны сделать, — убедиться в том, что ваши «прыжки веры» обоснованны, что у потребителей действительно есть серьезная проблема, которую надо решить[10]. Когда в 1982 г. Скотт Кук начал создавать компанию Intuit, у него было видение — довольно смелое для того времени, — что в один прекрасный день люди начнут использовать персональные компьютеры для оплаты счетов и управления своим бюджетом. Кук оставил работу консультанта, совершил прыжок в неизвестность и стал предпринимателем. Но он решил не полагаться на бесконечные маркетинговые исследования или теоретический анализ рынков. Вместо этого он взял телефонные справочники калифорнийского города Пало-Альто, где он тогда жил, и деревни Уиннетка, расположенной в штате Иллинойс.

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

Его первые разговоры с потенциальными клиентами не касались характеристик возможного сервиса — это было бы бессмысленно. Тогда лишь немногие разбирались в персональных компьютерах, и люди просто не знали, для каких целей можно использовать это устройство. Кук общался с самыми обычными людьми, а не с ранними последователями. Но эти разговоры помогли ему понять самое главное: если компании Intuit удастся решить эту проблему, у нее появится множество клиентов, и он сможет создать прибыльный бизнес.

Цель этих первых контактов с клиентами не в том, чтобы получить точные ответы на все вопросы. Они призваны прояснить, причем пока что на самом элементарном уровне, понимаем ли мы наших потенциальных потребителей и их проблемы. Если нам удастся их понять, мы сможем создать «архетип потребителя» — небольшой документ, который «очеловечивает» предполагаемого целевого клиента. Архетип потребителя — самое важное руководство по разработке продукта. Оно гарантирует, что ежедневные решения о приоритетах, которые приходится принимать любой команде разработчиков, будут соответствовать потребностям тех людей, которых стремится привлечь компания.

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

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

Большинство людей воспринимает статистику и отчетность как нечто сухое и скучное, нужное, главным образом, для того, чтобы подготовить финансовый отчет и пережить аудит. Это своего рода неизбежное зло. Но мы думаем так лишь потому, что воспринимаем отчетность как нечто само собой разумеющееся. Исторически сложилось так, что под руководством таких людей, как Альфред Слоун из General Motors, отчетность стала основным элементом централизованного управления крупными подразделениями. Она позволяла GM ставить перед каждым подразделением четкие задачи и заставляла руководителей этих подразделений отвечать за их выполнение. Все современные корпорации используют ту или иную версию этого подхода. Отчетность — ключ к их успеху.

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

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

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

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

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

Учет инноваций позволяет основателям стартапа убедиться в том, что у них действительно получается создать работающий бизнес. Он начинается с превращения «прыжков веры», о которых мы говорили в главе 5, в количественную финансовую модель. В любом бизнес-плане, даже если он написан на салфетке, есть та или иная модель, связанная с принципиальными допущениями. Такая модель основана на предположениях о том, каким может стать успешный бизнес в будущем.

Например, бизнес-план для крупной производственной компании может прогнозировать, что она будет расти пропорционально объемам продаж. Прибыль от продаж повторно инвестируется в маркетинг и продвижение товаров, и компания привлекает новых клиентов. Темпы роста зависят прежде всего от трех показателей: прибыльности каждого клиента, стоимости привлечения новых клиентов и количества повторных покупок, совершенных существующими клиентами. Чем выше эти цифры, тем быстрее будет расти компания и тем более прибыльной она будет. Это и есть драйверы модели роста компании.

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

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

Учет инноваций предполагает три этапа. Во-первых, нужно создать минимально рабочий продукт, чтобы получить данные о том, какова реальная ситуация на текущий момент. Без ясного представления о настоящем положении дел — какой бы далекой ни была ваша цель, — невозможно понять, где именно вы находитесь.

Во-вторых, нужно постараться приблизить базовые показатели к идеальным. Здесь может потребоваться множество попыток. После того как стартап совершил все микроизменения и оптимизировал продукт, он может приближать свои базовые показатели к идеалу, и тогда наступает третий этап, когда нужно решить — совершить вираж или двигаться дальше выбранным курсом.

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

Например, стартап может создать готовый опытный образец своего продукта и начать продавать его реальным пользователям через свой основной канал маркетинга. Этот единственный MVP протестирует все основные начальные допущения стартапа и сразу же установит базовые показатели для каждого из них. Или же можно создать несколько разных MVP, которые позволят получить обратную связь по каждому допущению отдельно.

Прежде чем выпускать опытный образец, компания может провести «дымовое тестирование» на основании своих рекламных материалов. Это традиционный метод директ-маркетинга, когда клиенты могут заранее заказать продукт, которого еще не существует. «Дымовое тестирование» показывает лишь одно: интересно ли клиентам познакомиться с продуктом. Но сам по себе такой тест не позволит во всех деталях проверить модель роста. Тем не менее иногда полезно бывает получить обратную связь от потенциальных клиентов, прежде чем вкладывать в разработку продукта деньги и другие ресурсы.

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

Из множества начальных допущений, изложенных в бизнес-плане, имеет смысл в первую очередь тестировать самые рискованные. Ведь если не удастся найти способ снизить риски до показателей, необходимых для создания жизнеспособного бизнеса, нет смысла тестировать остальные предположения. Например, перед медиабизнесом, который продает рекламу, стоят два главных вопроса: удастся ли привлечь внимание определенного сегмента потребителей и постоянно удерживать его и можно ли продать это внимание рекламодателям? Если стоимость рекламы для определенного сегмента потребителей известна, то допущение относительно способности привлекать внимание более рискованно. Поэтому первые эксперименты должны быть связаны с созданием контента, а не с продажей рекламы. Возможно, компания может создать пилотный эпизод, серию или статью, чтобы увидеть реакцию потребителей.

Как только установлены базовые показатели, можно переходить ко второму этапу обучения: настройке механизма роста. Каждая инициатива стартапа в сфере разработки продукта, маркетинга или в чем-то еще должна быть направлена на совершенствование одного из драйверов модели роста. Например, компания может потратить время на улучшение дизайна продукта, чтобы новым потребителям было легче им пользоваться. Это оправданно, если скорость привлечения новых клиентов — драйвер роста, но пока она ниже, чем хотела бы компания. Чтобы получать обоснованные знания, изменения в дизайне должны ускорять привлечение новых потребителей. Если этого не происходит, значит, новый дизайн оказался неудачным. Это важное правило: хороший дизайн — тот, который меняет поведение потребителей к лучшему.

А теперь давайте сравним два стартапа. Первая компания установила четкие базовые показатели, разработала план по их улучшению и задумала ряд экспериментов, чтобы проверить свои предположения. Члены второй команды без конца спорят о том, как усовершенствовать продукт, вводят несколько изменений одновременно и радуются, если какие-то цифры начинают расти. Какой стартап работает эффективнее и добьется более стабильных результатов?

Со временем команда, которая учится и ищет путь к созданию жизнеспособного бизнеса, видит, что цифры в ее модели начинают расти от самых низких базовых показателей, установленных MVP, и приближаются к идеалу, намеченному в бизнес-плане.

Если же этого не происходит, то идеал будет все больше отдаляться. И этот очевидный факт от себя не скроешь, сколько ни упорствуй: если драйверы нашей бизнес-модели не меняются, значит, мы никуда не движемся. Это верный признак того, что пришло время совершить вираж.

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

В ночь перед собранием правления мы проводили стандартный анализ, оценивая скорость привлечения пользователей, их количество и доходы, чтобы показать, как хорошо мы поработали. Но этот анализ лишь усугублял наше паническое состояние, потому что повышение качества продукта никак не влияло на поведение пользователей. Несколько заседаний правления были весьма неприятными. Мы могли продемонстрировать значительный «успех», но это почти никак не отражалось на финансовых результатах. Спустя какое-то время мы, вместо того чтобы оставлять все на последний момент, начали отслеживать показатели чаще, сократив цикл обратной связи в сфере разработки продукта. Показатели оказались еще более неутешительными. Шли недели, мы меняли опции продукта, но это ни к чему не приводило.

Мы отслеживали те аспекты поведения клиентов, которые считали самыми важными для нашего механизма роста: регистрацию, загрузку приложения, использование пробной версии, покупку продукта. Чтобы получить достаточно данных, нам нужно было привлечь достаточно пользователей — так мы могли получить реальные цифры для каждого типа поведения. Мы выделили на это бюджет в $5 в день: этого было достаточно для покупки кликов в системе AdWords компании Google. В те дни минимальная стоимость клика составляла 5 центов и никаких ограничений не было. Поэтому мы смогли позволить себе открыть счет и начать экспериментировать, почти не тратя денег[12].

Каждый день $5 приносили нам 100 кликов. С точки зрения маркетинга это не слишком много, но с точки зрения обучения это было бесценно. Каждый день мы могли оценивать успех продукта в совершенно новой группе пользователей. Кроме того, каждый раз, когда мы изменяли те или иные опции продукта, уже на следующий день мы получали совершенно новые данные о ситуации.

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

Каждый день был новым экспериментом. Информацию о поведении клиентов мы анализировали отдельно от данных о других клиентах, полученных в предыдущем тесте. Общие показатели росли, но скоро стало ясно: то, что интересует нас больше всего, не меняется. Это, в частности, демонстрировал график, представленный нами на одном из первых заседаний правления IMVU (см. рис. 7).

Этот график отражает приблизительно семь месяцев работы. В этот период мы неустанно совершенствовали продукт, ежедневно добавляя новые опции. Мы постоянно проводили личные интервью с пользователями, и разработчики продукта работали очень напряженно.

Чтобы понять этот график, нужно знать, что такое когортный анализ. Это один из самых важных инструментов анализа для стартапа. Он может показаться сложным, но основан на одной простой предпосылке. Вместо того чтобы оценивать совокупные общие показатели, например общий доход и общее количество потребителей, мы оцениваем показатели отдельно по каждой группе потребителей, которая вступает в контакт с продуктом независимо от остальных групп. Каждую такую группу называют когортой. График показывает скорость появления у IMVU новых клиентов в каждом из указанных месяцев. Показатели скорости привлечения клиентов показывают процент пользователей, которые зарегистрировались в этом месяце и впоследствии продолжали повторять обозначенные действия. Таким образом, среди всех клиентов, присоединившихся к IMVU в феврале 2005 г., около 60 % повторно пользовались продуктом хотя бы один раз.

Менеджеры, работающие в сфере продаж, увидят, что такой анализ напоминает традиционный анализ «воронки продаж», который помогает понять, что нужно сделать, чтобы превратить потенциальных клиентов в реальных. «Экономичный стартап» использует его также и в сфере разработки продукта. Этот метод полезен во многих сферах бизнеса, потому что выживание любой компании зависит от последовательных паттернов поведения потребителей, которые называют потоками. Такие потоки управляют взаимодействием клиентов с продуктами компании. Они позволяют оценивать и анализировать бизнес количественно и прогнозировать ситуацию гораздо точнее, чем традиционные общие показатели.

Если присмотреться, мы увидим, что график демонстрирует несколько четких тенденций. Некоторые действия по совершенствованию продукта оказались удачны — но не настолько, чтобы повлиять на ситуацию. Процент новых клиентов, пользовавшихся продуктом как минимум пять раз, вырос, от менее чем 5 % до почти 20 %. Однако же, несмотря на такое четырехкратное увеличение, процент новых пользователей, которые платили нам деньги, застрял в пределах 1 % и не двигался с места. После долгих месяцев работы, тысячи отдельных усовершенствований, фокус-групп, постоянного тестирования дизайна, повышения удобства и простоты использования процент новых клиентов, готовых платить деньги, остался точно таким же, как и в самом начале, хотя гораздо больше пользователей имели возможность познакомиться с продуктом.

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

Я руководил командой разработки продукта и сказал нашим соучредителям, что эту проблему должна решить моя команда. Я работал все больше и больше, пытался придумать все более и более качественные опции и почти не спал. Наше раздражение росло. Наконец я уже не мог ничего придумать и решил испробовать последнее средство: пообщаться с пользователями. Измученный неудачными попытками настроить механизм роста, я начал-таки задавать правильные вопросы.

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

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

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

Неутешительные количественные результаты вынуждают нас признать неудачу и создают мотивацию, контекст и пространство для более качественного анализа. Такие исследования приводят к новым идеям — новым гипотезам, которые можно тестировать, и, возможно, к виражу. А каждый вираж, в свою очередь, открывает новые возможности для дальнейших экспериментов, и цикл повторяется. Каждый раз мы проходим по этому кругу: устанавливаем базовые показатели, настраиваем механизм и пытаемся понять: стоит ли совершить крутой поворот или лучше продолжать двигаться выбранным курсом.

Чтобы лучше понять, почему так важны правильные показатели, давайте познакомимся с компанией под названием Grockit. Ее основатель Фарбуд Ниви 10 лет был преподавателем в двух крупных коммерческих образовательных компаниях — Princeton Review и Kaplan. Эти компании помогают студентам готовиться к сдаче стандартизированных тестов. Его учебные программы получали похвалы от студентов и признание начальства, он был удостоен награды «Учитель года» компании Princeton Review. Но Фарб никогда не был поклонником традиционных методов обучения, которые используют эти компании. Он преподавал по шесть-девять часов в день, имел дело с тысячами студентов, и у него была масса возможностей экспериментировать с новыми подходам.

Постепенно Фарб стал понимать, что традиционная модель лекционного обучения, одинаковая для всех, подходит не всем студентам. Он решил создать другой метод, основанный на сочетании лекций, самостоятельной домашней работы и обучения в группе. В частности, Фарба увлекал метод обучения «от студента к студенту», который оказался исключительно эффективным. Помогая друг другу, студенты получали двойную пользу. Во-первых, индивидуальные инструкции им давал партнер, которого они боялись гораздо меньше, чем преподавателя. Во-вторых, обучая других, они лучше учились сами. Постепенно занятия Фарба становились все более «интерактивными» — и более успешными.

В процессе Фарб стал замечать, что его физическое присутствие в классе не так уж важно. Он сделал важное открытие: «У себя в классе я ввел “социальную” модель обучения. Но все эти “интерактивные” вещи можно делать и в Сети». У него родилась идея: предложить «социальное» обучение «от студента к студенту» тем, кто не может позволить себе нанять репетитора или заплатить за посещение занятий в школах Kaplan и Princeton Review. Так родилась компания Grockit.

Фарб говорит: «Если вы готовитесь к сдаче теста SAT или учите алгебру, то у вас есть три варианта обучения. Вы можете работать с преподавателем, учиться самостоятельно и общаться с другими учениками. Grockit предлагает все эти три формата. Мы используем технологию и алгоритмы, позволяющие оптимизировать эти формы обучения».

Фарб — настоящий предприниматель-новатор. Он описывает свою идею так: «Давайте забудем о существующих подходах к обучению, о том, что возможно, а что — нет, и просто найдем новые методы, подходящие для современных студентов и современных технологий. В сфере образования работает множество крупных традиционных организаций, и я не думаю, что они станут вводить новаторские методы, такие методы, которые нужны сегодня, а я уверен, что они нужны. Для меня важнее всего — студенты, а я не вижу, чтобы они получали лучшее из возможного».

Сегодня Grockit предлагает множество различных образовательных программ, но в начале Фарб следовал методологии бережливого производства. Grockit создала минимально рабочий продукт. Это был простой курс подготовки к тесту, который можно было пройти с помощью популярного веб-инструмента для конференц-связи WebEx. Фарб не стал создавать ни специального программного обеспечения, ни новой технологии. Он просто попытался донести свой новый подход к обучению до студентов через Интернет. Информация о новом виде частного обучения быстро распространялась, и через несколько месяцев преподавание онлайн уже приносило Фарбу приличный доход. Он зарабатывал от $10 000 до $15 000 в месяц. Но как и многие другие амбициозные предприниматели, Фарб создал свой MVP не только для того, чтобы зарабатывать на жизнь. Он хотел создать более эффективный, интерактивный метод обучения для студентов по всему миру. И благодаря первым успехам смог добиться финансирования от некоторых из лучших инвесторов в Кремниевой долине.

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

Команда Фарба была чрезвычайно ориентирована на процесс и дисциплинированна. Она следовала самой строгой версии гибкой методологии разработки, которая называется Extreme Programming (она описана ниже), предложенной компанией из Сан-Франциско Pivotal Labs, с которой Grockit заключила партнерское соглашение. Первый продукт компании пресса назвала «прорывом».

Была только одна проблема: компания не видела большого притока клиентов. Пример Grockit очень показателен, потому что ее проблемы не были связаны с неудачной концепцией или недостатком дисциплины.

Следуя стандартным методам гибкой разработки, Grockit провела серию быстрых циклов итерации длительностью один месяц. Для каждого такого ежемесячного цикла Фарб расставлял приоритеты, создавая серию пользовательских историй — это метод также взят из методологии гибкой разработки. Вместо того чтобы разрабатывать спецификации для новой опции в технических терминах, Фарб описывал ее с точки зрения клиента. Это помогало разработчикам взглянуть на свою работу с позиций будущего пользователя.

Каждая опция была описана простыми словами, понятными всем — и тем, кто знаком с технологиями, и тем, кто не знаком. Кроме того, в соответствии со стандартной процедурой гибкой разработки Фарб мог в любой момент менять приоритеты. Узнав что-то новое о потребностях клиентов, он мог поменять местами задачи в плане разработки продукта. Единственное ограничение было в том, что Фарб не мог прервать выполнение задачи, если оно уже началось. К счастью, на выполнение задач уходило всего один-два дня.

Эту систему не зря называют гибкой разработкой: она позволяет быстро менять направление и чутко реагировать на новые бизнес-требования заказчика продукта (того, кто руководит процессом, в данном случае — Фарба).

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

Однако я видел, что Фарб и его команда не могут побороть сомнения. Вызван ли рост цифр их усилиями по развитию? Или это происходит благодаря другим факторам, например упоминаниям о Grockit в прессе? На встрече с членами команды я задал простой вопрос: «Откуда вы узнаете, что решения о приоритетах, которые принимает Фарб, правильны?» Члены команды ответили: «Это не в нашей компетенции. Фарб принимает решения, а мы их просто выполняем».

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

Я спросил Фарба: «Как вы узнаете, что принимаете правильные решения с точки зрения расстановки приоритетов?» Как и большинство основателей стартапов, он анализировал доступные данные и делал на их основании настолько адекватные предположения, насколько мог. Но это неизбежно приводило к неуверенности и сомнениям.

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

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

Гибкая методология разработки довольно эффективна с точки зрения разработчиков. Она позволяет им сосредоточиться на разработке опций и на технических аспектах. Попытка ввести в этот процесс потребность учиться может снизить производительность. (Когда метод бережливого производства стали вводить на предприятиях, возникли похожие проблемы. Менеджеры привыкли учитывать коэффициент загрузки каждой машины. Предприятия были организованы так, чтобы машины работали с полной мощностью — и как можно дольше. С точки зрения загрузки отдельной машины это эффективно, но с точки зрения производительности всей фабрики это иногда крайне неэффективно. Как говорят в теории систем, при оптимизации одной части системы мы обязательно снижаем эффективность системы в целом.)

Фарб и его команда не понимали, что прогресс Grockit оценивается на основании «показателей тщеславия»: общее количество клиентов и общее количество вопросов, на которые получены ответы. Именно это заставляло его команду действовать: эти показатели создавали у команды ощущение движения вперед, хотя ее успехи все еще оставались весьма скромными. Интересно, как точно метод Фарба следовал этапам обучения по системе «экономичный стартап»: компания создала раннюю версию продукта и установила некоторые базовые показатели. Она делала относительно короткие итерации, и каждую из них оценивала в соответствии с тем, улучшает ли она показатели, отражающие активность пользователей.

Однако Grockit использовала не те показатели и на самом деле не развивалась. Фарба беспокоило, что компания не делает выводов из обратной связи от пользователей. В каждом цикле менялись показатели, на которых была сосредоточена его команда: в один месяц она рассматривала общие показатели использования, в другой — число зарегистрировавшихся пользователей, и т. д. Казалось, приоритеты меняются сами собой. Невозможно было установить ясные причинно-следственные связи. Правильно расставить приоритеты в такой ситуации очень сложно.

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

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

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

В эксперименте по сплит-тестированию клиентам одновременно предлагаются разные версии продукта. Наблюдая изменения в поведении между теми, кто пользуется разными версиями, можно сделать выводы о влиянии разных изменений. Этот метод впервые стали использовать рекламодатели в сфере директ-мейла. Например, компания отправляет клиентам каталог продукции. Если вы хотите протестировать его дизайн, то можете отправить 50 % клиентов новую версию, а другим 50 % — старую, стандартную версию каталога.

Чтобы добиться научной чистоты эксперимента, оба каталога должны содержать одни и те же товары. Отличаться должен только дизайн. Чтобы выяснить, какой дизайн лучше, достаточно просто отслеживать объемы продаж для обеих групп клиентов. (Этот метод иногда называют A/B-тестированием, потому что каждой из версий каталога присваивалась та или другая буква.) Часто считается, что сплит-тестирование можно использовать только в маркетинге (или даже только в директ-маркетинге). Но в системе «экономичный стартап» оно включено в процесс разработки продукта.

Такие изменения сразу же позволили Фарбу взглянуть на свой бизнес по-новому. Сплит-тестирование иногда помогает выяснить удивительные вещи. Например, многие цифры, которые улучшают продукт в глазах разработчиков и дизайнеров, никак не влияют на поведение потребителей. Так произошло и в Grockit, и во всех остальных компаниях, использовавших этот метод, которые я наблюдал. Работать, проводя сплит-тестирование, кажется, труднее, потому что это требует дополнительного учета и показателей, позволяющих отслеживать каждое изменение. Но этот метод почти всегда позволяет сэкономить время, устраняя все, что не имеет значения для клиентов.

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

Это побудило команду попытаться лучше понять, чего же на самом деле хотят потребители. Ее участники провели мозговой штурм и нашли новые идеи для экспериментов. На самом деле во многих из этих идей не было ничего нового. Их просто не замечали раньше, потому что компания занималась созданием инструментов для коммуникаций. В результате Grockit протестировала интенсивный модуль для самостоятельного обучения, где были квесты и разные уровни, как в компьютерной игре, и где студенты могли выбирать: учиться самостоятельно или вместе с другими. Как и в классе у Фарба, это оказалось чрезвычайно эффективным. Без строгого сплит-тестирования компания могла бы этого так и не понять. Со временем, после десятков тестов, стало ясно, что больше всего студентов привлекает сочетание опций для самостоятельного обучения и для обучения в группе. Оказалось, что студенты хотят сами выбирать метод обучения.

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

Правило канбан гласит, что в каждой из четырех фаз может находиться только определенное количество историй. По мере того как истории переходят из одной фазы в другую, корзины заполняются. Если корзина заполнена, в нее не положишь еще одну историю. Только после проверки истории ее можно удалить с доски канбан. Если проверка показывает, что история неудачна, соответствующая опция удаляется (см. табл. 1, 2, 3).

Я вводил эту систему в нескольких командах, и всегда она поначалу вызывала неприятие: корзины быстро заполняются — сначала корзина «Проверка», а потом и корзина «Завершено». Скоро становится невозможно начать ни один новый проект. Команды, которые привыкли оценивать свою производительность только по количеству завершенных историй, начинают топтаться на месте. Единственный способ начать работу над новыми опциями — исследовать те проекты, которые до сих пор не прошли проверку. Здесь часто нужны действия, не связанные с разработкой: нужно общаться с клиентами, изучать данные сплит-тестирования и т. д.

Но очень скоро все учатся делать это. Сначала процесс происходит рывками. Разработчики могут завершить большой этап работы, а затем провести обширное тестирование и проверку. Изыскивая способы повысить производительность, они начинают понимать: если подумать о проверке с самого начала, то снизится общая производительность команды.

Например, стоит ли создавать новую опцию, которая не является объектом эксперимента по сплит-тестированию? Это может сэкономить немного времени, но позже, во время фазы проверки, потребуется больше времени на тестирование. Та же логика относится к истории, которой разработчик не понимает. По старой системе он просто создавал ее и лишь потом понимал, зачем она нужна. При новой системе становится очевидно, что такое поведение непродуктивно: как можно проверить историю, не имея ясной гипотезы? В IMVU мы тоже с этим сталкивались. Я как-то наблюдал, как разработчик убеждал провести тестирование идеи своего шефа, который хотел внести в продукт какое-то незначительное изменение. Разработчик настаивал на том, что новую опцию нужно подвергнуть сплит-тестированию, как и все остальные. Коллеги его поддержали: казалось совершенно очевидным, что нужно проверять все опции, независимо от того, кто поручил команде их разработку. (Должен признаться, слишком часто этим самым «шефом» был я сам.)

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

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

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

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

Я порекомендовал команде провести простое сплит-тестирование. Она выделила одну группу пользователей, от которой требовалась немедленная регистрация, но при этом пользователи могли только ознакомиться с рекламными материалами. Как ни странно, поведение этой группы было точно таким же, как и поведение той, которой предлагали «ленивую регистрацию»: тот же самый уровень регистрации, активации и последующего удержания. Иначе говоря, дополнительные усилия на поддержку «ленивой регистрации» были пустой тратой времени и сил, несмотря на то, что она считалась передовой практикой.

Этот тест позволил сократить затраты и привел к важному открытию: отношение клиентов к Grockit основано вовсе не на опыте использования продукта.

Представьте себе, что это значит. У группы пользователей, от которых требовали зарегистрироваться, прежде чем приступить к сеансу обучения вместе с другими студентами, почти не было информации о продукте — эти пользователи знали лишь то, что было написано на домашней странице сайта Grockit и на странице регистрации. У группы с «ленивой регистрацией», наоборот, было гораздо больше информации о продукте, потому что эти люди уже им пользовались. Тем не менее, несмотря на то, что разные пользователи были по-разному информированы, поведение в обеих группах было одинаковым.

Это показало, что для эффективного привлечения пользователей нужно заняться в первую очередь не новыми опциями, а позиционированием и маркетингом. Это был только первый из множества важных экспериментов, которые провела Grockit. С того времени компания значительно увеличила свою клиентскую базу: сейчас она предлагает подготовку к многочисленным стандартизированным тестам, а также онлайн-уроки математики и курсы английского для учеников 7–12-х классов.

Grockit продолжает оттачивать свои процессы и непрерывно совершенствуется. В ее офисе в Сан-Франциско работают больше 20 сотрудников, и компания по-прежнему следует продуманному и дисциплинированному подходу, который отличал ее с самого начала. Она уже помогла сдать тесты почти миллиону студентов и уверена, что может помочь миллионам других.

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

Отчет отражает действенные показатели, если он четко демонстрирует причинно-следственные связи. Если это не так, значит, он основан на «показателях тщеславия». Отчеты, которые стала использовать команда Grockit для оценки этапов обучения, очень ясно показывали, что нужно сделать, чтобы получить требуемые результаты.

«Показатели тщеславия», напротив, не могут указать, какие действия нужно предпринимать. Возьмем количество хитов на сайте компании. Скажем, у нас 40 000 хитов в этом месяце — настоящий рекорд. Что нам нужно сделать, чтобы получить больше хитов? Ну, мы не знаем, это зависит от многих факторов. Откуда появляются новые хиты? Благодаря 40 000 новых клиентов или в результате бешеной активности веб-браузера одного парня? Эти хиты — результат новой маркетинговой кампании или пиар-акций? И что такое хит? Считается ли каждая страница в браузере как один хит или встроенные изображения и мультимедийный контент тоже учитываются? Любому, кто хоть раз присутствовал на встрече, где обсуждались параметры показателя, приведенного в отчете, знакомы подобные проблемы.

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

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

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

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

Но против этого есть «противоядие». Во-первых, отчеты должны быть как можно более простыми и ясными, понятными для всех. Помните, что за любыми показателями стоят люди. Самый легкий способ написать понятный отчет — использовать определенные, конкретные понятия. Что такое хит на сайте? Этого никто не знает, но все знают, что такое посетитель сайта: можно нарисовать, как эти люди сидят за компьютерами.

Вот почему отчеты, основанные на когортном анализе, так эффективны для обучения организации — они превращают сложные действия в простые примеры, описывающие поведение людей. Каждый раз когортный анализ показывает: среди тех, кто пользовался нашим продуктом в этот период, столько-то людей продемонстрировали тот тип поведения, который для нас важен. В примере с IMVU мы видели четыре типа поведения: загрузка продукта, вход на сайт продукта с личного компьютера, чат с другими клиентами и покупка платной версии продукта. Иначе говоря, отчет связан с людьми и их действиями, что гораздо полезнее, чем массивы абстрактных данных. Например, подумайте о том, как трудно было бы сказать, успешно ли развивается IMVU, если бы в отчете мы сообщали только об общем количестве личных разговоров. Скажем, у нас есть 10 000 посетителей в данный период. Хорошо ли это? Это один очень-очень общительный человек или это 10 000 человек одновременно пытаются воспользоваться продуктом, а потом уходят с сайта? Чтобы узнать это, нужен более подробный отчет.

Когда общие показатели растут, ясность отчетов становится еще более значима. Что означает, если за месяц количество хитов на сайте сократилось с 250 000 до 200 000? Но почти каждый легко поймет, что значит потерять 50 000 клиентов — это целый стадион, полный людей, которые больше не хотят покупать ваш продукт.

Правило доступности также касается доступа к отчетам. Компания Grockit в этом отношении поступала очень правильно. Каждый день автоматически создавался документ, содержавший последние данные по каждому из экспериментов по сплит-тестированию и по другим показателям, связанным с «прыжками веры». Этот документ рассылался по электронной почте всем сотрудникам компании: у каждого всегда была самая свежая копия. Отчеты было легко читать, каждый эксперимент и его результаты описывались простым языком.

Еще один способ сделать отчеты доступными для всех — метод, который мы разработали в IMVU. Мы не стали выводить аналитику или данные в отдельную систему. Данные отчета и его инфраструктура считались частью самого продукта, и за них отвечала команда разработки. Отчеты выкладывались на нашем сайте и были доступны любому, у кого был аккаунт сотрудника.

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

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

Сотрудникам IMVU, как правило, удавалось улаживать споры, ссылаясь на отчеты об экспериментах, о которых я только что говорил. Но порой возникали сложности. Бывало и так, что, столкнувшись не с теми результатами, которых они ожидали, руководитель, или разработчик, или вся команда проекта начинали ставить под сомнение достоверность данных.

Такие проблемы возникают чаще, чем хотелось бы, и, к сожалению, обычные системы представления данных не помогают в их решении. Иногда так бывает из-за слишком рьяного желания защитить личные данные клиентов. Но чаще дело в пренебрежении к подготовке сопроводительной документации. Почти всегда системы представления данных создает не команда разработчиков, задача которых — расставлять приоритеты и совершенствовать опции продукта, а топ-менеджеры и аналитики. Менеджеры, которым приходится использовать такие системы, могут только посмотреть, не противоречат ли отчеты друг другу. Часто у них нет инструментов для того, чтобы проверить, соответствуют ли данные действительности.

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

Во-вторых, тем, кто составляет отчеты, нужны для этого простые механизмы. Отчеты должны быть основаны на базовых данных, а не на промежуточных результатах. Это снижает вероятность ошибок. Я заметил, что каждый раз, когда какое-то суждение или предположение оказывается неверным просто из-за ошибок в данных, это подрывает уверенность в своих силах, моральный дух и дисциплину сотрудников.

В мифологическим мире голливудского кино, книг и журналов мы постоянно видим преуспевающих предпринимателей. Их истории всегда преподносятся одинаково. Сначала мужественного главного героя озаряет гениальная идея. У него сильный характер и яркая индивидуальность. Мы видим, как он оказывается в нужном месте в нужный момент, совершает головокружительный прыжок и создает собственный бизнес.

Но дальше начинается «фотомонтаж». Обычно вся дальнейшая история укладывается в несколько минут. Мы видим, как главный герой собирает команду, проводит опыты в лаборатории, пишет формулы на доске, заключает сделки, в творческом экстазе печатает одновременно на нескольких клавиатурах. В итоге к нему приходит успех. Иногда история продолжается, и возникают не столь вдохновляющие темы: основатели компании не могут поделить деньги, спорят, кто из них появится на обложке журнала, подают друг на друга в суд и т. д.

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

Но одно решение важнее всех остальных: оно самое сложное, требует больше всего времени и приводит к самым значительным для большинства стартапов тратам. Но всем нам рано или поздно приходится пройти через это — наступает момент, когда надо решить, что делать дальше: круто повернуть в другую сторону или продолжать упорно следовать избранным курсом. Чтобы понять, чего нам не показывают в кино, нужно знать, что такое «вираж». Об этом мы и поговорим в главе 8.

Есть разные типы виражей. Слово «вираж» иногда используют неправильно, просто как синоним изменений. Но вираж — это особый вид изменений, он нацелен на то, чтобы проверить новую фундаментальную гипотезу о продукте, бизнес-модели и механизме роста.

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

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

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

Когда уже собрано достаточно данных о клиентах, иногда выясняется, что проблема, которую мы пытаемся для них решить, не так уж важна. Зато обнаруживаются новые, связанные с первой, проблемы, которые действительно важны и которые нашей команде вполне «по зубам». Однако, чтобы справиться с ними, недостаточно репозиционировать существующий продукт. Бывает так, что нужно разработать абсолютно новый продукт. И снова это тот случай, когда гипотеза продукта подтверждается, но только частично: у целевой аудитории есть проблема, которая нуждается в решении, однако не та, которую мы ожидали.

Такой вираж совершила, например, известная сеть Potbelly Sandwich Shop, имеющая сегодня больше 200 торговых точек. В 1977 г. ее основатели открыли антикварный магазин и, чтобы привлечь больше покупателей, стали продавать сэндвичи. В результате очень скоро они совершили вираж и ушли в совершенно другую область бизнеса.

Вираж платформы — это переход от приложения к платформе, или наоборот. Бывает, что стартап, стремившийся создать новую платформу, начинает с продаж единственного приложения, которое становится «убийцей» платформы. Но бывает и так, что выясняется: вместо одного продукта необходима целая линейка приложений, — и это приводит к тому, что продукт становится платформой. Иногда компании приходится совершать такой вираж несколько раз.

Такой вираж напоминает идею Джеффри Мура, который однажды заметил, что компании обычно следуют одной из двух базовых архитектур бизнеса: высокая доля прибыли и небольшие объемы продаж (модель сложных систем) или низкая доля прибыли и большие объемы продаж (модель объема операций)[14]. Первая модель обычно подразумевает продажи товаров и услуг предприятиям (B2B) или цикл продаж предприятия, а вторая — продажи потребительских товаров (хотя здесь бывают исключения). При вираже бизнес-архитектуры стартап меняет архитектуру. Некоторые компании отказываются от высокомаржинальной штучной модели продаж и выходят на массовый рынок (например, поисковая машина Google). Другие же, изначально ориентированные на массовый рынок, скоро понимают, что им нужен длительный и дорогостоящий цикл продаж.

Есть множество методов сохранить ценность, которую создает компания. Эти методы принято называть способами монетизации. Но это слишком узкий термин. Идея монетизации подразумевает, что ту или иную «опцию» продукта можно добавить или устранить по желанию. Но в действительности сохранение ценности — неотъемлемый элемент гипотезы продукта. Часто, изменив способ, которым компания сохраняет ценность, можно серьезно повлиять на остальные аспекты бизнеса, на продукт и стратегии маркетинга.

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

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

Например, Интернет произвел революцию в тех отраслях, которые раньше требовали сложных каналов дистрибуции, скажем, в сфере продаж газет, журналов и книг.

Иногда одно и то же решение можно предложить с помощью совершенно разных технологий. Вираж технологии чаще всего происходит в стабильных компаниях. Такой вираж — это поддерживающие инновации, постепенное совершенствование, предназначенное для того, чтобы привлечь и сохранить существующую клиентскую базу. Стабильным компаниям прекрасно удаются виражи такого типа, потому что при этом меняется не так уж много. Сегмент потребителей остается тем же, проблема клиентов — той же, модель монетизации — тоже, и партнерские каналы не меняются. Единственный вопрос заключается в том, является ли новая технология дешевле и/или эффективнее существующей.

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

Компания Toyota обнаружила, что благодаря подходу небольших партий ее заводы стали работать намного эффективнее. Но суть системы «экономичный стартап» заключается не в том, чтобы эффективнее производить больше товаров, а в том, чтобы как можно быстрее выяснить, как создать жизнеспособный бизнес.

Вернемся к примеру, который я уже приводил. Что, если клиенту вдруг оказался не нужен продукт, который мы производим? Эту новость нельзя назвать приятной, но лучше узнать ее раньше, чем позже. Работа небольшими партиями гарантирует, что в такой ситуации стартап может свести к минимуму потери времени, денег и сил.

В IMVU мы тоже применяли методы из сферы производства. Обычно новые версии продуктов, подобных нашему, выпускаются на рынок каждый месяц, каждый квартал или каждый год.

Возьмите свой мобильный телефон. Скорее всего, это не самая первая модель в своей категории. Даже такие новаторские компании, как Apple, каждый год создают новые модели. Обычно в новинке присутствуют десятки новых опций (в версии iPhone 4 было более 1500 изменений).

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

В процессе разработки продукта подход больших партий все еще остается основным. Разработка происходит на чем-то вроде виртуального конвейера. Продукт-менеджеры выясняют, какие опции могут понравиться клиентам. Затем разработчики продукта выясняют, как должны выглядеть эти опции и какие ощущения вызывать у пользователя. На основе получившихся проектов создается новый продукт или модифицируется существующий. И уже он передается тем, кто проверяет, работает ли он именно так, как представляли себе продукт-менеджеры и разработчики. Для таких продуктов, как iPhone, эта внутренняя проверка может проводиться раз в месяц или раз в квартал.

Давайте еще раз вспомним пример с конвертами. Как можно более эффективно решить эту задачу?

В IMVU мы пытались проектировать, разрабатывать и создавать новые опции по очереди, используя все преимущества работы небольшими партиями. Вот как мы это делали.

С самого начала конструкторы и разработчики совместно трудились над каждой из опций. Когда опция была готова к тестированию с участием клиентов, выпускалась новая версия продукта. Она была доступна на нашем сайте относительно небольшому числу пользователей. Видя реакцию клиентов, команда могла быстро оценить результаты своей работы и решить, что делать дальше. Если изменения были незначительными, этот цикл мог повторяться несколько раз в день. В целом каждый день IMVU вводила в продукт в среднем около 50 изменений

Как и в производственной системе Toyota, чтобы действовать с такой скоростью, нужно как можно быстрее замечать дефекты, предотвращая тем самым серьезные проблемы в будущем. Например, у нас был большой набор автоматизированных тестов, которые подтверждали, что после каждого изменения продукт все еще работает так, как нужно. Но что будет, если разработчик случайно удалит важную опцию, например кнопку «Оплатить» на одной из страниц нашего электронного магазина? Без этой кнопки пользователи ничего не смогут у нас купить. И компания тут же превратится из бизнеса в хобби. Подобно андону на заводах Toyota, в IMVU мы использовали тщательно продуманный набор защитных механизмов, которые не позволяли разработчикам случайно удалить что-то важное.

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

Возвращаясь к примеру, когда бизнес превращается в хобби, потому что с сайта пропала кнопка «Оплатить», давайте сделаем его немного более наглядным. Предположим, что разработчик не удалил кнопку, а случайно изменил ее цвет, и на сайте она стала белой на белом фоне. С точки зрения автоматизированных функциональных тестов, кнопка осталась на месте, и все работает как надо. Но пользователь не видит ее и поэтому не может ничего приобрести. Такие проблемы трудно обнаружить только с помощью автоматизированной проверки, но они грозят катастрофическими последствиями. Иммунная система IMVU запрограммирована так, чтобы быстро обнаруживать такие ошибки и автоматически приводить в действие наш аналог андона.

Если наша иммунная система обнаруживает проблему, тут же происходит следующее:

1. Угрожающие изменения автоматически удаляются.

2. Все члены команды, допустившей ошибку, получают уведомление о проблеме.

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

В IMVU мы назвали этот метод непрерывным развертыванием, и даже в очень динамичном мире разработки программного обеспечения он до сих пор считается спорным. Но движение «экономичный стартап» набирает обороты, и этот метод все чаще берут на вооружение. Среди последних примеров — компания Wealthfront, вираж которой был описан в главе 8. Используя непрерывное развертывание, она проводит каждый день более десятка проверок новых опций с участием пользователей.

Когда я рассказываю это людям, работающим в отраслях, где не нужны такие скорости, как в мире высоких технологий, им кажется, что это какая-то научная фантастика. Тем не менее процесс разработки ускоряется в самых разных областях. Это происходит под влиянием следующих тенденций:

1. Аппаратные средства превращаются в программное обеспечение. Давайте вспомним, что произошло в сфере бытовой электроники. Самые современные телефоны и планшеты — это просто экраны, соединенные с Интернетом. Почти вся их ценность заключается в программном обеспечении. Даже ценность продуктов «старой школы», например автомобилей сегодня во многом определяется программным обеспечением, которое есть у них внутри и управляет всем — от музыкального центра до двигателя и тормозной системы. А возможности программного обеспечения можно изменить намного быстрее, чем механические устройства.

2. Быстрое изменение продукта. Благодаря успеху движения бережливого производства сегодня многие конвейеры настроены так, что каждый новый продукт, который с него сходит, может быть полностью индивидуализирован, и при этом не приходится жертвовать качеством или рентабельностью. Раньше такой подход использовался для того, чтобы расширять ассортимент продукции. Но в будущем эта способность позволит разработчикам намного быстрее получать от пользователей обратную связь о новых версиях и моделях. В продукт вносятся изменения, и товарных запасов продуктов старых версий уже нет, поэтому ничто не замедляет процесс выпуска новых. Настройки оборудования можно быстро менять, и как только готовы спецификации новой модели, можно сразу же начинать ее производство.

3. Трехмерная печать и инструменты для быстрого создания опытных образцов. Всего один пример: почти все продукты и детали, сделанные из пластмассы, сегодня производятся с помощью метода массового производства под названием «литьевое прессование». Его внедрение требует много средств и времени, но зато он позволяет штамповать сотни тысяч одинаковых товаров по очень низкой себестоимости. Это классический метод производства большими партиями, и он ставит в невыгодное положение предпринимателей, которые хотят разработать новый товар, ведь обычно только крупные компании могут позволить себе столь масштабное производство. Однако новые технологии позволяют предпринимателям создавать небольшие партии товаров того же качества, что и те, которые изготовлены с помощью литьевого прессования, однако с гораздо меньшими затратами и гораздо быстрее.

Самый важный вывод заключается не в том, что любой компании нужно создавать новые версии продукта по 50 раз на дню, но в том, что, уменьшая размеры партий, можно пройти цикл обратной связи «создать — оценить — научиться» быстрее конкурентов. Способность быстрее учиться у клиентов — важнейшее конкурентное преимущество, необходимое любому стартапу.

Давайте посмотрим, как это происходит на практике. Позвольте мне познакомить вас с компанией SGW Designworks из города Бойсе, штат Айдахо. Специализация SGW — методы быстрого производства товаров. Многие ее клиенты — стартапы.

SGW Designworks получила запрос от одного клиента. У него был заказ от корпорации, сотрудничающей с армией США. Нужно было разработать сложное рентгеновское оборудование, позволяющее в полевых условиях, при переходе границы и в районах боевых действий, обнаруживать взрывчатые вещества и другие опасные устройства.

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

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

Когда проект разработки был согласован, всего через три дня команда SGW представила клиенту первые опытные образцы. Они были изготовлены из алюминия в точном соответствии с трехмерной моделью, и образец был собран вручную сотрудниками SGW.

Клиент сразу же отправил опытные образцы заказчику. С некоторыми незначительными модификациями общая концепция была принята. В следующие пять дней прошел еще один полный цикл и был создан еще один опытный образец, а также завершен общий анализ проекта при участии клиента и SGW. Первая промышленная партия из 40 единиц была готова через три с половиной недели после начала разработки (см. табл. 9).

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

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

Представьте себе, что вы — учитель математики в средней школе. Можно преподавать теорию небольшими партиями, постепенно, но общая программа обучения меняется не так уж часто. Вы разрабатываете программу заранее и преподаете один и тот же материал в одном и том же порядке каждому ученику в классе. Изменения в программу можно вносить не чаще, чем один раз в год.

Как учитель математики может экспериментировать с «небольшими партиями»? В рамках нынешней системы школьного образования, основанной на подходе больших партий, это невозможно. Современная система образования была разработана в эру массового производства и поэтому основана на подходе больших партий.

Но есть смельчаки, которые решили изменить ситуацию. Например, в экспериментальной школе School of One у каждого ученика есть ежедневный «репертуар» учебных задач, подобранный с учетом его индивидуальных потребностей, подготовки и стиля обучения. Скажем, Джулия опережает программу по математике этого учебного года и лучше всего занимается в небольшой группе. Поэтому в ее «репертуаре» может быть три или четыре видеофильма, соответствующих ее уровню способностей, 30-минутный индивидуальный урок с учителем и работа в небольшой группе, где ей нужно решить математическую задачу вместе с тремя другими учениками такого же уровня подготовки. Готовую работу можно сдать учителю, и он выберет соответствующие задачи для следующего «репертуара».

Такой подход может применяться в классе, во всей школе и даже в целом районе.

Представьте себе, как можно экспериментировать со школьной программой в такой школе, как School of One. Каждый ученик работает в собственном темпе. Скажем, вы — учитель и хотите предложить новую учебную программу по математике. Вы сможете очень быстро оценить ее эффективность для тех ваших учеников, которые сейчас изучают темы программы, с которыми вы экспериментируете. Если вы увидите, что новая программа лучше, то сможете сразу же ввести ее для всех: приступая к новым темам, каждый отдельный ученик автоматически будет изучать их по-новому. Иначе говоря, такие инструменты, как School of One, позволяют учителям использовать подход небольших партий, и это очень эффективно для учеников. (А если такие инструменты получат широкое распространение, успешные эксперименты отдельных учителей можно будет внедрить в масштабах района, города или даже всей страны.) Такой подход приобретает популярность и получает все больше признания. Журнал Time недавно включил школу School of One в список «наиболее новаторских проектов». Она оказалась единственной организацией из сферы образования в этом списке.

Представьте, что вы ехали на машине, думали обо всех достоинствах подхода небольших партий и вдруг случайно помяли бампер своей новенькой голубой Toyota Camry 2011 г. Вы едете в автосервис и уже готовитесь к худшему. Автомеханик говорит, что бампер нужно менять. На складе есть новый бампер, и вашу машину могут отремонтировать немедленно. При этом все довольны. Вы довольны, потому что скоро снова сможете ездить на своей машине, сотрудники автосервиса тоже довольны, потому что в следующий раз, случись что, вы наверняка приедете именно к ним. Кроме того, работникам сервиса не придется держать вашу машину на своей стоянке или давать вам другую напрокат, пока не появятся нужные запчасти.

В традиционном массовом производстве, чтобы избежать дефицита запасных частей — когда на складе нет того, что нужно клиенту, — всегда есть большой запас, просто на всякий случай. Может оказаться, что бампер для голубой Camry 2011 г. пользуется большим спросом. Но как насчет прошлогодней модели или модели, выпущенной пять лет назад? Чем больше на складе запчастей, тем выше вероятность того, что у вас найдется нужная деталь для каждого клиента. Но держать на складе большие товарные запасы накладно, ведь их нужно транспортировать, хранить и учитывать. Что, если в процессе производства у всей партии бамперов модели 2011 г. появились дефекты? Тогда все эти бамперы на всех складах тут же станут ненужными.

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

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

Когда компания берет на вооружение такой подход, ей становятся не нужны гигантские склады, ведь количество товарных запасов, хранящихся просто «на всякий случай», резко сокращается.

Стартапам труднее добиться такого результата. Если на заводе есть избыточные запасы «на всякий случай», они начинают накапливаться в цехах. А в стартапах они почти не видны. Например, все, что нужно для разработки минимально рабочего продукта — до того момента, когда он будет выпущен на рынок, — это как раз запасы «на всякий случай». К ним можно отнести и незаконченную разработку, и еще не проверенные предположения, и почти все бизнес-планы. Однако выход есть. Почти все методы «экономичного стартапа», которые мы до сих пор обсуждали, действуют следующим образом: они останавливают попытки «проталкивать» большие партии изделий по цепи поставок и позволяют получать их «по запросу» — вовремя и небольшими партиями. В итоге и то и другое сокращает запасы «на всякий случай».

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

Но, как мы уже говорили, система «экономичный стартап» работает иначе, ведь клиенты далеко не всегда знают, чего хотят. Наша цель при создании продукта — приступить к экспериментам, которые помогут нам выяснить, как создать жизнеспособный бизнес. Соответственно, правильное отношение к процессу разработки продукта в системе «экономичный стартап» заключается в том, что она реагирует на запросы клиентов, собирая информацию о том, какие эксперименты нужно провести.

Как только мы сформулируем, что именно мы хотим проверить, можно создавать команду, которая должна будет максимально быстро разработать и провести эксперимент, используя при этом минимальные партии. Наш цикл обратной связи называется «создать — оценить — научиться», потому что действия происходят именно в этой последовательности. Однако планирование происходит в обратном порядке: мы выясняем, чему нам нужно научиться, что нужно выяснить, а затем движемся назад, чтобы понять, какой продукт позволит провести эксперимент, который поможет нам в этом. Таким образом, не клиент, а скорее наша гипотеза о клиенте, является «запросом» для разработчиков продукта и других команд. Все остальные действия попросту не нужны.

Чтобы увидеть, как это происходит на практике, давайте познакомимся с компанией Alphabet Energy. Это стартап из Беркли, разрабатывающий технологии экономии энергии. Все, что производит энергию, будь то двигатель или электростанция, работающая на угольном топливе, в качестве побочного продукта вырабатывает тепло. Компания Alphabet разработала технологию, позволяющую производить электроэнергию из этих «тепловых отходов». Для этого используется новый материал, который называется термоэлектрик. Его больше 10 лет разрабатывали ученые Национальной лаборатории им. Лоуренса в Беркли.

Подобно многим другим разработкам в сфере чистых технологий, такой продукт очень сложно вывести на рынок. Следуя своим «прыжкам веры», инженеры Alphabet быстро выяснили, что для производства термоэлектричества нужно создать теплообменник и общее устройство для передачи тепла из одной среды в другую.

Компания Alphabet Energy уникальна тем, что еще в самом начале процесса исследований она приняла разумное решение. Она не стала применять в качестве материалов относительно редкие элементы и решила использовать кремниевые пластины — тот же самый материал, из которого сделаны центральные процессоры компьютеров. Генеральный директор компании Мэтью Скаллин говорит: «Для нашего термоэлектрика можно использовать низкозатратную инфраструктуру производства полупроводников». Это позволило Alphabet Energy разрабатывать и создавать свои продукты небольшими партиями.

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

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

Кажется, что самый перспективный рынок для технологии Alphabet — это электростанции. Такой и была первоначальная гипотеза команды. Инженеры Alphabet предположили, что простым и дешевым решением будет присоединить термоэлектрические полупроводники к газовым турбинам. Эти турбины, похожие на стоящие на земле реактивные двигатели, используются для производства дополнительной энергии в периоды максимального спроса.

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

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

Все эти эксперименты обошлись компании гораздо дешевле, чем тратят на разработку новых технологий другие стартапы в энергетической сфере. Сегодня Alphabet привлекла около $1 млн инвестиций. Время покажет, удастся ли ей добиться успеха, но благодаря подходу небольших партий она очень быстро узнает об этом.

Возможно, производственная система Toyota — самая совершенная система менеджмента в мире, но еще больше впечатляет то, что Toyota создала самую совершенную обучающуюся организацию в истории. Она способна раскрывать творческий потенциал своих сотрудников, она постоянно развивается и уже почти 100 лет непрерывно создает инновационные продукты.

Именно к такому долгосрочному успеху нужно стремиться предпринимателям. Методы бережливого производства весьма действенны, но они — не все, что нужно эффективной организации, которая стремится достичь максимальной продуктивности, используя адекватные показатели успеха в долгосрочной перспективе. Процесс — только основа, на которой может возникнуть культура великой компании. Однако без этой основы невозможно учиться, раскрывать творческий потенциал сотрудников и создавать инновации — это подтвердит любой опытный директор по управлению персоналом (см. рис. 9).

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

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

Механизмы роста нужны для того, чтобы дать стартапу относительно небольшой набор показателей, на которых можно сосредоточиться. Как говорит один из моих наставников, инвестор венчурного капитала Шон Кэролан, «стартапы не умирают медленно от голода — они быстро тонут». Всегда есть множество новых идей о том, как сделать продукт лучше, но суровая правда заключается в том, что большинство из них мало что могут изменить. Чаще всего эти идеи касаются незначительной оптимизации. А стартапу нужно сосредоточиться на серьезных экспериментах, которые позволят получить подтверждение фактами. Тот или иной механизм роста помогает сосредоточиться на тех показателях, которые действительно важны.

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

Стартап, продающий базы данных, рассчитывает на повторное использование по совсем другим причинам. Его технология баз данных — только основание для создания собственных продуктов клиентов, например для разработки веб-сайтов или систем обслуживания торговых точек. Но если вы создаете продукт на основании определенной технологии баз данных, то поменять технологию становится очень трудно. В ИТ-отрасли считается, что такие клиенты становятся «заложниками» своих поставщиков. Чтобы такой «рискованный» продукт стал популярным, он должен предлагать поистине потрясающие опции — только это может побудить клиентов заключить долгосрочный контракт.

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

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

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

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

После нашей встречи основатели одного из этих двух стартапов последовали моему совету и смоделировали поведение потребителей, взяв за основу механизм «липкого» роста. Результаты оказались неожиданными: уровень удержания в 61 % и рост числа новых клиентов в 39 %. Иначе говоря, коэффициент потери и темпы привлечения новых потребителей почти идеально уравновешивали друг друга. При этом общие темпы роста составляли всего 0,02 % — почти ноль.

Такие показатели типичны для компаний, которые работают на рынках, требующих вовлечения потребителей. На таких рынках сложно добиться роста. Один инсайдер, работавший в компании PointCast в эру доткомов, рассказывал мне, что эта компания столкнулась с такой же проблемой. PointCast почти не росла, но тем не менее она невероятно успешно привлекала новых пользователей — точно так же, как стартап, о котором идет речь (39 % в каждый период). К сожалению, этот рост сводился на нет почти таким же уровнем потерь. Как только вы видите эту модель, становится ясно: все прекрасно, в вашу дверь стучит множество новых клиентов. Значит, чтобы добиться роста, нужно сосредоточиться на существующих потребителях и сделать продукт еще более привлекательным для них. Например, компания может создавать более полные каталоги. Это стимулирует клиентов чаще их просматривать. Или можно сделать что-нибудь попроще, например регулярно отправлять пользователям сообщения о специальных предложениях и временных скидках. Так или иначе, нужно думать о том, как повысить коэффициент удержания клиентов. Это противоречит традиционному представлению о том, что, если компании трудно добиться роста, ей нужно вкладывать больше денег в стимулирование продаж и маркетинг. Но если ориентироваться не на «показатели тщеславия», то вы сумеете прийти к правильным выводам.

Социальные сети и изделия Tupperware — примеры продуктов, где львиную долю маркетинга берут на себя клиенты. Информация о продукте быстро распространяется от человека к человеку, точно так же, как вирус во время эпидемии. Это не просто рост с помощью «сарафанного радио». При вирусном росте продукты «передаются» от человека к человеку, это естественное следствие использования продукта. Клиенты не рассказывают о нем друзьям и знакомым. Рост происходит автоматически, как побочный эффект использования продукта, ведь вирус поражает всех, кого встречает на своем пути.

Например, одна из самых известных историй успеха, связанных с «вирусным» ростом, — компания под названием Hotmail. В 1996 г. Сабир Бхатия и Джек Смит запустили новый сервис электронной почты, где пользователи могли создать бесплатный аккаунт. Сначала рост был вялым: при небольших начальных инвестициях от венчурной компании Draper Fisher Jurvetson команда Hotmail не могла позволить себе обширной маркетинговой кампании. Но все изменилось, как только команда ввела несколько небольших изменений. В конце каждого электронного письма, отправленного с адреса, зарегистрированного на Hotmail, теперь вместе со ссылкой для регистрации появлялось сообщение: «P. S. Заведите бесплатную электронную почту на Hotmail».

Всего через несколько недель это небольшое изменение дало потрясающие результаты. Если за полгода Бхатия и Смит привлекли около миллиона новых клиентов, то спустя пять недель количество пользователей перевалило за два миллиона. Через полтора года после создания сервиса у компании было 12 млн клиентов, и ее за $400 млн купила корпорация Microsoft[17].

Тот же феномен мы наблюдаем на знаменитых «домашних вечеринках» Tupperware, когда клиенты получают комиссионные, продавая изделия компании друзьям и соседям. Каждый раз это возможность не только продать товар, но и убедить других клиентов стать представителями компании. Вечеринки Tupperware популярны до сих пор — спустя десятилетия после того, как они возникли. Подобную модель успешно используют многие другие современные компании, например Pampered Chef (принадлежащая корпорации Berkshire Hathaway Уоррена Баффетта), Southern Living и Tastefully Simple.

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

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

И наоборот, если вирусный коэффициент выше единицы, рост будет идти по экспоненте, потому что каждый новый клиент приведет за собой в среднем больше одного человека. Эти эффекты изображены на графике (см. рис. 10).

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

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

Истинная проверка гипотезы ценности — всегда добровольный обмен ценностью между клиентами и стартапом, который их обслуживает. Важно понять, что этот обмен может быть как денежным, как в случае с Tupperware, так и не денежным, как в случае с Facebook. При вирусном механизме роста денежный обмен не приводит к росту, он полезен только как индикатор: клиенты достаточно ценят продукт, чтобы заплатить за него. Если бы в первые годы своего существования Facebook или Hotmail начали брать с клиентов деньги, это было бы глупо, поскольку не позволило бы им расти. Но это не значит, что клиенты не приносят этим компаниям ничего ценного: уделяя продукту свое время и внимание, они повышают его ценность для рекламодателей. Компании, продающие рекламу, на самом деле обслуживают две разные группы клиентов — потребителей и рекламодателей — и обмениваются с каждой из них разной «валютой»[18].

Такая стратегия заметно отличается от стратегий тех компаний, которые активно используют для ускорения своего роста деньги. Например, розничная сеть растет с той скоростью, с какой она способна финансировать открытие новых магазинов в подходящих местах. Такие компании используют совершенно другой механизм роста.

Представьте себе две другие компании. Первая зарабатывает на каждом новом клиенте $1, а вторая — $100 000. Чтобы выяснить, какая из них будет расти быстрее, нужно знать только одно: сколько она тратит на привлечение нового клиента.

Предположим, первая компания использует Google AdWords, чтобы находить новых клиентов онлайн, и платит за каждого в среднем 80 центов. Вторая компания продает сложный продукт крупным заказчикам. Каждая продажа требует от продавца существенных затрат времени и индивидуального инжиниринга, связанного с инсталляцией продукта. В целом это выливается в сумму до $80 000 на каждого нового клиента. Это значит, что обе компании растут с одинаковой скоростью. Каждая из них может одну и ту же часть дохода (20 %) повторно вложить в привлечение новых клиентов. И если какая-то из двух компаний хочет нарастить темпы роста, она может выбрать для этого один из двух способов: повысить доходность каждого существующего клиента или снизить стоимость приобретения каждого нового клиента.

Это и есть механизм оплаченного роста.

В истории IMVU, описанной в третьей главе, я говорил о том, что сначала наша стратегия была совершенно неверной. В итоге нам пришлось совершить вираж механизма роста. Сначала мы думали, что наша стратегия — создать дополнение к IM-сетям — приведет к вирусному росту. К сожалению, клиенты не оценили нашу блестящую идею.

Мы ошиблись, решив, что они станут использовать IMVU как дополнение к уже существующим на рынке IM-сетям. Мы думали, что продукт будет распространяться вирусным путем, через эти сети, от клиента к клиенту. Но некоторые виды продуктов не совместимы с вирусным ростом.

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

Как и другие механизмы, механизм оплаченного роста действует на основании цикла обратной связи. У каждого пользователя есть свой жизненный цикл — тот период, в течение которого он будет пользоваться сервисом. За это время он заплатит сервису определенное количество денег. Эту сумму за вычетом переменных издержек называют ценностью жизненного цикла потребителя. Ее можно инвестировать в рост, покупая рекламу.

Предположим, реклама стоит $100 и побуждает подписаться на сервис 50 новых клиентов. Стоимость привлечения одного клиента при этом составляет $2. Если затраты на привлечение клиента будут ниже его ценности, т. е. последняя составляет больше $2, то механизм оплаченного роста будет работать. Если наоборот — рост компании замедлится. В таком случае можно проводить какие-то одноразовые акции, например использовать для рекламы инвестированный капитал, но такая тактика нежизнеспособна. В этом на собственном горьком опыте убедились многие компании, в том числе и знаменитые доткомы.

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

Например, однажды я работал со стартапом, создававшим средства для совместной работы в командах и группах. Этот стартап как раз совершил радикальный вираж и перешел от разработки инструментов, предназначенных в основном для небольших клубов и людей, увлеченных каким-нибудь хобби, к средствам, ориентированным на предприятия, неправительственные организации и другие крупные компании. Однако, совершив такой вираж сегмента потребителей, он не изменил механизм роста. До этого он привлекал клиентов онлайн с помощью методов прямого маркетинга в Интернете. Я помню ситуацию в самом начале работы этого стартапа, когда позвонила крупная неправительственная организация, которая хотела купить его продукт и внедрить его в нескольких своих подразделениях. Самый дорогой «безлимитный» ценовой план стартапа стоил всего несколько сотен долларов в месяц.

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

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

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

IMVU — показательный пример. Другие онлайн-сервисы не считали наших клиентов слишком прибыльными: среди них было много подростков, взрослых с низкими доходами и людей из других стран. Обычно считается, что такие люди ни за что не станут оплачивать онлайн-сервис. Но мы создали методы, позволяющие производить онлайн-расчеты с клиентами, у которых нет кредитной карты, например списывать деньги с их мобильных телефонов или принимать денежные переводы по почте. Поэтому мы могли позволить себе платить за привлечение таких клиентов больше, чем наши конкуренты.

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

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

Нужно ли стартапу вкладывать средства в программу обучения новых сотрудников? Если бы вы задали мне этот вопрос несколько лет назад, я посмеялся бы и сказал: «Конечно, нет. Программы обучения — для крупных компаний, которые могут себе это позволить». Тем не менее мы в IMVU в итоге создали программу обучения, и она оказалась так хороша, что новые сотрудники полностью вливались в рабочий процесс уже в первый день работы. Всего несколько недель спустя они работали наравне с «ветеранами». Нам пришлось приложить массу усилий, чтобы стандартизировать рабочие процессы и подготовить программу, которую должны были изучить новые сотрудники. У каждого нового разработчика был наставник, помогавший новичку освоить программу, ознакомиться с системами, понятиями и методами, необходимыми для эффективной работы в IMVU. Результаты работы наставника и его ученика были взаимосвязаны, и поэтому наставники серьезно относились к обучению новичков.

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

Я называю это созданием адаптивной организации, которая автоматически корректирует свои процессы и действия в соответствии с текущими условиями.

До сих пор мы говорили о том, как важна скорость. Стартап бьется не на жизнь, а насмерть, чтобы выяснить, как создать жизнеспособный бизнес, ведь если он не сделает это до тех пор, как у него закончатся ресурсы, то умрет. Но нужно думать не только о скорости. Чтобы эффективно действовать, стартапу необходимы встроенные регуляторы скорости, помогающие находить оптимальный темп движения.

Мы видели пример регулирования скорости в главе 9, когда говорили о том, как можно использовать идею андона в таких системах, как непрерывное развертывание. Эта концепция прекрасно выражена в парадоксе, возникшем в компании Toyota: «Вовремя останавливайте производство, чтобы производство никогда не останавливалось». Смысл андона в том, что он позволяет остановить работу, если возникает серьезная проблема с качеством — и вынуждает устранить ее. Это одно из самых важных открытий системы бережливого производства: нельзя жертвовать качеством ради скорости. Если сегодня возникают проблемы с качеством (или вы их не замечаете), позже они начнут мешать вам расти. Брак приводит к лишней работе, деморализует людей, заставляют клиентов жаловаться, и все это замедляет развитие компании и истощает ценные ресурсы.

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

Очень скоро правила становятся невероятно запутанными, и сотрудникам приходится тратить массу времени и сил на то, чтобы выучить их. Теперь представьте себе, что в такой компании менеджер-предприниматель пытается экспериментировать с новыми правилами или процедурами. Чем более качественны новые правила, тем легче их будет совершенствовать со временем. И наоборот, неясные правила полны противоречивых и неоднозначных пунктов, и если произойдет что-то неожиданное, возникнет хаос.

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

Поэтому, если сегодня мы упустим что-то важное — в сфере качества продукта, разработки или инфраструктуры, — завтра это может помешать нам расти. Можно увидеть, как этот парадокс проявился в IMVU. В главе 3 я уже рассказывал о том, что мы вывели на рынок продукт, который имел минимум опций и был полон багов. Но никто даже не попробовал воспользоваться этим продуктом, и поэтому почти вся наша работа оказалась ненужной. Хорошо, что мы не потратили слишком много времени на то, чтобы «улучшить» ту первую версию продукта.

Новые знания позволяли нам создавать продукты, нужные пользователям, но в какой-то момент рост стал замедляться. Продукт невысокого качества может препятствовать обучению, если его дефекты не позволяют клиентам понять, каковы его преимущества, и дать нам обратную связь. В случае с IMVU, когда мы стали предлагать продукт клиентам основного рынка, они оказались куда менее снисходительными, чем ранние последователи. А чем больше опций мы добавляли, тем сложнее становилось добавлять новые, потому что возрастал риск того, что новая опция вступит в конфликт с уже существующими. Такая же динамика существует в сфере услуг, так как любые новые правила могут войти в конфликт с уже существующими, и чем больше правил, тем чаще они начинают противоречить друг другу.

Компания IMVU использовала методы, описанные в этой главе, чтобы расти и поддерживать качество в соответствии с подходом «точно вовремя».

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

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

Альтернатива в том, чтобы использовать метод под названием «Пять “Почему?”». Он позволит создавать программу обучения постепенно и шаг за шагом развивать процессы стартапа. Главная идея «Пяти “Почему?”» заключается в том, чтобы напрямую связать инвестиции с предотвращением самых болезненных симптомов. Название этого метода напоминает о приемах ведения расследований в полиции, когда детектив пять раз задает вопрос «Почему?», чтобы понять, что произошло (какова причина). Если вам доводилось отвечать на вопросы ребенка, который хотел знать, почему небо голубое, и продолжал спрашивать «Почему?» после каждого ответа, то вы с ним знакомы. Этот метод как системный инструмент решения проблем разработал Тайити Оно, создатель производственной системы Toyota. Я адаптировал его для системы «экономичный стартап» и внес несколько изменений, специально для стартапов.

1. Почему станок остановился? (Возникла перегрузка, и предохранитель вышел из строя.)

2. Почему возникла перегрузка? (Был плохо смазан вкладыш.)

3. Почему он был плохо смазан? (В смазочном насосе был недостаточный напор.)

4. Почему в насосе был недостаточный напор? (Шахта насоса изношена.)

5. Почему шахта изношена? (В ней нет сита, куда бы направлялись металлические отходы.)

Обратите внимание: даже в таком простом примере видно, что основная причина — не в технической неполадке (вышел из строя предохранитель), а в ошибке, допущенной человеком (кто-то забыл присоединить сито к насосу). Это весьма типично для большинства проблем, с которыми сталкиваются стартапы, в какой бы сфере они ни работали. При этом в сфере обслуживания почти все проблемы, которые, на первый взгляд, кажутся промахами отдельных людей, можно объяснить проблемами в обучении или противоречивым набором правил компании.

Я хочу показать, как метод «Пяти “Почему?”» помог нам создать систему обучения сотрудников, о которой мы говорили выше. Представьте себе, что IMVU внезапно начала получать от клиентов жалобы на новую версию продукта, которую мы только что выпустили.

1. В новой версии оказалась отключена одна из опций. Почему? Потому что возникли неполадки на одном из серверов.

2. Почему возникли неполадки на сервере? Потому что какая-то из подсистем использовалась неправильно.

3. Почему она использовалась неправильно? Работавший с ней разработчик не знал, как это нужно делать.

4. Почему он этого не знал? Потому что его не обучили.

5. Почему его не обучили? Его руководитель не считает нужным обучать новых сотрудников, потому что он сам и члены его команды «очень заняты».

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

Как метод «Пяти “Почему?”» помогает создать адаптивную организацию? Нужно постоянно делать соразмерные инвестиции на каждом из пяти уровней. То есть нужно прикладывать меньше усилий, если симптом незначителен, и больше, если он более серьезен. Иначе говоря, мы не делаем значительных инвестиций в профилактику до тех пор, пока не справились с более серьезными проблемами.

В приведенном выше примере, чтобы устранить проблему, нужно устранить неполадки на сервере, изменить подсистему так, чтобы она была менее подвержена ошибкам, обучить нового сотрудника и, конечно же, провести беседу с его руководителем.

Эта последняя задача, разговор с руководителем, всегда трудна, а особенно в условиях стартапа. Когда я был руководителем в стартапе, если бы мне сказали, что должен заняться обучением своих людей, я ответил бы, что не стану заниматься ерундой. У меня всегда было слишком много других задач. Вероятно, я сказал бы какую-нибудь колкость, например: «Конечно, я буду счастлив это сделать! Если вы предоставите мне пару месяцев свободного времени, я обязательно этим займусь». Иначе говоря: «Ни за что на свете!»

Вот почему соразмерные инвестиции так важны. Если электричество отключилось просто в результате небольшого сбоя, достаточно потратить час времени на то, чтобы устранить его. Если проблема возникнет снова, следуя методу «Пяти “Почему?”», мы сможем выяснить ее причины. А если она больше не возникнет, час времени, потраченный на ее решение, — не слишком большая потеря.

Я не случайно привел в пример обучение новых сотрудников. Ведь я отказывался уделять ему внимание в IMVU. Когда мы только создали наш стартап, я искренне полагал, что нам нужно сосредоточиться исключительно на создании и маркетинге продукта. Но когда нам пришлось в короткий срок принять на работу много новых сотрудников, метод «Пяти “Почему?”» раз за разом стал показывать, что проблемы, связанные с отсутствием обучения, замедляют разработку продукта. Конечно, мы не стали бросать все остальное, чтобы заняться обучением новых людей. Но мы постоянно и последовательно совершенствовали программу обучения, и каждый раз она становилась немного лучше. Со временем положительные изменения накапливались, высвобождая время и силы, которые раньше мы тратили на авралы и кризис-менеджмент.

Метод «Пяти “Почему?”» может стать естественным регулятором скорости. Чем больше проблем, тем больше времени и сил уходит на их решение. Когда инвестиции в инфраструктуру или процесс начинают давать результаты, кризисы случаются все реже, они все менее серьезны, и команда снова набирает скорость. Стартапы особенно подвержены опасности того, что их команды начнут работать слишком быстро, жертвуя качеством ради времени, и это будет приводить к небрежности и ошибкам. Метод «Пяти “Почему?”» препятствует этому, позволяя команде найти оптимальный темп.

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

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

Когда команды начинают использовать метод «Пяти “Почему?”» для решения своих проблем, у них часто возникают одни и те же трудности. Обычно мы склонны слишком сильно реагировать на то, что происходит с нами в данный момент. И при этом очень расстраиваться, если вдруг происходит то, чего мы не ожидали.

Когда «Пять “Почему?”» используют не по назначению, я называю это «Пять обвинений». Вместо того чтобы вновь и вновь спрашивать «почему» и выяснять, что пошло не так, расстроенные члены команды начинают тыкать друг в друга пальцами в поисках виноватых. Вместо того чтобы использовать «Пять “Почему?”» для выявления и решения проблем, менеджеры и сотрудники иногда попадают в ловушку и начинают играть в «Пять обвинений» — это помогает им как-то выразить свои негативные чувства. Но такие поиски виноватых не дают увидеть недостатки системы. Мы все склонны считать, что ошибка — это следствие плохой работы какого-то другого отдела, невежества или дурного характера других людей. Но метод «Пяти “Почему?”» предназначен для того, чтобы помочь нам увидеть объективную истину. А она обычно состоит в том, что если проблема повторяется — это следствие неэффективных процессов, а не действий отдельных людей. Если мы поймем это, у нас появится шанс создать более адекватные процессы.

Чтобы не погрязнуть в «Пяти обвинениях», я предлагаю несколько тактик. Во-первых, на встрече, посвященной «Пяти “Почему?”» должны присутствовать все, кого касается проблема. На ней должны быть все те, кто обнаружил или диагностировал проблему, в том числе, если это возможно, сотрудники, обслуживающие клиентов. На ней должны быть все, кто пытался устранить симптом, а также все, кто работал с подсистемами или опциями, связанными с проблемой. Если проблема дошла до уровня высшего руководства, то руководители, которые не решили проблему вовремя, тоже должны прийти на встречу.

В результате на встрече может быть очень много людей, но это не страшно. По моему опыту, если кто-то не будет участвовать в обсуждении, в итоге именно он станет мишенью для обвинений. Козлом отпущения здесь может оказаться любой — и сотрудник низшего уровня, и генеральный директор. Если это простой сотрудник, может показаться, что его легко заменить. Если на встрече не присутствует генеральный директор, все начнут думать, что на его действия повлиять невозможно. Но ни то, ни другое обычно не соответствует действительности.

Обвинения начнутся неизбежно. Но тем из присутствующих на встрече, кто имеет самый высокий статус, нужно выучить и повторять следующую мантру: «Если возникает ошибка, стыд нам и позор за то, что мы ее допустили! Но анализ пяти “Почему?” позволит нам взглянуть на проблему системно».

Вот пример ситуации, в которой эта мантра оказалась очень полезной. В процессе обучения новых сотрудников, который мы создали в IMVU с помощью метода «Пяти “Почему?”», мы просили их в самый первый рабочий день ввести какое-нибудь изменение в продукт. Программистов, обученных традиционным методам разработки, это пугало. Они спрашивали: «Что со мной будет, если я случайно прерву или остановлю процесс?» В компании, где они работали раньше, это считалось серьезной ошибкой, из-за нее могли уволить. Но мы говорили новичку: «Если наш производственный процесс такой хрупкий, что вы сможете нарушить его в первый же день работы, стыд нам и позор, что мы позволили вам это сделать». Если новичку действительно удавалось что-нибудь нарушить, мы немедленно поручали ему устранить проблему, а также придумать, как сделать так, чтобы следующему новичку не удалось повторить его ошибку.

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

Вот несколько подсказок на тему, как начать использовать метод «Пяти “Почему?”». Они основаны на моем личном опыте, ведь я помогал вводить этот метод во многих компаниях.

Чтобы «Пять “Почему?”» работали как следует, нужно соблюдать определенные правила. Например, он требует атмосферы взаимного доверия и ответственности. Если ее нет, использовать его будет довольно сложно. В таких ситуациях я предлагаю упрощенную версию, позволяющую командам анализировать причины проблемы и в то же время учиться применять этот подход — на будущее, когда появится возможность использовать его.

Я прошу всех следовать двум простым правилам:

1. Будьте терпимы к ошибкам, которые возникли впервые.

2. Не позволяйте, чтобы одна и та же ошибка повторялась дважды.

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

Такая упрощенная система довольно эффективна. Фактически мы использовали ее в IMVU в те дни, когда я еще не нашел метод «Пяти “Почему?”» и ничего не знал о производственной системе Toyota. Но упрощенная версия метода со временем теряет эффективность, и я убедился в этом на собственном опыте. Честно говоря, поэтому и заинтересовался методологией бережливого производства.

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

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

Часто сотрудники стартапов приходят на мои семинары, чтобы научиться использовать метод «Пяти “Почему?”». Но я не рекомендую им это делать, если у них нет поддержки менеджера или руководителя группы. В такой ситуации нужно действовать осторожно. Возможно, вам не удастся собрать всю команду для настоящего исследования в стиле пяти «Почему?», но в своей собственной работе вы всегда можете использовать более простую версию этого подхода, состоящую из двух правил. Всякий раз, когда что-то идет не так, спросите себя: что я могу сделать, чтобы в следующий раз не оказаться в такой ситуации?

Я рекомендую начать с нескольких четко определенных симптомов. Например, я впервые успешно использовал метод «Пять “Почему?”» для анализа причин проблемы, касавшейся одного нашего внутреннего инструмента тестирования, который не оказывал непосредственного влияния на пользователей. Конечно, заманчиво начать с чего-то большого и важного, ведь именно на большие и важные вещи команда тратит впустую больше всего времени. Но когда на кону стоит многое, «Пять “Почему?”» могут быстро превратиться в «Пять обвинений». Чтобы научить команду использовать этот метод, лучше начать с не слишком важных проблем и только потом применять его там, где ставки высоки.

Чем конкретнее симптомы, тем легче понять, когда нужно назначить встречу, посвященную «Пяти “Почему?”». Скажем, вы хотите использовать «Пять “Почему?”», чтобы понять причины жалоб клиентов. В этом случае, назначьте дату, после которой все жалобы станут автоматическим сигналом о том, что пора провести встречу. При этом объем жалоб не должен быть слишком большим. Это позволит проводить встречи «Пяти “Почему?”» каждый раз, когда это потребуется. Если жалоб слишком много, выберите отдельный класс жалоб, на котором можно сосредоточиться. Правила, которые определяют, какие виды жалоб будут сигналом о том, что пора провести встречу «Пяти “Почему?”», должны быть простыми и неизменными. Например, можно рассматривать все жалобы, связанные с оплатой кредитными карточками. Это несложное и понятное правило. Не выбирайте правила, которые можно трактовать по-разному.

Сначала может возникнуть соблазн ввести радикальные изменения сразу во всех системах расчетов и во всех процессах. Не делайте этого. Лучше проводите короткие встречи и выбирайте относительно простые изменения для каждого из пяти «почему». Со временем, когда команда начнет лучше понимать метод «Пять “Почему?”», изменения могут становиться более серьезными, можно включать все больше типов жалоб, а затем перейти к другим проблемам.

Чтобы ускорить процесс обучения, назначьте специалиста по «Пяти “Почему?”» для каждой сферы, в которой используется этот метод. Этот человек будет модератором на каждой встрече, посвященной принятию решений о том, какие профилактические меры нужно принять, и будет давать задания ее участникам. Специалист по «Пяти “Почему?”» должен занимать высокую должность, чтобы иметь достаточно полномочий и гарантировать, что задачи будут выполнены, но при этом у него должно быть время для того, чтобы присутствовать на встречах. Специалист по «Пяти “Почему?”» — главный человек с точки зрения ответственности, он — основной проводник изменений. Он может оценить, успешно ли проходит встреча и эффективны ли действия компании, направленные на устранение обнаруженной проблемы.

IGN Entertainment, подразделение корпорации News Corporation, разрабатывает онлайн-видеоигры. У ее игр самая многочисленная аудитория геймеров в мире: она составляет больше 45 млн человек. Компания IGN была основана в конце 1990-х гг., а в 2005 г. ее купила News Corporation. На сегодняшний день в ней работает несколько сот человек.

Недавно у меня была возможность пообщаться с командой разработчиков IGN. В последние годы компания работала вполне успешно, но, как и все крупные компании, с которыми мы встречались в этой книге, хотела ускорить процесс разработки новых продуктов и активизировать инновации. Она объединила команды разработки, продукта и дизайна, чтобы обсудить способы использования системы «экономичный стартап».

Эту инициативу поддерживали руководители IGN, в том числе генеральный директор и глава подразделения разработки продукта. Прежние попытки использовать в компании метод «Пяти “Почему?”» не принесли особых результатов. Проблемы, которые нужно было решить, были самыми разными — от несоответствий в веб-аналитике до неэффективных партнерских баз данных. Первая встреча, посвященная анализу «Пяти “Почему?”», длилась около часа. На ней возникло несколько интересных идей, но в целом ее нельзя было назвать удачной. Никто из тех, кто был связан с проблемами и больше всего знал о них, на ней не присутствовал. Раньше компания никогда не проводила таких встреч, поэтому участники не придерживались формата и постоянно отклонялись от темы. Это нельзя было назвать пустой тратой времени, но не дало того эффекта, которым так ценен этот метод.

Компания IGN уже пыталась решить все эти проблемы. И это не удавалось ей в течение многих лет. Такие хронические проблемы носят эндемический характер и поэтому естественным образом выходят на поверхность во время анализа пяти «Почему?». Эту возможность можно использовать для того, чтобы начать постепенно решать их. Если же такие проблемы не всплывают сами собой во время анализа, возможно, они не так важны, как кажется.

В попытках использовать метод «Пяти “Почему?”» IGN упустила из виду три важных момента:

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

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

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

После первой встречи руководство IGN решило дать методу «Пять “Почему?”» еще один шанс. Следуя советам, изложенным в этой главе, они назначили специалиста по «Пяти “Почему?”». Им стал Тони Форд, директор по разработке. Тони был предпринимателем и пришел в IGN, когда она купила его небольшую компанию. Он начал с интернет-технологий и в конце 1990-х гг. стал создавать веб-сайты, посвященные видеоиграм. Так появился стартап TeamXbox, где Тони был ведущим разработчиком программного обеспечения. В 2003 г. TeamXbox вошла в состав IGN Entertainment, и Тони стал разработчиком, а также лидером инноваций и сторонником гибкой методологии разработки и бережливого производства.

К сожалению, с самого начала Тони не удалось выбрать узкую проблемную область, на которой все могли бы сосредоточиться. Это вызвало замешательство и раздражение. Сам Тони рассказывает об этой ситуации так: «Я только недавно стал специалистом по «Пяти “Почему?”» и провел встречу не лучшим образом. Кроме того, мы выбрали для решения слишком сложные проблемы. Поэтому первые встречи не принесли особой пользы. Я был обескуражен и расстроен».

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

Все изменилось, когда Тони провел встречу в связи с одним проектом, который не был закончен в срок. Встреча была увлекательной, на ней родилось множество новых идей и были приняты правильные решения. Тони говорит: «Все прошло хорошо, ведь и у меня, и у других участников было больше опыта. Все уже знали, что это за метод, и я поработал как следует. Я успешно руководил встречей и не позволял участникам отклоняться от темы. Это было самое главное. Это был поворотный момент. Тогда я понял, что «Пять “Почему”» — новый инструмент, который поможет нам работать еще лучше».

На первый взгляд, метод «Пять “Почему?”» хорош для решения технических проблем. Но по мере того, как команды избавляются от ненужных трат, они начинают по-новому воспринимать командную работу. Тони говорит: «Я осмелюсь сказать, что этот метод позволяет не только анализировать причины проблем, но и делиться информацией и мнениями. Это сближает команду, благодаря общему пониманию и общей точке зрения. Часто проблемы разобщают людей, а «Пять “почему?”», наоборот, объединяют их».

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

Программа QuickBooks много лет занимает ведущие позиции в своей категории. Поэтому у нее есть большая база лояльных клиентов, и она приносит компании Intuit существенную долю ее дохода. Команда разработчиков QuickBooks обычно выпускала новую версию ежегодно, одним большим пакетом. Так происходило и с другим программным обеспечением для ПК, созданным в последние два десятилетия. И так было еще три года назад, когда в команду пришел Грег Райт, новый директор по маркетингу QuickBooks. Существовало множество процессов, обеспечивавших целостность продукта и его своевременный выпуск. Перед выпуском новой версии команда тратила достаточно времени на то, чтобы выяснить, чего хотят пользователи.

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

В 2009-м, в первый год своей работы в команде QuickBooks, Грег столкнулся с серьезной проблемой. Компания представила совершенно новую систему для онлайн-банкинга. Это была одна из самых важных опций новой версии QuickBooks. Команда провела несколько раундов тестирования удобства и простоты использования, применяя макеты и теоретические модели, а затем провела бета-тестирование на основании типовых данных о пользователях. В момент запуска все выглядело хорошо.

Первая бета-версия была выпущена в июне, и тут же стали поступать негативные отзывы. Пользователи жаловались, но достаточных оснований для того, чтобы приостановить выпуск новой версии, не было, потому что технически она отвечала всем требованиям — не уничтожала компьютеры. Грег оказался в безвыходном положении. Он никак не мог выяснить, как эта обратная связь повлияет на реальное поведение потребителей на рынке. Это просто отдельные жалобы? Или симптом общей проблемы? Одно он знал наверняка: его команда должна уложиться в срок.

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

Чтобы оценить степень удовлетворенности пользователей ее продуктами, компания Intuit проводит маркетинговые исследования с использованием NPS (Net Promoter Score — чистый индекс поддержки). Это надежный способ установки действенных показателей, дающий объективное представление о том, что пользователи думают о продукте. Я использовал его и в IMVU. Одно из достоинств NPS заключается в том, что он очень стабилен. Он измеряет основной уровень удовлетворенности потребителей и не подвержен незначительным колебаниям, регистрируя только существенные изменения в настроениях пользователей. В тот год показатели QuickBooks упали на 20 пунктов, впервые с того времени, как в компании начали проводить подобные исследования. Такое падение привело к существенным убыткам для Intuit и стало очень неприятным сюрпризом, ведь обратная связь от потребителей пришла на слишком поздних стадиях процесса, и у компании уже не было времени на итерацию.

Руководство компании решило, что пора что-то менять. Управлять этими изменениями было поручено Грегу. Теперь у него была важная миссия: достичь при разработке и развертывании QuickBooks скорости стартапа.

Следующая страница этой истории рассказывает о том, что создать адаптивную организацию очень непросто. Грег решил изменить процесс разработки в QuickBooks на основании четырех принципов:

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

2. Сократить время цикла.

3. Быстрее получать обратную связь от потребителей, тестировать, не повредит ли новая версия компьютеры пользователей, и выяснять, как влияют новые опции на качество обслуживания клиентов.

4. Дать командам полномочия принимать быстрые и смелые решения.

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

Фактически процесс разработки оставался почти таким же, как в прошлые годы. Как поясняет Грег: «У организации есть “мышечная память”, и людям трудно избавиться от старых привычек». Грег сражался с системой и проводил отдельные изменения, например переназначил дату выпуска, но старые привычки были еще сильны.

Раздраженный неудачами прошедшего года, Грег объединился с лидером команды разработки продукта Химаншу Бакси. Вместе они решительно избавились от всех старых процессов. Они публично заявили о том, что их объединенные команды намерены создать новые процессы и что они не собираются возвращаться к старому.

Грег и Химаншу не стали менять сроки выпуска новой версии. Вместо этого они сосредоточились на изменениях, связанных с процессами, продуктом и технологиями, которые позволяли работать с меньшими партиями. Эти технические инновации способствовали тому, что отзывы от клиентов стали поступать раньше. Грег начал новый год не с планирования действий на 12 месяцев вперед, а с того, что назвал «заторами» идеи/кода/решения. Инженеры, продукт-менеджеры и пользователи объединили усилия и создали «трубопровод идей». Грегу, как продукт-менеджеру, было страшно начинать год, не имея точного перечня опций новой версии продукта, но он был уверен в своей команде и в новом процессе. В третий год работы он ввел новые методы:

• команды активно участвовали в создании новых технологий, процессов и систем;

• кросс-функциональные команды были сформированы вокруг новых идей;

• контакт с пользователями поддерживался с самого начала разработки каждой опции.

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

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

Чтобы процесс изменений шел успешно, очень важно было наладить коммуникацию. Руководители команды были открыты к обсуждению изменений и причин, по которым эти изменения необходимы. Скептицизм сотрудников чаще всего был связан с тем, что они не представляли, какие конкретно преимущества может принести новый подход. Ведь это был совершенно новый процесс. Им нужно было объяснить, почему старый процесс не работает и почему привычный способ выпуска новой версии не ведет к успеху. В ходе изменений сотрудникам постоянно говорили, каких результатов нужно достичь: быстрее получать обратную связь от клиентов и ускорить цикл разработки, не связанный с ежегодной датой выпуска новой версии. Руководители постоянно подчеркивали, что новый подход используют конкуренты, разрабатывая новые продукты и проводя итерации. Поэтому компании придется или последовать их примеру, или просто уйти с рынка.

Раньше новые версии QuickBooks разрабатывала большая команда, и цикл разработки был длительным. Например, в предыдущие годы команда онлайн-банкинга состояла из 15 разработчиков, семи специалистов по качеству, продукт-менеджера, а иногда приглашали еще и нескольких дизайнеров. Теперь в каждой команде — не больше пяти человек. Основная их цель — быстрые итерации с участием пользователей, проведение экспериментов, подтверждение фактами и принятие на их основе решений, над чем нужно продолжать работать в первую очередь. Раньше было пять основных отделов по разработке QuickBooks, которые объединяли созданные ими опции только во время выпуска новой версии. Теперь таких отделов 20 или 25. Это позволяет проводить гораздо больше экспериментов. Каждая команда работает над новой опцией по полтора месяца, в течение всего процесса тестируя ее с участием реальных пользователей.

Мало изменить культуру — основные изменения, необходимые для создания адаптивной организации, должны произойти в мышлении ее сотрудников. Как мы видели в главе 9, метод бережливого производства требует, чтобы все действия компании воспринимались системно. А затем нужно сокращать размеры партий и время прохождения цикла всего процесса. Таким образом, для достижения долгосрочных изменений команде QuickBooks нужно было создать новые инструменты и изменить платформы, чтобы начать работать быстрее и по-новому.

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

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

На третий год результаты заметно улучшились. Очередная новая версия QuickBooks продемонстрировала гораздо более высокие показатели удовлетворенности потребителей и продавалась лучше предыдущих. Если сейчас вы используете QuickBooks, возможно, ваша версия программы создана уже по методу небольших партий. На четвертый год работы в команде QuickBooks Грег стал искать новые способы сократить размеры партий и ускорить цикл. Как обычно, здесь есть возможности, лежащие за пределами технических решений. Например, ежегодный цикл продаж новых версий программного обеспечения не позволяет быстро учиться. Поэтому команда начала экспериментировать, привлекая самых активных пользователей. Они могут загружать обновления в режиме онлайн, и поэтому Intuit может выпускать новые версии своих программ чаще, чем раньше. В ближайшее время команда QuickBooks собирается выпускать обновления каждый квартал.

Работая по системе «экономичный стартап», команда может использовать адаптивные методы для разработки более сложных процессов, не отказываясь при этом от основного преимущества: быстро проходить цикл обратной связи «создать — оценить — научиться». Одно из основных преимуществ использования методов из арсенала бережливого производства заключается в том, что в процессе развития компания может в соответствии с ними совершенствовать свои операции. Команды уже знают, как следовать дисциплине, разрабатывать процессы с учетом своей индивидуальной ситуации, и используют такие методы бережливого производства, как «Пять “Почему?”» и работу небольшими партиями. И когда успешный стартап превращается в стабильную компанию, в нем уже есть культура, основанная на строгих экспериментах и дисциплине, характерная для лучших компаний мира, таких как Toyota.

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

Чтобы команда инноваций достигла успеха, ей нужна правильная структура. Если у стартапа есть поддержка венчурного капитала, такая структура возникает естественным образом — ведь он остается небольшой, независимой компанией. Внутренним командам-стартапам в крупных компаниях тоже нужна такая структура, и здесь важна поддержка высшего руководства. По моему опыту, командам стартапов обоих типов необходимы для успешного развития три условия: скромные, но доступные ресурсы, возможность независимо развивать и проверять свои идеи и личная заинтересованность в результате. В подразделениях крупных стабильных компаний таких условий обычно нет. Помните, что структура — это просто предпосылка, она не гарантирует успеха. Но неправильная структура почти наверняка приведет к неудаче.

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

У стартапа все по-другому: слишком большой бюджет для него так же вреден, как и слишком маленький — это подтвердили неудачи бесчисленных доткомов, — и стартапы очень чувствительны к изменениям бюджета в процессе работы. Очень редко стартап может позволить себе неожиданно сократить бюджет на 10 %. Такой удар может оказаться для него фатальным. У независимых стартапов очень невысокая доля прибыли и поэтому почти нет права на ошибку. Так что стартапом управлять и легче, и сложнее, чем подразделением крупной компании: ему нужно намного меньше капитала, но этот капитал должен быть защищен от любых посягательств.

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

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

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

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

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

Эта формула эффективна и для коммерческих организаций. В компании Toyota менеджера, который отвечает за разработку новой модели от начала до конца, называют главным инженером, или суса.

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

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

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

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

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

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

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

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

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

Подобные ситуации как раз и создают плохую репутацию экспериментам и решениям, основанным на данных. А все дело было в том, что команда баз данных писала отчеты, которых никто не читал или не понимал. Проектные группы считали, что эксперименты — пустая трата времени, потому что для них придется создавать сырые и «недоделанные» опции. Слова «провести эксперимент» казались просто оправданием для того, чтобы отложить трудное решение. И даже высшее руководство компании считало такие встречи хронической головной болью. Привычные встречи, посвященные расстановке приоритетов, могли быть просто борьбой мнений, но хотя бы было понятно, что на них происходит. Теперь же им приходилось проводить ритуал, связанный со сложными математическими расчетами и не приносивший никаких результатов, — и он все равно заканчивался борьбой мнений.

Однако в основе этой вражды подразделений лежал вполне понятный страх. Компания обслуживала два сегмента потребителей: корпоративных клиентов и частных. В одном сегменте у компании были продавцы, предлагавшие сложные системы другим компаниям, а в другом происходили по большей части одноразовые покупки. Основная часть текущих доходов компании поступала от продаж B2B, но рост в этом сегменте замедлился. Все считали, что в сегменте частных клиентов есть огромный потенциал роста, но его никак не удавалось реализовать.

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

Команда, отвечавшая за рост сегмента В2С, хотела провести эксперимент: снизить цены и посмотреть, что будет. Команда, отвечавшая за сегмент В2В, опасалась, что это отпугнет корпоративных клиентов. Что будет, если они увидят, что обычные люди покупают продукт по более низким ценам, чем они?

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

Важно подчеркнуть, что страхи компании были вполне обоснованы. Саботаж — адекватная реакция менеджера, если кто-то вторгается на его территорию. Эта компания — не скромный маленький стартап, у которого еще ничего нет. Большой компании всегда есть что терять. Если доход от основного бизнеса начнет снижаться, полетят головы. И к этому невозможно отнестись легкомысленно.

Но если бы эта компания не стала активно экспериментировать, ее в итоге постигла бы печальная участь: год за годом высокие прибыли, а потом внезапная смерть.

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

Рассмотрим эту ситуацию с точки зрения менеджеров, которым поручили разработку инноваций. Скорее всего, они будут считать, что их предали, и начнут превращаться в параноиков. В конце концов, если что-то настолько важное можно успешно скрывать, что еще поджидает их в темноте? Со временем это приводит к политическим играм, поскольку менеджеры начинают во всем искать угрозу своей власти, влиянию и карьере. И успех инноваций — не оправдание для такого нечестного поведения. С точки зрения опытного менеджера, ситуация выглядит так: если вы не владеете информацией, все эти секреты приведут к тому, что вам нанесут удар в спину.

Несправедливо критиковать этих менеджеров — ответственность здесь лежит на высшем руководстве, которое не смогло создать систему поддержки, позволяющую открыто действовать и создавать инновации, не пытаясь «прятать» их. Я полагаю, что именно по этой причине компании, действующие по примеру IBM, быстро теряют лидерские позиции на новых рынках, которые завоевали, создав инновации в «черном ящике». Ведь они не могут укреплять и поддерживать культуру, которая и позволила им создать эти инновации.

Но выход есть. Можно создать механизм, который даст команде необходимые полномочия и позволит открыто создавать инновации. Это — путь к жизнеспособной культуре инноваций, которая позволит компании выжить, когда она снова и снова будет сталкиваться с угрозами своему существованию. Я предлагаю такое решение: создать «песочницу» инноваций, в которой можно проверять новые идеи любыми методами, без всяких ограничений. Это можно сделать следующим образом: любая команда может разработать эксперимент по сплит-тестированию, затрагивающий только те элементы товара или услуги (если они состоят из нескольких элементов), которые помещены в «песочницу», либо предназначенный только для определенных сегментов потребителей или территорий (для новых продуктов). При этом:

1. Одна и та же команда должна проводить эксперимент полностью, от начала до конца;

2. Эксперимент должен занимать четко определенное время (обычно это несколько недель для простых экспериментов с опциями, а если речь идет о подрывных инновациях — то дольше);

3. Эксперимент может распространяться только на определенное количество клиентов (обычно оно определяется как процент от общей базы основных клиентов компании);

4. Каждый эксперимент нужно оценивать на основе единственного стандартного отчета, содержащего пять-десять (не больше) действенных показателей;

5. Каждая команда, работающая в «песочнице», и каждый продукт, который она создает, должны использовать одни и те же показатели для оценки успеха;

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

Вначале «песочница» должна быть небольшой. В компании, описанной выше, в «песочницу» сперва входил только прайс-лист. В зависимости от типа продуктов, которые создает компания, размер «песочницы» может быть определен по-разному. Например, онлайн-сервис может ограничить ее определенными страницами сайта или потоками пользователей. Розничная компания может ограничиться несколькими магазинами или географическими областями. Если компания пытается вывести на рынок совершенно новый продукт, ограничения могут касаться определенных сегментов потребителей.

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

При любой возможности команды инноваций должны быть кросс-функциональными, и их руководитель должен обладать теми же полномочиями, что и суса в компании Toyota. Он должен иметь возможность руководить созданием, выводом на рынок и продвижением продуктов или опций в «песочнице» без предварительного одобрения высшего руководства. Его отчеты об успехах или неудачах проекта должны быть основаны на стандартных действенных показателях и учете инноваций.

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

Успех или неудачу эксперимента оценить легко, потому что с самого начала установлены точные критерии и показатели. Так или иначе, команда может очень быстро выяснить, верны ли ее предположения о поведении клиентов. Используя систему учета инноваций, описанную во второй части, команда может сообщать о своем продвижении. И все, кто будет читать ее отчеты, тоже увидят, насколько эффективны действенные показатели. Такой подход очень продуктивен. Даже если кто-то захочет саботировать усилия команды инноваций, для этого ему придется как минимум понять, что такое действенные показатели и этапы обучения.

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

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

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

В соответствии с такой моделью внутренние команды инноваций, по сути, действуют как стартапы. А если они добились успеха, новые продукты нужно интегрировать в общий портфель товаров и услуг компании.

Любая компания проходит в своем развитии разные фазы. На первой стадии развития стартапа предприниматели, авторы оригинальной идеи, должны решить проблему масштаба. У компании появляются новые клиенты на основном рынке, она завоевывает новые территории, у нее возникает определенная репутация, и это отражается в ее пиар-кампаниях, маркетинге, продажах и развитии бизнеса. В большинстве случаев продукт привлекает конкурентов: подражателей, быстрых последователей и имитаторов всех мастей.

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

Затем компания входит в ту фазу, когда особое значение приобретают унаследованные продукты и эксплуатационные расходы. Это область аутсорсинга, автоматизации и снижения затрат. Тем не менее и на этом этапе проблемы с ресурсами, с инфраструктурой или потеря лояльных клиентов могут уничтожить компанию. И в отличие от первых фаз теперь инвестиции не помогут ей достичь быстрого роста. На этой стадии менеджеры часто похожи на бейсбольных судей: их критикуют, когда что-то идет не так, но не обращают на них внимания, когда все хорошо.

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

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

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

Что же делать в такой ситуации? Выход в том, чтобы по-разному управлять всеми видами задач, создавая кросс-функциональные команды в каждой области. Когда проект по разработке нового продукта переходит из одной фазы в другую, его передают от команды команде. Сотрудники могут переходить из команды в команду вместе с продуктом или оставаться на прежнем месте и начинать работу над чем-то новым. Ни тот ни другой выбор не является предпочтительным, все зависит от характера и навыков каждого человека.

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

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

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

В идеале со временем «песочница» будет расти: вместо того, чтобы переводить команду инноваций из «песочницы» в стандартные рутинные условия работы в компании, можно увеличить объем «песочницы». Например, если эксперименты в «песочнице» касались лишь некоторых аспектов продукта, к ним можно добавить новые опции. В ситуации, описанной выше, это можно сделать, сначала поместив в «песочницу» только ценообразование. Получив результаты этих экспериментов, компания может добавить в «песочницу» домашнюю страницу веб-сайта. А затем — функциональность поиска или общий веб-дизайн. Если изначально в целевую группу входили только отдельные пользователи или определенное их количество, то можно привлечь новых. При этом руководители компании должны позаботиться о том, чтобы команды, работающие в «песочнице», не подвергались давлению со стороны головной организации. «Песочница» нужна и для их защиты, и для защиты головной компании, и если возникла идея увеличить «песочницу», об этом нужно помнить.

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

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

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

Вернемся на несколько лет назад, в те годы, когда я руководил процессом разработки продукта. Каждого нового сотрудника нужно было ознакомить с системой «экономичный стартап». Сплит-тестирование, непрерывное развертывание и тестирование с участием клиентов были в нашей компании стандартными методами. Мне нужно было постоянно продвигать свои идеи, чтобы каждый новый сотрудник был готов дать им шанс. Но те, кто уже какое-то время проработал в компании, воспринимали их как нечто само собой разумеющееся, как установленный порядок.

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

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

Я понял, что каждое предложение нужно подвергать тому же самому строгому анализу, который привел к созданию системы «экономичный стартап». Можно ли на основе теории предсказать результаты предложенных изменений? Можно ли ввести изменение в небольших масштабах и посмотреть, что будет? Можно ли измерить его воздействие? Всякий раз, когда это можно было сделать, эти подходы позволяли учиться мне самому и, что еще важнее, увеличивали продуктивность компаний, с которыми я работал. Многие методы системы «экономичный стартап», которые мы изобрели в IMVU, не были предложены лично мною. Их предложили, протестировали и внедрили наши сотрудники, вложив в них свой талант и творческий подход.

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

Чтобы ответить на эти вопросы, нужна теория. Те, кто пытается использовать систему «экономичный стартап» просто как набор методов или тактик, не добьются успеха. Мне пришлось узнать это на собственном горьком опыте. У стартапа постоянно возникают проблемы. И каждый раз мы сталкиваемся со старой дилеммой, поставленной еще Демингом: как мы узнаем, что проблема вызвана отдельной ошибкой, а не системной причиной? Если мы находимся в процессе принятия нового подхода, то всегда есть соблазн обвинить в возникающих проблемах новую систему. Иногда это бывает справедливо, а иногда нет. Чтобы это выяснить, нужна теория. Нужно иметь возможность предсказывать, что принесут изменения, которые мы вводим, чтобы определить, что возникающие проблемы — действительно проблемы.

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

Я обучаю других своей системе уже много лет и постоянно сталкиваюсь с тем, что переход к концепции подтверждения фактами сначала вызывает отторжение и только потом люди начинают видеть, в чем заключается ее суть. Дело в том, что проблемы, вызванные старой системой, часто бывают неосязаемыми, а проблемы новой системы слишком очевидны. Но тут нужно знать теорию. Если все понимают, что временное снижение продуктивности в переходном периоде неизбежно, то этим процессом можно активно управлять. Ожидания можно установить с самого начала. Например, в своей консалтинговой практике я поднимаю этот вопрос с первого дня; если не сделать этого, то есть риск свести на нет все остальные усилия. Но по мере внедрения изменений можно с помощью анализа первопричин выяснять, какие проблемы нужно предотвратить. В конце концов, «экономичный стартап» — это система, а не план, которому нужно следовать. Она разработана таким образом, чтобы ее можно было адаптировать к условиям каждой отдельной компании. Не нужно слепо копировать то, что делают другие. Такие методы, как «Пять “Почему?”» позволяют найти то, что лучше всего подходит именно вашей организации.

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