Бюджет и время на идеи, которые в 80% случаев провалятся: как мы организовали гроуз-хакинг

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

Гроуз-хакинг (growth hacking) помогает искать способы роста через быстрые и недорогие эксперименты. Находим проблему, формулируем гипотезу, проверяем её с ограниченными затратами в ограниченные сроки и решаем, стоит ли применять решение шире. Искать можно по всему пути клиента, включая обработку заявки, повторную покупку и рекомендации. Иногда неочевидные идеи приходят из старых аналитических данных, которые копились несколько лет и зря занимали несколько гигабайт на серверах.

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

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

Чем это отличается от обычной работы

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

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

• 10-20% бюджета на проверку гипотез;

• не более 10% рабочего времени сотрудника на проверку гипотез;

• гипотезы согласовывает только команда гроуз-хакинга;

• неудачная гипотеза это не неудача;

• скорость проверки гипотез важнее качества;

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

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

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

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

Одна метрика на квартал

На каждый квартал мы выбирали OMTM (One Metric That Matters), одну общую метрику, важную для бизнеса именно в этот период. В фокус могли попасть NPS нулевого этапа, скорость перезвона, стоимость квалифицированного лида или конверсия во встречу. От неё отталкивались при выборе гипотез: какую проблему решаем и как поймём, что стало лучше. У всей команды был общий ориентир, поэтому дизайнер, аналитик и CRM-специалист могли работать над разными проверками, которые влияют на один результат.

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

Где искать гипотезы

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

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

Из этого можно сделать гипотезу: показать нужную информацию и дать выбрать время для разговора. Дальше её надо проверить. Наше сочувствие покупателю само по себе ничего не доказывает.

Примеры проверок в девелопменте

Креативы. Сравниваем два подхода к одному предложению для одного сегмента: изображение двора и объяснение ежемесячного платежа. Или, наоборот, один и тот же посыл на разные сегменты. Смотрим, какой вариант даёт больше квалифицированных обращений при сопоставимых условиях. Одного дешёвого клика недостаточно. И не забываем про долгий цикл принятия решения в недвижимости.

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

CRM. Проверяем SMS с напоминанием о встрече: разный tone of voice, время отправки, способ перенести встречу и т. п. Сравниваем долю состоявшихся визитов с текущим сценарием, учитываем стоимость отправки и жалобы.

Формы. Убираем необязательные поля или сокращаем шаги. Проверяем качество полученных обращений: менеджерам потом с ними работать.

Персонализация. Посетителю, который смотрел трёхкомнатные квартиры, при следующем визите предлагаем подходящие планировки. Сравниваем с общей страницей и не объявляем любое изменение улучшением.

Для поиска идей мы разбирали фреймворки. AARRR помогает увидеть этапы пути клиента, JTBD нужен для разбора задачи покупателя, а с помощью «Пяти почему» ищем причину проблемы. Метод выбираем под задачу. Коллекцию аббревиатур можно собрать и без единой полезной гипотезы.

Деньги и скорость

На гипотезы мы выделяли 10% бюджета. Это позволяло проверять идеи с неопределённым результатом и при этом держать затраты в рамках. Успешные решения масштабировали и передавали в постоянную работу. Десять процентов были нашим решением. Другой компании понадобится свой расчёт.

Перед запуском фиксируем предполагаемый эффект, аудиторию, метрику, способ сравнения, срок и ответственного. Отдельно договариваемся, что нельзя ухудшить: например, качество заявок или нагрузку на менеджеров и колл-центр. Приоритет отдаём проверкам с понятным основанием, заметной возможной пользой и посильной стоимостью. ICE и RICE помогают выстроить очередь, но балл команды ещё не доказывает, что идея правильная.

Формулировка гипотезы должна объяснять ожидаемую связь. Например: «Если после записи на просмотр отправить клиенту карту проезда и предложить подтвердить время, доля состоявшихся встреч вырастет, потому что ему будет проще спланировать визит». С модным предложением «давайте сделаем Telegram-бота с ИИ» ещё предстоит разобраться: какую проблему он решает и почему должен помочь.

Важно быстро сделать MVP, минимальную версию для проверки. Для теста напоминаний иногда достаточно вручную отправить сообщения части подходящих клиентов, соблюдая их согласие на коммуникацию. Бота с личным кабинетом можно разработать после того, как польза подтвердится. При этом проверяемая функция должна работать: неисправная форма мало расскажет о спросе.

Для быстрых тестов мы внедрили Amplitude. Событийная аналитика позволяет смотреть действия пользователей и потери между шагами воронки. Но события надо настроить, данные проверить, а тесту дать время. Быстрая разработка не делает маленькую выборку убедительнее.

Как работала команда

Участник мог проверить гипотезу сам, а мог предложить мини-команду. Результат совместной гипотезы в KPI делился между участниками группы. Одна проверка не превращалась в пять полноценных достижений, если над ней работали пятеро. Так мы уменьшали соблазн раздувать состав. При этом экономить на нужном специалисте ради личного показателя тоже было бы странно.

У эксперимента должен оставаться один владелец, который доведёт его до вывода. Команде нужны доступ к данным, выделенное время и возможность запустить проверку. Иначе любая скорость упрётся в ответ разработки «вернёмся к этому в следующем квартале».

Мы встречались раз в неделю на час. Полчаса обсуждали идеи, текущие проверки и препятствия. Ещё полчаса изучали фреймворки и кейсы крупных компаний: разбирали механизм, условия успеха и возможность применить это у себя.

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

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

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

По моей оценке, примерно 20% первоначального состава удержались в этом режиме и стабильно выполняли KPI, не выгорев и не выйдя из команды. Это не делает остальных плохими специалистами. Самостоятельный поиск и проверка решений требуют другой нагрузки. Руководителю здесь полезно проверить и организацию работы: достаточно ли у людей времени, помощи и поддержки непосредственных начальников.

Как оценивать результат

В нашей KPI-модели ориентиром было 12 гипотез за квартал. Количество задаёт ритм, но вместе с ним надо оценивать качество проверок, эффект и внедрение успешных решений. Если платить только за число тестов, команда научится делать много мелких тестов.

Для KPI не имело значения, удачная гипотеза или нет.

Неудачная гипотеза это не ошибка, а доказанный на цифрах факт, куда идти не надо.

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

Смотрим, сколько времени проходит от идеи до вывода, по каким экспериментам можно принять решение и что изменилось в бизнесе. Дополнительные продажи, экономию или вклад в прибыль считаем с учётом расходов на проверку и внедрение.

Условный пример: конверсия выросла с 2% до 2,4%. Это прибавка 0,4 процентного пункта, или 20% относительно исходного уровня. На 10 тысячах сопоставимых посещений получим 40 дополнительных заявок. До дополнительных продаж им ещё предстоит дойти. Если обращения хуже квалифицируются или требуют больших скидок, оценка результата изменится.

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

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

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

Кому это подойдёт

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

Но! Если заявки теряются, данные ненадёжны, а продукт не выполняет обещанное, сначала восстанавливаем основу.

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

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