Это рассказ о нашем опыте выстраивания процесса работы growth-команды и наборе лайфхаков, которые пригодятся продуктовому аналитику при работе в режиме быстрой проверки гипотез.
Для тех, кто еще не знаком с growth hacking, поясню: это методология для поиска возможностей быстрого роста IT-продукта, которая помогает командам хорошо ускориться при разработке нового продукта.
Кто мы, зачем была нужна growth-команда, и что у нас получилось
Я продуктовый аналитик в команде внутреннего стартапа Циан. Мы мечтаем изменить рынок аренды, сделав его более понятным с точки зрения собственника и приятным с точки зрения арендатора. Методом проб и ошибок мы пытаемся создавать новый продукт. У нас крутая продуктовая команда, мы привыкли слушать наших пользователей, но в условиях, когда создаёшь инновацию, невозможно не ошибаться.
Гипотезы в разработке стоят довольно дорого, а стартап-продукт требует быстрых скоростей. Поэтому в конце 2020 года мы стали думать, как удешевить наши ошибки и проверять больше гипотез в короткие периоды времени. Возникла идея создания growth team внутри основной команды.
Было две цели, которые должна была решать новая команда:
Искать простые идеи по улучшению продукта, до которых не доходят руки у менеджеров продукта;
«Дёшево и сердито» проверять прорывные гипотезы.
По итогам работы за 10 месяцев мы достигли следующих результатов:
Придумали 292 гипотезы;
137 из них запустили;
42% из реализованных гипотез признали успешными и включили в продукт;
В конце работы вышли на темп 20 гипотез в месяц;
Собрали MVP продукта для арендаторов, посчитали его unit-экономику.
Как лучше выстраивать работу growth-команды
Состав участников
Команда желающих хакнуть процессы и идти к звездам собралась быстро. В неё вошли 4 человека: два разработчика, один из них в роли лида команды, исследователь и продуктовый аналитик (я). Первые два месяца на обсуждениях был наш продакт-менеджер, в роли «невидимой руки». Мы работали в формате недельных спринтов.
Процесс обсуждений и приоритизации
Мы выстраивали работу внутри каждого спринта в таком порядке:
Определяем тему спринта.
Проводим брейншторм: команда накидывает любые идеи в рамках выбранной темы. Через пару месяцев работы стало сложнее придумывать идеи, и мы стали приглашать на брейнштормы людей из основной команды.
Каждый член команды берёт на себя 2-3 идеи, выработанные на брейншторме, для проработки. Проработка — это подробное описание деталей, создание макетов, текстов. Мы выработали собственный шаблон для создания гипотез, который позволяет правильно их формулировать, не забывать про аналитику и держать все обсуждения вокруг гипотезы в одном месте.
Аналитик придумывает метрику, по которой будет приниматься решение об успешности гипотезы. Смотрит текущие показатели метрики и решает, сколько времени потребуется, чтобы измерить результаты.
На общей встрече команды мы презентуем свои идеи. На этом этапе часть идей может отсеяться из-за недостаточной проработанности.
После презентации всех идей начинается процесс приоритизации. Каждый член команды оценивает идеи по десятибалльной шкале по трём критериям: вера, сложность, влияние.
Исходя из оценок формируется бэклог задач для разработчика на следующую неделю.
Инструмент координации задач
Мы использовали Airtable для ведения идей и приоритизации. Airtable позволяет назначать приоритетность гипотезам, менять их статусы и ещё много всего. У меня как у аналитика есть отдельный дашборд, где я вижу, какие гипотезы нуждаются в рассмотрении до приоритизации, какие гипотезы уже нужно оценить. Инструмент даёт чёткое понимание, на каком этапе сейчас находится гипотеза.
Быстрая разработка
Ключевым ограничением является временной ресурс разработчиков, поэтому крайне важно правильно его распределять. По итогам работы мы пришли к четырем важным решениям:
1. Нужно думать о том, как проверить гипотезы без написания кода
Мы поняли, что некоторые гипотезы можно проверить, если просто спросить у пользователей, представившись специалистом отдела продаж Циан. Иногда это сильно экономит время разработки, и дополнительным бонусом будет услышанный голос пользователя. Но тут нужно быть осторожным и уметь определять, в каких случаях идея может быть продана словами не хуже, чем интерфейсом.
2. Оценивать сложность разработки должны сами разработчики
Оказалось, что оценка сложности, описанная в процессе приоритизации, не работает. Мы пришли к выводу, что оценивать сложность должен разработчик, который непосредственно будет выполнять задачу, иначе едут все сроки и планы. Разработчик дает оценку задачам на встрече команды сразу после приоритизации. Иногда бывает, что гипотезы, которые мы оценили как лучшие, стоят в разработке больше дня: в таких случаях мы берем их в работу только при единогласном решении.
3. Нужно постоянно задавать вопрос: «Как сделать дешевле?»
Обдумывая гипотезу, мы стараемся довести её до идеальной формы. Но иногда получается в разы удешевить разработку, немного упростив реализацию изначальной задумки. В итоге вопрос «Как сделать дешевле?» оказался в списке обязательных вопросов во время защиты гипотезы перед приоритизацией.
4. Нужно перезапускать гипотезы
Большинство гипотез не выстреливают, но на их проработку и разработку уже было потрачено время, поэтому поменять какую-то деталь в них почти ничего не стоит. У нас были кейсы, когда небольшая деталь полностью меняла результат. Например, сделали новую точку входа, но она совсем не принесла новых подключений. Тогда мы поменяли заголовок и подключений стало гораздо больше. При этом надо держать баланс, чтобы не скатиться в постоянные перезапуски идей, в которые мы верим, в то время как пользователям они неинтересны.
Мои лайфхаки для аналитиков
Постоянно проверяя огромное количество гипотез и стремясь сделать это более эффективно и без ущерба качеству, я пришла к использованию трёх лайфхаков:
1. Концентрация на теме
Мы ограничивали обсуждения одной темой за спринт и чередовали 2-3 темы спринтов в течение квартала. Во-первых, я как аналитик делала в разы меньше работы по оценке гипотез, поскольку метрика для спринта уже есть и нужно просто обновить данные. Во-вторых, команда, взаимодействуя из спринта в спринт с одними и теми же метриками, начинает лучше понимать аналитику.
Благодаря тому, что метрики по теме уже собраны, мы стали начинать наши брейнштормы по придумыванию гипотез с аналитической сводки, где я рассказывала про текущие показатели. Это бывало очень полезно, иногда метрики вдохновляли команду на поиск гипотез. Например, в один из спринтов мы работали над увеличением количества шаблонов анкет, которые создает арендатор. Имея перед глазами воронку, которую проходит пользователь, мы понимали, какие шаги вызывают большие проблемы у пользователей. Такой подход, когда у команды есть полная аналитика по теме спринта, открывал возможность придумывать гипотезы, отталкиваясь от метрик. В какой-то момент от работы над одними и теми же темами у нас наступил кризис креативности и аналитика стала помогать нам, давая базу для идей. Мы видели слабые места более точечно, так придумывать гипотезы стало гораздо проще.
Кроме того, благодаря повторяющимся темам спринта авторы гипотезы сами могли её прорабатывать с точки зрения аналитики, экономя моё время. Так как всем понятны метрики, которые мы хотим улучшить, и уже есть собранные значения по ним.
2. Тестирование пакетных предложений
Второй лайфхак касается тех спринтов, в которых мы пытались собрать на коленке MVP продукта для арендаторов. В рамках этой темы мы проверяли спрос арендаторов на новые фичи. В таких случаях очень удобно тестировать пакетные предложения, ставя на них привлекательную цену, примерно равную стоимости одного пункта из пакета.
Пример гипотезы с пакетными предложениями
Мы предлагаем пользователю пакет фич и смотрим, находит он в нём ценность или нет. Если находит, то мы начинаем тестировать, какие именно фичи ему понравились, по очереди откидывая варианты из пакета. Такой подход хорош тем, что если нет спроса на пакет, то мы просто не тратим время на все включенные в него гипотезы и переходим к следующим. Если спрос есть, то начинаем тестировать отдельно каждый пункт из пакетного предложения. Перебор в разработке нам уже почти ничего не стоит, остается просто потратить время для сбора данных. При таком подходе мы тестируем только те гипотезы, которые находят отклик у пользователя, и сразу отбрасываем те, которые не вызывают практически никакого интереса.
3. Не бояться когортного сравнения
Третий совет, который хотелось бы дать аналитикам, работающим в growth-командах: не бойтесь иногда переходить от АВ-тестов к когортному сравнению. По негласным правилам growth hacking, нежелательно брать в спринт гипотезы, сбор данных по которым будет длиться больше недели. Мы иногда нарушали это правило. Из-за того, что мы делаем новый продукт, у нас мало аудитории, поэтому иногда для сбора данных требовалось 3-4 недели. В таких случаях, чтобы ускорить процесс сбора данных, мы отказывались от идеи АB-тестов. Просто выкатывали изменение и смотрели на метрику в динамике. При этом, конечно, стоит быть осторожным и постоянно держать в голове такие факторы, как сезонность и прочие (тут должна быть ссылка про важность АВ-тестов). С другой стороны, не стоит забывать, что формат growth подразумевает взрывной рост, а влияние фактора сезонности на промежутке в одну неделю маловероятно, поэтому мы жертвовали им, чтобы проверять гипотезы быстрее. Не бойтесь немного отойти от строгой аналитики: маленькое изменение не поможет выйти на новый уровень быстро, а целая свободная неделя даст время для проверки ещё одной гипотезы, которая, возможно, выстрелит!
Мы получили отличный опыт, который улучшил наш продукт. Проверили очень много гипотез за относительно небольшое время. Глядя на нас, методологию growth hacking стали применять другие продуктовые команды в Циан. Надеюсь, наш опыт будет полезен для вас. А если у вас есть инсайты для работы growth-команды, будем рады их обсудить в комментариях.