Запуск Growth Team в Movavi

Как в Movavi перестали делать функции в продукте, начали тестировать пять гипотез роста в неделю и увеличили выручку на $27 тысяч в месяц.

Для этого в Movavi пришлось поменять мышление, собрать Growth Team (команду роста), полностью изменить процессы, пересмотреть инструменты. В статье все подробности этих изменений: от теории до реальной истории внедрения.

Movavi. Уверен, вы о ней хоть раз, но слышали. Компания-разработчик программного обеспечения для работы с видео, аудио и фото, которое продаётся в более чем 150 странах мира. Сейчас в Movavi работают более 300 сотрудников.

Growth Academy — первая компания в России, которая системно обучает, внедряет процессы Growth Hacking и запускает Growth Team (команды роста). Среди клиентов: «Райффайзенбанк», ФРИИ, Freemake, Timeweb, CS-Cart.

Я, Юрий Дроган, генеральный директор Growth Academy, внедрял Growth Hacking процессы в Movavi, о чём вам и хочу рассказать в подробностях.

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

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

Итак, передо мной стояла задача запустить Growth Team и тестировать минимум пять гипотез в неделю. Для этого я сначала провёл двухдневный обучающий курс в компании на 20 человек, чтобы все в компании получили одно и то же понимание и терминологию Growth Hacking. Затем выделили небольшую команду, встречи которой я помогал провести.

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

Сначала поговорим о теории и инструментах процессов Growth Hacking, затем я расскажу, как проходили четыре встречи команды, где мы приземляли эту теорию.

Что за зверь такой Growth Team (она же команда роста)? Вот лучшее определение.

Первой в истории командой роста считается та, что была организована в Facebook. Её возглавлял Чамат Палихапития. Именно его команда привела первые 500 млн пользователей в соцсеть. Был разработан простой фреймворк: привлечение — активация, вовлечение и виральность. Именно он обеспечивал прозрачность и логичность процессов и позволял легко и правильно приоритизировать внедрение гипотез, проводить эксперименты и создавать продукты.

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

Чтобы настроить непрерывный процесс тестирования гипотез в Growth Academy, разработан фреймворк — Growth Scrum. Он чётко детализирован, в отличии от HADI- и PDCA-циклов.

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

Growth Scrum предполагает тестирование гипотез в рамках одно- или двухнедельного спринта.

Ключевым событием в Growth Scrum является Growth Meeting, который проводится в одно и то же время в начале спринта и длится не более двух часов.

Growth Meeting обладает чёткой структурой:

• обзор спринта;
• ретроспектива спринта;
• обсуждение гипотез;
• приоритизация гипотез.

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

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

Эта часть обычно длится не более 30 минут.

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

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

Третий этап Growth Meeting — обсуждение идей из бэклога и превращения их в гипотезы. Здесь особенно важна работа Growth Master. Он следит за правильным формулированием гипотез с указанием ожидаемого эффекта, чтобы команда не сваливалась в бесконечное обсуждение гипотез. Важно отсекать гипотезы, если они не могут быть быстро «проданы» команде.

Приоритизация гипотез — это последний этап Growth Meeting. Он крайне важен, так как ценность и время исполнения у гипотез разная. Их приоритизация может осуществляться например по шаблону ICE Score.

Daily Meeting — это ежедневная встреча. Она нужна, чтобы команда не тестировала гипотезы в пятницу вечером и экспериментирование поддерживалось в течении недели. Daily Meeting проводится в одно и то же время, в течение 10–15 минут, как в скраме.

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

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

• идеи;
• приоритизация;
• исполнение (или в работе);
• измерение;
• успех;
• неуспех.

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

Вы можете скопировать её по этой ссылке: Growth Hacking Board Template.

Подробнее опишу каждый этап:

• Идеи. Все идеи, которые появились во время Daily Meeting или в течение недели, записывайте в первый столбик в сыром виде — так, как они пришли в голову. Уже на еженедельном Growth Meeting на этапе обсуждения гипотез карточка с гипотезой переносится на следующий этап приоритизации.
• Приоритизация. Во время Growth Meeting необходимо приоритизировать перешедшие на этот этап гипотезы, например, по методологии ICE Score. Переместите карточки «победивших» гипотез на следующий этап.
• Исполнение (в работу). На этом этапе назначаются исполнители и ответственные за внедрение гипотез, комментируется прогресс реализации.
• Измерение. Когда гипотеза запущена, карточка перемещается на этап измерений, пока данные по гипотезе не будут запущены. Тут гипотеза может находиться от нескольких дней или недель (если это гипотеза дохода, например). Когда данные собраны, обязательно поместите скриншот с результатами эксперимента из системы аналитики в карточку гипотезы.
• Успех ил неуспех. Данные собраны? Ожидаемый эффект достигнут? Да? Помещаем карточку с гипотезой в «Успех». Нет — в «Неуспех». Так формируется база для будущих инсайтов и новых гипотез, которые приведут к кратному росту. Укажите результат эксперимента, суммировав ответы участников команды роста на вопрос: «Что стало понятно, что раньше было неочевидно?».

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

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

В Movavi Growth Team состояла из четырёх участников.

Growth Master: отвечает за процессы команды роста. Организовывает и ведёт события (Growth Meeting, Daily Meeting и так далее), сортировку гипотез, следит за правильной формулировкой гипотез, фасилитирует команду, актуализирует Experiment Board.

