Помоги проекту - поделись книгой:
Мы отслеживали те аспекты поведения клиентов, которые считали самыми важными для нашего механизма роста: регистрацию, загрузку приложения, использование пробной версии, покупку продукта. Чтобы получить достаточно данных, нам нужно было привлечь достаточно пользователей – так мы могли получить реальные цифры для каждого типа поведения. Мы выделили на это бюджет в $5 в день: этого было достаточно для покупки кликов в системе AdWords компании Google. В те дни минимальная стоимость клика составляла 5 центов и никаких ограничений не было. Поэтому мы смогли позволить себе открыть счет и начать экспериментировать, почти не тратя денег[12].
Каждый день $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. Мы не стали выводить аналитику или данные в отдельную систему. Данные отчета и его инфраструктура считались частью самого продукта, и за них отвечала команда разработки. Отчеты выкладывались на нашем сайте и были доступны любому, у кого был аккаунт сотрудника.
Поделиться книгой: