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

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

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

Цифры, которые меняют всё

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

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

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

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

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

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

Структура ответственности, подходящая для любой отрасли

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

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

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

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

Как работает учет инноваций: три обучающих этапа

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

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

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

Установка базовых показателей

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

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

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

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

Настройка механизма

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

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

Вираж

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

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

Учет инноваций в IMVU

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

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

Как совершенствовать продукт за $5 в день

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

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

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

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

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

Когортный анализ

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

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

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

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

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

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

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

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

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

Оптимизация или обучение?

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

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

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

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

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

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

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

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

«Показатели тщеславия»: предостережение

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

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

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

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

Действенные показатели вместо «показателей тщеславия»

Чтобы лучше понять, почему так важны правильные показатели, давайте познакомимся с компанией под названием 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 и на странице регистрации. У группы с «ленивой регистрацией», наоборот, было гораздо больше информации о продукте, потому что эти люди уже им пользовались. Тем не менее, несмотря на то, что разные пользователи были по-разному информированы, поведение в обеих группах было одинаковым.

Это показало, что для эффективного привлечения пользователей нужно заняться в первую очередь не новыми опциями, а позиционированием и маркетингом. Это был только первый из множества важных экспериментов, которые провела 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.