Запуск 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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