В одной компании Growth Hacking измеряли числом тестов. Каждый месяц PM отчитывался запущенными A/B-тестами, к концу года их набралось несколько десятков, а метрики роста стояли на месте. Руководство разочаровалось в подходе целиком.
Такой исход типичен: Growth Hacking часто сводится к набору разрозненных экспериментов, которые не связаны между собой и не дают устойчивому росту накопиться.
Причина почти всегда в порядке действий. Команды начинают с тактик: запускают тесты, меняют кнопки, пробуют каналы. На простой вопрос, почему именно эти действия должны дать рост, ответа нет. Энергия тратится, накопленного эффекта не появляется, и каждый следующий эксперимент начинается почти с нуля.
Внедрить Growth Hacking значит поменять то, как команда принимает решения, и приучить её учиться на каждом тесте. Отдельная роль и новые инструменты этого не заменят. Чаще всего дело застревает в двух местах. Первое: сбои в самой системе, которых команда может не замечать. Второе: ошибки PM, которые эти сбои прячут.
Рост зависит от системы сильнее, чем от PM
Когда рост не случается, команда ищет персонального виноватого. Чаще всего им становится PM, особенно если Growth в его зоне ответственности. Конструкция удобная и опасная: она снимает ответственность с системы.
PM может быть слабым. Но гораздо чаще он работает в среде, где рост невозможен по определению. Целей нет, метрики противоречат друг другу, приоритеты меняются каждую неделю, а эксперимент требует согласований на месяц.
Рядом живёт вторая иллюзия: будто PM должен приносить идеи роста. Идеи как раз самый дешёвый элемент Growth Hacking. Ценность создаётся в проверке гипотез и извлечении знаний. Если от человека ждут вдохновения вместо управления процессом, рост будет случайным.
Поэтому внедрение начинается с разбора контуров, в которых люди работают. Оценка самих людей подождёт.
Где ломается контур роста
Когда роста нет, обычно сломано управление. Цели звучат абстрактно. Стратегию не перевели в цифры, которые можно измерить. О росте говорят, но не отвечают, за счёт чего он случится. Ломается всё в трёх местах, и первое во многом определяет два других.
Первая точка: нет единой модели роста. Команда не понимает, какое действие пользователя важнее всего и какие рычаги на него влияют. Поэтому маркетинг, продукт и разработка тянут в разные стороны, и PM не может их синхронизировать. Маркетинг тянет к регистрациям, продукт к фичам, аналитика к аккуратным отчётам. Ни один вектор не совпадает с ростом бизнеса.
Вторая точка лежит в интерфейсах между функциями. Growth требует быстрой итерации. Если аналитика подключается постфактум, а разработка живёт двухмесячными циклами, эксперименты дорожают, и PM торгуется за каждое изменение.
Третья точка: незамкнутая обратная связь. Результаты экспериментов не превращаются в решения, и даже успешные тесты не масштабируются.
Корень у трёх поломок общий: рост нигде не описан как механизм. Модель при этом проще, чем кажется. Ей достаточно одного ключевого действия пользователя, сильнее всего связанного с деньгами и удержанием, и короткой цепочки рычагов. Для сервиса учёта это может быть «добавил первые 10 операций за неделю», для маркетплейса «сделал второй заказ в течение 30 дней». Как только модель записана, спор о приоритете эксперимента перестаёт быть вопросом вкуса. Гипотезу оценивают по тому, двигает ли она ключевое действие и насколько дёшево это проверить.
Почему тесты кнопок не двигают метрики
У истории из начала есть арифметическое объяснение. Цифры ниже придуманы, но порядок величин типичен.
Допустим, в продукт приходит 6 000 новых пользователей в неделю, активация 25%. Чтобы надёжно заметить рост активации на 3 процентных пункта, нужно около 3 300 пользователей на вариант. Это считается по стандартной формуле: 16 × 0,25 × 0,75 / 0,03². Всего 6 700 человек, чуть больше недели трафика. Такой тест команда может себе позволить.
Теперь тест цвета кнопки. Её реальный эффект, скорее всего, около 0,5 пункта. Эффект в шесть раз меньше, значит, людей нужно примерно в 36 раз больше: около 120 000 на вариант, то есть 40 недель трафика. А тест заканчивают через две недели с выводом «разницы нет». Повторите это 30 раз, и получится ровно та картина: тестов много, метрики стоят.
Вывод для приоритизации прямой. На вашем трафике есть минимальный эффект, который вы в принципе способны увидеть. Гипотезы, которые не обещают такого эффекта, проверять тестом бессмысленно. Их либо объединяют в одно крупное изменение, либо внедряют без теста, если они дёшевы и обратимы.
Есть и второй фактор. Изменения интерфейса часто дают эффект новизны: первые дни люди нажимают на новое просто потому, что оно новое, а через несколько недель привыкают и возвращаются к прежним маршрутам. Короткая метрика при этом может ошибаться в обе стороны. Двухнедельный «выигрыш» кнопки нередко растворяется к концу квартала.
Порог видимого эффекта можно опустить и без нового трафика. Для этого метрику каждого пользователя корректируют на её значение до эксперимента: если человек и раньше заходил пять раз в неделю, важен сдвиг относительно его собственной нормы. Для вернувшихся пользователей со стабильным поведением это сужает разброс, и тест заканчивается быстрее. Для новичков истории нет, поэтому на онбординге метод почти ничего не даёт: там выручают только трафик и крупные изменения.
Какие ошибки в экспериментах нормальны
Модель роста подсказывает, что проверять, но не обещает, что проверка подтвердит ожидания. Поэтому при внедрении первым делом договариваются о норме ошибок.
Ошибка гипотезы нормальна. Если команда корректно сформулировала предположение, выбрала метрику и получила отрицательный результат, у неё на руках информация. Пространство поиска сузилось, следующая гипотеза будет точнее. Если из пяти гипотез подтверждается одна, это обычная доля для продукта, который ищет рост, и считать остальные четыре провалом нельзя.
Нормальны и ошибки в выборе метрик на ранних этапах. Команды часто начинают измерять то, что легко посчитать. Право пересматривать метрики входит в само обучение.
Ошибки процесса относятся к другому классу. Гипотезы не записаны, критериев успеха нет, выводы не документируются. Такие ошибки ничему не учат, и их нужно останавливать. Разница видна в экономике: отрицательный результат честного эксперимента окупается знанием, а эксперимент без гипотезы оборачивается расходом впустую, потому что даже из удачного исхода нечего вынести.
Когда промах становится некомпетентностью
Граница между нормальной ошибкой и некомпетентностью проходит по повторяемости. Если команда раз за разом наступает на одни и те же грабли и не делает выводов, проблема уже не в гипотезах.
Первый маркер: Growth-инициативы оторваны от бизнес-целей. Эксперименты существуют сами по себе, их результаты не влияют на стратегию, и рост, даже если случается, остаётся случайным.
Второй маркер тоньше. Данные используют для подтверждения заранее принятого решения. Growth Hacking теряет научную основу и превращается в политику.
Этот переход слышно в речи раньше, чем он виден в цифрах. «Давайте просто попробуем» почти всегда означает, что гипотезы нет. «Это срочно, потому что конкуренты сделали» подменяет анализ ценности страхом. «Данные потом посмотрим» прямо говорит, что метрики не входят в процесс. Распознавать такие фразы команда учится только там, где есть культура обратной связи и прозрачные критерии качества работы.
Хаос в исследованиях, поставке и коммуникации
Сломанный контур оставляет следы на каждом этапе цикла. На этапе исследований хаос заметен быстрее всего. Команда не разговаривает с пользователями или делает это формально, и гипотезы строятся на внутренних догадках.
Часто нет и внятной формулировки проблемы. Вместо вопроса «почему пользователь не доходит до ценности» обсуждают «как увеличить конверсию». Причину подменяют следствием, и эксперименты получаются поверхностными.
В поставке тот же хаос выглядит как перегруженные бэклоги и длинные циклы. Запуск простого теста занимает недели. Эксперименты оформляют как полноценные фичи, они дорожают, команда становится осторожной и оптимизирует мелочи. Стандартов нет, поэтому сравнивать результаты почти невозможно.
Хороший ориентир для поставки: путь от записанной гипотезы до запущенного теста не дольше 10 рабочих дней. Если он занимает 30, за квартал команда проверит две-три гипотезы, и при доле подтверждений один к пяти может не найти ни одной рабочей.
В коммуникации всё упирается в отсутствие общего языка. Маркетинг говорит о каналах, продукт о фичах, аналитика об отчётах. Самый опасный сигнал подаёт защитная реакция: вопросы о результатах воспринимают как атаку, и обучение прекращается.
Каждый из трёх сбоев проверяется за полчаса. Для исследований откройте последние 10 гипотез и посмотрите, сколько из них ссылаются на интервью, запись сессии или данные о поведении. Если меньше трёх, гипотезы рождаются на внутренних догадках. Для поставки посчитайте медианное число дней от записи гипотезы до запуска теста за последний квартал. Для коммуникации спросите трёх людей из разных функций, какие эксперименты идут сейчас. Если ответы не совпадают, общей картины у команды нет, и первым шагом станет еженедельный разбор на 30 минут.
Ошибки PM, из-за которых движение есть, а вектора нет
Системные сбои не снимают ответственности с PM. Внутри сломанного контура его ошибки делают картину хуже, и собираются они в трёх местах.
Первое касается логики роста. PM не может объяснить, какое поведение пользователя приводит к росту, поэтому эксперименты не усиливают друг друга. Гипотезы подменяются готовыми задачами, обсуждение сразу уходит в реализацию.
Второе связано с экономикой эксперимента. Стоимость проверки не учитывают, тесты становятся тяжёлыми, и команда боится ошибаться. Приоритизации нет, метрики обсуждают после релиза, выводы не записывают. Через полгода те же гипотезы проверяют заново.
Третье относится к культуре. PM воспринимает вопросы о результатах как личную критику, смотрит только на цифры без контекста поведения и лечит симптомы. Иллюзия полного контроля заставляет его скрывать неопределённость, хотя управлять ею было бы полезнее.
Три артефакта воспроизводимого роста
Против этих сбоев работает короткий набор из трёх артефактов. Первый: бэклог гипотез, где каждая инициатива описана через проблему, предположение, метрику и критерий успеха. Второй: журнал экспериментов, где фиксируют выводы вместе с результатами. Третий: несколько общих метрик, которые отражают ценность для бизнеса и пользователя.
Работают они только вместе, как один цикл. Бэклог говорит, что проверяем и как поймём, что получилось. Общие метрики помогают прочитать результат. Журнал сохраняет вывод и возвращает его в бэклог в виде следующей, более точной гипотезы.
Уберите любой из трёх, и цикл рвётся. Без критериев спорят о том, был ли эффект. Без общих метрик каждая функция меряет своё. Без журнала команда теряет память и проверяет уже отвергнутое.
Минимальный формат записи в журнале помещается в пять строк: гипотеза, метрика и критерий успеха, размер выборки и сроки, результат с доверительным интервалом, решение. Последняя строка обязательна. Если решение не записано, эксперимент не закончен.
Порядок в бэклоге задаёт простая оценка ожидаемой ценности. Перемножьте вероятность, что гипотеза верна, ожидаемый эффект и долю пользователей, которых она затрагивает, и разделите на стоимость проверки в днях. Например:
- Гипотеза А: новый первый экран онбординга. Вероятность 30%, эффект +4 пункта активации, затрагивает всех новичков, проверка 8 дней. Оценка: 0,3 × 4 × 1,0 / 8 = 0,15.
- Гипотеза Б: подсказки в разделе отчётов. Вероятность 50%, эффект +2 пункта удержания, затрагивает 20% пользователей, проверка 5 дней. Оценка: 0,5 × 2 × 0,2 / 5 = 0,04.
- Гипотеза В: перекраска кнопки оплаты. Вероятность 40%, эффект +0,5 пункта, затрагивает всех, проверка 2 дня. Оценка: 0,4 × 0,5 × 1,0 / 2 = 0,1, но эффект ниже порога, который видит ваш трафик, и в тест она не идёт.
Цифры вероятностей субъективны, и это нормально. Ценность оценки в том, что спор переходит с «моя идея лучше» на конкретные множители, и каждый из них можно оспорить данными. Через квартал журнал покажет, насколько хорошо команда угадывает вероятности, и оценки станут точнее.
Скорость обучения тоже стоит измерять. Метрика: число гипотез в месяц, по которым записано решение. Ограничитель: доля экспериментов, остановленных без вывода. Если она выше 20%, команда запускает больше, чем способна разобрать, и темп пора снижать.
Два разворота: от давления на канал и от разрозненных трюков
Первая команда споткнулась о модель роста, хотя была уверена, что дело в канале. Она вкладывалась в новые каналы привлечения: регистрации росли, активация оставалась низкой, а PM объяснял это качеством трафика и требовал больше бюджета.
После паузы и анализа команда пересобрала путь пользователя до первого ценностного действия. Оказалось, что большинство новичков не понимали, зачем возвращаться в продукт. Родилась гипотеза: нужно сократить время до первого результата. Команда запустила несколько простых экспериментов в онбординге. Часть не дала эффекта, но помогла нащупать барьер: пользователям не хватало контекста, функциональности было достаточно.
На основе этих выводов переписали сценарий первого использования. Без крупных релизов активация выросла, а стоимость привлечения снизилась, потому что канал наконец приводил людей к ценности. Важнее метрик оказался сдвиг в мышлении: команда начала думать гипотезами.
Вторая компания та самая, с которой начинался текст. Growth Hacking там выродился в A/B-тесты интерфейса, и руководство разочаровалось. Команда остановилась, зафиксировала основные метрики и сформулировала логику роста продукта.
Затем появился единый бэклог гипотез, привязанных к этапам воронки. Эксперименты стали реже, но осмысленнее, выводы документировались, и слабые идеи отсекались быстрее. Через несколько месяцев рост стал предсказуемее. По сути, команда собрала три артефакта в правильном порядке: сначала метрики и модель, потом бэклог, потом журнал выводов.
Когда дисциплина экспериментов только мешает
Для молодого продукта вся эта система может оказаться избыточной. У продукта 300 новых пользователей в неделю, и тест на 3 пункта активации займёт больше пяти месяцев. Бэклог гипотез с критериями превращается в бюрократию, а основатель, который лично обзвонил 20 клиентов, узнаёт за неделю больше, чем журнал экспериментов за квартал.
Тут с этим трудно спорить. Если трафика меньше примерно 1 000 новых пользователей в неделю, A/B-тесты стоит оставить для крупных изменений. Остальное проверяют интервью, ручной работой с первыми клиентами и сравнением «до и после» с записанным ожиданием.
Но журнал гипотез нужен и здесь. Он единственное, что не даёт команде из пяти человек через полгода забыть, почему от идеи отказались. Ситуация меняется, когда трафика хватает на тесты, а команда продолжает решать «по ощущениям». Тогда интуиция основателя превращается в узкое горлышко роста.
Отдельный случай составляет B2B с небольшим числом крупных клиентов. Если клиентов 80, тест, где пользователей делят на группы случайно, почти всегда смазан: сотрудники одного клиента видят оба варианта и обсуждают их между собой. Честнее делить на группы целые аккаунты и смотреть только на крупные эффекты. Или провести пилот на нескольких клиентах и заранее записать, что будет считаться успехом. Сезонность добавляет свою ловушку: тест, запущенный в декабре в B2B, меряет праздничную просадку активности сильнее, чем саму гипотезу.
Что чаще всего спрашивают про Growth Hacking
С чего начать внедрение Growth Hacking в команде?
С договорённости о том, какое поведение пользователя сильнее всего связано с ростом. Без этого любые эксперименты будут разрозненными.
Затем договоритесь о языке: что такое гипотеза, эксперимент, результат и вывод. Первая неделя на практике выглядит так: записать модель роста на одной странице, собрать в бэклог 15-20 гипотез, оценить их по формуле ожидаемой ценности и запустить одну, самую дешёвую из сильных. Общий словарь снижает число недопониманий. Инструменты и фреймворки идут после этого.
Нужно ли выделять отдельную Growth-команду?
Выделенная команда ускоряет старт, но несёт риск изоляции: Growth становится чужой функцией для остальных.
Распределённая модель, где подход применяют все продуктовые команды, сложнее, но устойчивее. Практичный компромисс: выделенная команда на 6-12 месяцев, чья задача в том, чтобы научить остальных и раздать им процесс.
Как вовлечь разработчиков в Growth Hacking?
Разработчикам важно видеть смысл экспериментов. Когда изменение напрямую связано с поведением пользователей, мотивация растёт.
Критично снижать стоимость тестов: фича-флаги, шаблоны экспериментов, готовые события в аналитике. Чем проще запуск, тем меньше сопротивления. Разговаривать с разработкой лучше на языке проблем пользователя.
Как связать Growth Hacking и стратегию продукта?
Эксперименты должны проверять стратегические предположения. Тогда Growth становится инструментом реализации стратегии.
Если стратегия не записана явно, Growth будет реактивным. Раз в квартал сверяйте бэклог гипотез со стратегией и убирайте то, что к ней не относится.
Что делать, если руководство ждёт быстрых результатов?
Договориться об ожиданиях заранее. Growth Hacking не гарантирует рост. Полезный вывод появляется, если эксперимент проверяет конкретное предположение и данные позволяют отличить эффект от шума.
Покажите руководству арифметику размера выборки: она объясняет сроки лучше любых обещаний. Первые результаты часто выражаются в понимании, и это нужно проговаривать.
Можно ли внедрить Growth Hacking в большой компании?
Можно, но сложнее. Мешают инерция процессов и длинные циклы принятия решений.
Начинать стоит с пилотной команды, потому что успешный кейс легче масштабировать, чем теорию. Хороший выбор для пилота: продукт с трафиком на тесты и руководителем, готовым публично разбирать неудачные эксперименты.
Команда, которая не может назвать гипотезу, проверенную на прошлой неделе, и решение по её результату, не обязательно растёт плохо. Трюки у неё есть, часть даже срабатывает, но без одной метрики и заранее заданного критерия никто не скажет, какой дал эффект. Самая дешёвая проверка дисциплины занимает один расчёт: минимальный эффект, который способен увидеть ваш трафик. Гипотезам, которые обещают меньше, в бэклоге тестов не место.