Что команда знает о продукте после теста, который ничего не сдвинул? Чаще всего ничего: гипотезу не записали, порог успеха не задали, разбор свёлся к фразе «не взлетело». Пустых тестов у любой честной команды большинство, поэтому именно здесь решается, куда уходит бюджет роста: в знание или в повторение тех же ошибок через полгода.
Поэтому Growth Hacking не сводится к набору трюков, которые «взрывают» метрики. Трюк не воспроизводится. Воспроизводится процесс: гипотеза, проверка, записанный вывод. Без связи гипотез с бизнес-результатом рост превращается в дёргание показателей.
Научить команду Growth Hacking значит изменить то, как она принимает решения и как относится к ошибкам. Одним курсом тут не обойтись. Нужен понятный порядок работы, который не разваливается, когда эксперимент провалился.
К тому же рост всегда рождается на стыке продукта, маркетинга, аналитики и разработки. Назначить одного ответственного и ждать результата не выйдет: учиться должна вся команда.
Почему рост нельзя повесить на одного Growth-специалиста
Когда рост не случается, удобно найти персонального виноватого. Эксперименты не взлетают, гипотезы не дают эффекта, метрики стоят, и Growth-специалист становится громоотводом для всех проблем системы. Такое объяснение опасно тем, что упрощает реальность: рост почти никогда не ломается из-за одного человека.
Чаще всего от специалиста ждут результата, не давая контекста, полномочий и инфраструктуры для экспериментов. В ответ он начинает имитировать активность.
Другая версия той же ошибки: ждать от него «идей роста». В зрелых командах рост не держится на вдохновении отдельных людей; он строится на системной работе с воронками, сегментами и ограничениями продукта. Команда, которая ждёт гениальных инсайтов вместо качественного процесса, заранее обрекает себя на нестабильность.
Поэтому обучение начинается с отказа от поиска виноватых: рост надо видеть как функцию системы, в которой отдельная роль остаётся лишь одним из элементов.
Где ломается рост
Если Growth не работает, дело почти всегда в том, как устроено управление. И ломается оно обычно в одном из трёх мест.
Первое место: стратегия. Компания говорит о росте, но не может ответить, что должны делать пользователи, чтобы он случился. Без ясной главной метрики (North Star) Growth Hacking распадается на мелкие улучшения, которые не складываются в общий результат. Одна команда двигает регистрации, другая открытия экрана, и ни одно из этих чисел не связано с деньгами.
Второе место: связь между отделами. Росту нужна быстрая реализация. Если разработка живёт в своём мире, а аналитиков зовут, когда всё уже сделано, каждый эксперимент становится дорогим и медленным. За любое изменение приходится торговаться, и команда учится всё медленнее.
Третье место тише, но опаснее: выводы. Если результаты экспериментов не превращаются в знание, команда не растёт. Метрики в Growth Hacking вторичны, главное в нём учёба. Когда выводы не записывают, одни и те же ошибки повторяются, а желание работать пропадает.
Какая ошибка учит, а какая нет
Обучение росту невозможно без нормализации ошибок: эксперимент по определению предполагает неопределённость, и часть гипотез не сработает. Важно заранее договориться, где проходит граница допустимого.
Ошибка гипотезы допустима. Если команда сформулировала предположение, корректно его проверила и получила отрицательный результат, она вложилась в понимание продукта и пользователя, и такие ошибки стоит поощрять. Допустимы и ошибки в измерениях на раннем этапе: идеальные метрики редко находят сразу, и команде нужно позволить уточнять события и улучшать аналитику по ходу.
Недопустимы ошибки дисциплины. Эксперименты без гипотез, незаписанные результаты, выводы, которые не влияют на решения, превращают Growth Hacking в хаос под видом экспериментов.
Граница проходит по процессу. Если команда снова и снова повторяет одни и те же провалы, не извлекая уроков, менять придётся мышление. Тот же диагноз ставят, когда инициативы не привязаны к бизнес-целям (эксперименты ради активности) или когда данными задним числом оправдывают уже принятые решения. Обучая команду, важно научить её отличать честную ошибку от системной некомпетентности, а это требует зрелой культуры обратной связи.
Ошибки дисциплины видны на каждом этапе. Раньше всего на этапе поиска (discovery): команда либо не говорит с пользователями, либо говорит для галочки. Гипотезы роста строятся на догадках команды, а не на том, что реально мешает людям.
Часто и саму проблему формулируют размыто. Вместо "почему пользователь не доходит до пользы продукта" обсуждают "как повысить конверсию". Без понимания причины решения получаются случайными. Сюда же относится смешение поиска и разработки: команда сразу спорит о решениях, не записав, что именно проверяет. Тогда эксперимент теряет главное: из него нечему научиться.
На этапе разработки (delivery) проблемы видны по перегруженным спискам задач и долгим циклам. Если на запуск простого теста уходят недели, быстро учиться не выйдет. Эксперименты нередко делают как полноценные функции.
Цена ошибки от этого растёт, готовность рисковать падает, и команда начинает выбирать «безопасные» гипотезы с минимальным потенциалом. Не хватает и стандартов: каждый тест делается по-своему, результаты несравнимы, знания не накапливаются.
В общении виден разрыв между ролями. Маркетинг говорит о каналах, продукт о функциях, аналитики об отчётах, а общего языка роста нет. К этому добавляется закрытость: команда не знает, какие эксперименты идут и чему они научили. И защитная реакция: вопросы о результатах воспринимают как нападение. В этот момент учёба останавливается.
Гипотеза из четырёх частей и карточка для журнала
Большая часть бесполезных экспериментов начинается с плохо сформулированной гипотезы. Рабочая гипотеза содержит четыре части: проблему (что именно ломается в поведении пользователя), предположение о причине, изменение, которое проверяем, и метрику с заранее заданным критерием успеха. «Добавим подсказку в онбординг» остаётся задачей. «Пользователи не возвращаются, потому что не понимают, зачем; если показать ценность в первые минуты, семидневное удержание вырастет» уже тянет на гипотезу: её можно опровергнуть.
Гипотез всегда больше, чем мощностей, поэтому брать их по порядку нельзя. Проще всего оценивать каждую по ожидаемому эффекту, уверенности в нём и стоимости проверки: дешёвый тест с высоким потенциалом идёт раньше дорогого с сомнительным. Точность оценок тут не главное: важно, чтобы команда перестала распылять усилия на идеи, которые выглядят одинаково важными только потому, что их никто не сравнивал. Метрику выбирают до запуска и вместе с защитной метрикой, показателем, который не должен просесть ради роста основного; иначе легко «улучшить» конверсию, обрушив удержание.
Для очереди хватит формулы ICE: оценка = влияние × уверенность × простота, каждое от 1 до 10. Допустим, подсказка в онбординге получает 6 × 7 × 9 = 378, а переделка тарифов 9 × 4 × 2 = 72. Подсказка идёт в работу первой, хотя потенциал тарифов выше: тарифы проиграли на уверенности и простоте. Это повод сначала дёшево проверить спрос на новый тариф и поднять его уверенность с 4 хотя бы до 7. Баллы субъективны, но разложить идею на три оси уже полезно: спор уходит от «моя идея важнее» к конкретной оси, где мнения расходятся.
Зрелость команды видна по следам работы, и метрики среди них не самый показательный след. Главный след: бэклог гипотез и журнал экспериментов. Карточка в журнале выглядит так:
- Проблема с цифрой: например, 62% зарегистрированных не возвращаются на второй день.
- Причина, как её видит команда.
- Изменение и сегмент, на котором его проверяют.
- Основная метрика и порог: например, удержание на седьмой день (D7) с 18% до 21%.
- Защитная метрика: что не должно просесть, скажем, доля платящих.
- Срок и выборка: сколько дней и пользователей нужно для вывода.
- Вывод и решение, даже если эффекта нет.
Без списка гипотез с такими карточками Growth как дисциплины нет. В журнале хранят и результаты, и выводы. Если команда не может быстро сказать, чему научилась за квартал, знания не копятся и уходят вместе с людьми.
Третий артефакт: единый набор метрик. Когда каждая функция смотрит на свои показатели, рост рассыпается, а зрелые команды договариваются о нескольких ключевых метриках и строят эксперименты вокруг них.
Семь механизмов, на которых буксует обучение
Провалы повторяются. Их можно пересчитать по пальцам:
- Нет явной модели роста. Никто не объяснит, за счёт какого поведения продукт растёт, и инициативы не усиливают друг друга.
- Гипотезы подменяются задачами. Команда спорит о реализации, не договорившись, что проверяет.
- Игнорируются ограничения системы. Эксперименты планируют без учёта пропускной способности, аналитики и техдолга, и большинство застревает на реализации.
- Метрики смотрят постфактум. Выводы получаются размытыми.
- Выводы не документируются. Через несколько месяцев те же ошибки повторяются.
- Эксперименты оторваны от стратегии. Даже успешные тесты не меняют систему.
- Иллюзия контроля. Продакт делает вид, что всё под контролем, хотя данных мало, вместо того чтобы назвать неопределённость.
Эти механизмы легко услышать в речи. «Давайте просто попробуем и посмотрим» обычно означает отсутствие гипотезы и критериев. За фразой «Нам срочно нужна эта фича, конкуренты уже сделали» стоит решение из страха, без понимания, какое поведение изменится. А «Данные потом посмотрим» прямо говорит, что метрики в принятии решений не участвуют.
Как выглядит переход от давления на каналы к обучению
Возьмём две типичные команды, собранные из знакомых ситуаций. Первая наращивала регистрации через новые маркетинговые каналы. Конверсия оставалась низкой, стоимость привлечения росла, и продакт объяснял это качеством трафика, требуя больше бюджета.
После пересмотра подхода начали с анализа пути пользователя до первого ценностного действия, и увидели, что большинство просто не понимает, зачем возвращаться в продукт после регистрации. Сформулировали гипотезу: сократить время до первого результата. Запустили несколько простых экспериментов с онбордингом, не трогая ядро продукта. Результаты вышли смешанными, но обнажили главный барьер: пользователям не хватало контекста, а не функций.
На этом выводе переработали сценарий первого использования и без крупных релизов подняли активацию, снизив нагрузку на маркетинг. Важнее самого роста оказалась перемена в мышлении: команда стала рассуждать гипотезами и перестала давить на каналы.
У второй команды Growth Hacking сводился к A/B-тестам кнопок. Продакт отчитывался количеством экспериментов, но основные метрики не двигались, и руководство разочаровалось в подходе. Команда остановилась и пересобрала работу: определила ключевые метрики роста, зафиксировала North Star (это дало общий язык) и создала единый бэклог гипотез, привязанных к этапам воронки. Экспериментов стало меньше, зато каждый что-то проверял.
Часть гипотез не дала эффекта, но выводы фиксировали и переиспользовали, и команда начала быстрее отсеивать слабые идеи. Через несколько месяцев рост стал предсказуемее, и объяснялось это налаженным процессом обучения, без всяких магических решений.
Сначала общий язык, потом одна метрика, потом приоритизация
Учёба начинается с языка. Пока команда не договорилась, что считать гипотезой, экспериментом и результатом, никакие методики не приживутся: люди называют одними словами разные вещи. Потом выбирают одну главную метрику и сосредотачиваются на ней. Учить "росту вообще" почти всегда бесполезно: у команды нет общей цели. И только после этого стоит учить, как выбирать гипотезы и как строить эксперименты. Без этой основы они превращаются в ритуал.
Готовность к такому обучению определяется отношением к неопределённости, уровень знаний здесь важен меньше. Если люди готовы признавать, что не знают ответа заранее, это хороший сигнал. К этому нужны две вещи: минимальная аналитическая инфраструктура (без данных обучение опирается на интуицию и повышает конфликтность) и поддержка руководства. Если эксперименты наказывают за неудачу, команда быстро возвращается к безопасным решениям, и обучение останавливается, не начавшись.
Выделенная команда или распределённая модель?
Один из первых организационных вопросов: собирать ли отдельную Growth-команду. Выделенная команда ускоряет старт, но создаёт риск изоляции: рост становится «чужой» функцией, и остальные перестают чувствовать за него ответственность. Распределённая модель, где Growth-подход применяют все, требует больше времени на разгон, но даёт устойчивый эффект. Выбор зависит от размера компании и зрелости процессов, но в любом варианте у роста должен быть владелец, но запирать эту работу в одном отделе нельзя.
В обеих моделях решает разработка. Ей важно показать ценность быстрых экспериментов: когда инженеры видят прямую связь между изменением и поведением пользователей, мотивация растёт, а сопротивление падает. Помогает и дешёвый эксперимент: чем проще запустить тест, тем охотнее команда рискует и тем быстрее учится. С разработкой стоит обсуждать проблему пользователя до того, как показывать готовое решение, иначе инженеры превращаются в исполнителей чужих решений и теряют интерес.
Выгорание в Growth-командах почти всегда связано с постоянным давлением на результат. Смещение фокуса с «роста любой ценой» на обучение снимает часть этого давления: регулярные разборы и признание ценности неудачных экспериментов возвращают работе смысл даже без мгновенного эффекта. Чёткие приоритеты защищают от перегрузки не хуже: команда, которая тянет десять направлений сразу, выгорает быстрее той, что доводит до конца два.
Обучение видно раньше выручки: три индикатора
Метрики роста запаздывают по отношению к обучению, поэтому команду, которая учится, видно раньше, чем это отразится в выручке. Раньше всего заметна скорость, с которой команда отсекает слабые идеи: если слабые гипотезы отбраковываются всё быстрее и спор решают записи в журнале, обучение идёт. Зрелость выдаёт и переиспользование выводов, когда знание из одного эксперимента применяется в новом контексте. Третий индикатор: доля экспериментов с заранее заданными критериями и записанным результатом.
Результат без заметного эффекта полезен, если данные и точность оценки позволяют исключить практически важный выигрыш; иначе тест остаётся неубедительным. Если же эксперименты системно не дают эффекта, стоит сначала пересмотреть формулировку проблем, а тактику уже потом: возможно, команда оптимизирует не тот участок воронки, и лучшим ростом здесь станет отказ от неверного направления.
Индикаторы меняются вместе с продуктом. Growth Hacking не исчезает с ростом продукта: он меняет форму. На ранних этапах он сводится к быстрым дешёвым экспериментам в поиске рычагов, на зрелых к системной оптимизации уже понятных механик. Когда продукт стабилен, рост становится менее заметным, но остаётся в виде постоянного мелкого улучшения. Полный отказ от Growth обычно значит застой: команда перестаёт искать новые пути роста и живёт по инерции.
Нужны ли внешние эксперты? Они ускоряют старт, но внутреннюю работу не заменяют: решает способность команды честно смотреть на свои ошибки, а этому снаружи не научить. Самообучение требует больше терпения, зато даёт понимание собственного контекста, которого у приглашённого консультанта нет.
Вернёмся к тесту из начала, который ничего не сдвинул. В команде, где North Star зафиксирована и ни один эксперимент не стартует без гипотезы и порога успеха, у такого теста есть карточка: что ожидали, что увидели, какую идею теперь можно не проверять. Отрицательный результат разбирают на общей встрече наравне с положительным, и знание остаётся у команды, даже когда автор теста уходит. Приоритизация, журнал и общий язык продукта, маркетинга и разработки вырастают из этой привычки сами. Удачную механику конкурент скопирует за неделю. Скорость, с которой команда отбраковывает слабые гипотезы, так просто не копируется.