Growth Marketing - как бизнесу вижить в период неопределенности
Делюсь опытом, как продуктовая команда справляется с вызовами и продолжает расти, тестируя 15-20 гипотез в неделю.
Цель статьи - показать как может работать команда роста (Growth Team) без привлечения внешних ресурсов. Какие этапы мы проходили и какие ошибки допускали.
В данной истории показывается опыт продуктовой команды из 30 человек.
Мы не придумывали ничего нового, но адаптировали под себя существующее решение — GROWTH HACKING the ultimate guide
Формируем команду роста
Первая задача: сформировать команду роста, которая будет ориентирована на проведение экспериментов по всей AAARRR воронке.
Команда роста фокусируется на экспериментах, которые могут дать кратный рост.
При этом главной целью всех экспериментов команды остается поиск новых возможностей, а не их масштабирование, например, через performance marketing.
Состав команды:
Первая команда состояла из 4 человек: Head of Digital, CPO, CEO и аналитик.
В нашем случае оказалось, что Head of Digital - лучший кандидат, чтобы возглавить команду роста.

Почему?

Это связано с этапами воронки, за которые отвечает команда маркетинга: awareness, acquisition, retention, referral. Гипотезы по этим метрикам можно очень быстро тестировать.
Приведу примеры:

Этапы Awareness и Acquisition находятся за пределами продукта и связаны с работой с внешними инструментами (соц.сети, лендинги, квизы, боты в мессенджерах, рекламные кабинеты и.т.д).
Этап Retention - зона ответственности CRM маркетолога. Все push-уведомления, email, sms настраиваются на внешних платформах.
Этап Referral связан с реферальной программой. Это может быть как привлечение вебмастеров, так и шеринг ссылкой с друзьями за возможность получить бонусы внутри продукта. В нашем случае это также относится к зоне ответственности команды маркетинга.

А что с продуктовыми этапами воронки? Нужно принять факт, что делать правки внутри продукта всегда сложнее. Знаю историю, когда добавление дополнительного поля в форму регистрации заняло полтора месяца. И это не прихоть CPO, а необходимость, потому что у продуктов есть релизы. И если какая-то фича готова, то ее не запускают в прод без полноценного QA, проверок на деве, повторных правок и.т.д .

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

Идея ≠ Гипотеза

ФОРМУЛА гипотезы:
Действие [X] позволит улучшить метрику [Y] на величину [Z], потому что [N]
Пример идеи:
ИИ саппорт для ответа на базовые вопросы пользователей. В нашем FAQ достаточно статей, которые покрывают все стандартные вопросы пользователей. Есть платформа chatsimple.ai , куда можно скормить наш FAQ и провести быстрый тест, заменив Freshcat на их решение (замена кода).
Идея превращена в гипотезу:
Внедрение ИИ саппорта позволит сократить среднюю скорость ответа с 5 минут до 10 секунд за счет моментальных ответов на базовые вопросы, которые составляют 94% от всех обращений.

Все идеи попадают на доску в Miro, где они трансформируются в гипотезы, приоритизируются и затем уходят в работу.
Эксперты по Growth Hacking говорили: внедрите в команду мышление, основанное на гипотезах.
На деле это оказалось сложной задачей - для начала нужно, чтобы все отделы начали делиться с вами идеями.
В какой-то момент мы пришли к выводу, что перекладывать работу по формированию гипотез на сотрудников команды, которые не находятся в команде роста- плохая идея.
Формирование гипотез трудоемкий процесс, а поделиться идеями и болями можно за несколько минут.
Коллеги будут делиться проблемами, если вы убедите их, что с их проблемами вы будете работать. Но если вы будете требовать от них приносить готовые гипотезы, то это будет выглядеть, что уже вы перекладываете на них свои проблемы.
Возможно, они будут осознавать важность вашей работы, но так ли это важно, если вы добавляете им дополнительной работы?
Повышаем качество гипотез
Есть два способа:
1.Формирование гипотез по конкретной формуле;
2.Приоритизация гипотез по конкретной формуле

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

Есть несколько формул, но из-за простоты мы выбрали следующую:

I.С.E. Score = I + C + E

где:
I — Impact on Metric - влияние на деньги;
C — Confidence - вера в критерий успеха гипотезы;
E —Easy - насколько легко реализовать гипотезу (например, 10 баллов, если делать изменение по гипотезе менее получаса).

Каждый участник команды роста выставляет баллы от 1 до 10 для каждой гипотезы. Growth-мастер суммирует баллы и берет среднеарифметическое.
Приоритизация гипотез происходит раз в 2 недели на Growth Meeting (об этом событии в следующем разделе)
Делаем работу команды устойчивой через Growth Scrum
Внутри Growth команды встала задача выстроить процессы - изначально мы работали по HADI-циклам и по пиратским-метрикам (AARRR). В последний год мы перешли к фреймворку, который содержит все выше указанное - Growth Scrum.
Ключевое событие Growth Scrum - Growth Meeting.
Мы научились проводить Growth meetings, а вместе с этим увеличили количество еженедельных экспериментов.

Growth meetings состоит из 5 событий:
1. Обзор метрик
2. Обзор спринта
3. Ретроспектива спринта
4. Презентация гипотез
5. Приоритизация гипотез

Обсуждение первых трех событий происходит с разбором доски в Miro:
Для презентации и приоритизации гипотез также используется доска в Miro:
Growth Meeting - это главная встреча команды роста, которая определяет, какие эксперименты будут проводиться во время спринта. По результатам Growth Meeting команда роста должна получить приоритезированный список гипотез для внедрения и план изменений в команде, инфраструктуре или правилах, нацеленный на совершенствование процесса экспериментирования и увеличение количества инсайтов.

Делимся результатами экспериментов с командой
Результатами всех протестированных гипотез мы делимся в канале в Slack.

Чаще всего сообщение включает в себя:
— Название эксперимента;
— Результаты (цифры, которые достигли по метрикам)
— Что узнали (знания о поведении пользователей и их реакции на эксперимент)
— Что дальше (продолжать или не продолжать эксперимент, его вариации, какие другие эксперименты мы запустим, используя инсайты из этого эксперимента )
— Подробнее об эксперименте (ссылка на страницу эксперимента в Notion/Confluence, и ссылки на дашборды по эксперименту)
Подводим итоги
Это один из примеров того, как может быть сформирована команда роста. При наличии ресурсов она может быть больше: всегда можно добавить JTBD и UX-исследователей, а также дополнительно усилить команду кем-то из разработки.

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


e-mail us: hello@getromi.com