Product Owner: специализируется на генерации гипотез активации, дохода, ценности, метрике «полярной звезды», занимается проблемами онбординга и идентификацией aha-момента. Переносит гипотезу в бэклог разработки, отслеживает исполнение.

Growth-маркетолог: специализируется на гипотезах информирования (привлекает трафик и тестирует различные заголовки и каналы), гипотезах ценности, гипотезах привлечения (скачивание и установка).

Growth-аналитик: отвечает за аналитику на сайте и в продукте, измеряет результаты экспериментов, проводит исследования в аналитике, создаёт общий дашборд с ключевыми метриками для всех.

И я, временный Growth Master, который должен настроить процессы и передать их Growth Master команды.

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

• Мало гипотез содержали ожидаемый эффект от внедрения. Например, «Поменяем шаг в онбординге» или «Сделать A/B-тест заголовка на сайте», однако какой ожидаемый эффект это принесёт, было очевидно далеко не всем. А если команда не понимает эффекта, то как ей голосовать за неё?

Решение: жёстко прописывать ожидаемый эффект прямо в тексте карточки. Например: «Если поменяем шаг в онбординге, то увеличим конверсию в первое конвертированное видео на 2% для первой сессии».

• Как только представили ожидаемый эффект в показателях, у команды появились вопросы, на чём основан этот оптимизм. Автор гипотезы судорожно лез в аналитику, искал сколько отваливалось на этом этапе, сколько их всего — и так далее. Даже если он уже делал исследование, тяжело было рассказать это команде по памяти. Это крало много времени у всей команды, начинались споры, переписывались старые гипотезы, возникали новые, команда уставала, но так и не приближалась к запуску спринта.

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

• Ещё команда много спорила, как именно это должно выглядеть. Какие конкретно надписи должны быть на этом шаге онбординга, будет одна или две кнопки. Это снова съедало время команды, но видение реализации гипотезы было у каждого разное, и каждый должен был голосовать за своё понимание гипотезы.

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

• Многие из них оказались ничейными. Команда когда-то придумала её в споре, записала, но что именно имелось в виду, каждый понимает по-своему.

Решение: каждая гипотеза должна иметь автора, и он ответственен за правильную формулировку, что для неё создан скетч, прикреплены аналитические данные. Именно автор пытается продать гипотезу команде на Growth Meeting.

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

Итак, хорошая гипотеза отвечает на все четыре вопроса:

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

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

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

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

• Участники команды роста всегда приходят на Growth Meeting с уже правильно сформулированными, подготовленными гипотезами.
• Каждая гипотеза является результатом индивидуальной работы, а не порождением коллективного разума. Каждая гипотеза принадлежит определённому сотруднику. Именно в индивидуальной работе над гипотезами заключается главный секрет успеха любой команды роста.
• Команда роста ни в коем случае не занимается коллективной генерацией гипотез во время Growth Meeting.
• Автор гипотезы должен прикрепить подкрепляющую успех гипотезы аналитику и предоставить скетч, на котором будет наглядно продемонстрировано возможное изменение в продукте. Хотите добавить кнопку? Нарисуйте, чтобы всем было понятно, как это будет выглядеть, и не тратьте время на объяснения на пальцах.

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

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

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

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

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

После обсуждения гипотез у нас осталось предостаточно времени на их приоритизацию. Команда голосовала за каждую по методологии ICE Score.

ICE Score предполагает оценку каждой из гипотез с использованием трёх коэффициентов:

• Impact — влияние на метрику;
• Confidence — степень уверенности оценивающего в успехе (обычно эта уверенность базируется на результатах уже проведённых похожих экспериментов);
• Ease — лёгкость внедрения.

По каждому из критериев проставляется оценка от одного до десяти. Затем результаты по каждой гипотезе перемножаются в следующем порядке: Impact x Confidence x Easy = ICE Score.

После приоритизации шесть гипотез удалось запустить в работу. Гипотезы, которые обсуждали на втором Growth Meeting, распределились следующим образом:

• три гипотезы активации пользователя;
• две гипотезы информирования;
• одна гипотеза привлечения на сайт (A/B-тест).

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

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

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

Качество гипотез — это качество топлива, на котором едет вся Growth Team.

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

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

С одной стороны, увеличилось количество целевых действий пользователя — добавление видео. С другой — произведённое изменение отрицательно сказалось на доходе (revenue). А ведь раньше наблюдалась прямая зависимость: чем больше добавляют видео, тем больше платят.

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

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

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

Для каждого эксперимента вне зависимости, завершился ли он успехом или провалился, Growth Master задавал каждому члену команды роста одни и те же вопросы.

1. Что стало понятно, что раньше было неочевидно? (После этого Growth Master заносил сумму ответов в карточку гипотезы.)
2. Исходя из этого инсайда, какой шаг должен быть следующим? (Ответ на этот вопрос заносился в бэклог — список идей в Growth Hacking Board.)
   

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

На четвёртой встрече нам осталось добавить последний блок в наш Growth Meeting, чтобы завершить создание машины по перемалыванию гипотез. Этим блоком была «ретроспектива спринта», которая шла сразу после обзора гипотез.

Growth Master задавал участникам команды следующие вопросы:

• Что шло хорошо в этом спринте?

• Какие улучшения заметили по сравнению с предыдущим спринтом?
  

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

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

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