Команда роста запускает новый пейволл, и конверсия пробного периода в оплату растёт с 20% до 23%. Тест объявляют победой. Через три месяца продуктовая команда замечает, что новые подписчики уходят заметно быстрее.
Спор о том, чья метрика важнее, занимает следующий квартал. Правы обе команды, каждая в своей картине мира. В этом и проблема: конфликт заложен в устройство компании, а не в людей.
Иметь по отдельности сильную функцию роста и сильный продакт-менеджмент мало. Цифровые компании выигрывают, когда две функции работают как одна система: с общей иерархией метрик, понятными правами принятия решений и единым подходом к экспериментам. Поэтому интерфейс между командами роста и продакт-командами, то есть то, как они договариваются и делят решения, стал одним из главных вопросов устройства компании.
Конфликт роста и продукта заложен в конструкцию
Напряжение между продуктом и ростом обычно объясняют характерами, плохой коммуникацией или борьбой за влияние. Всё это вторично. Функции выросли из разных управленческих традиций. Рост пришёл из рекламы с оплатой за результат (перформанс-маркетинга), привычки всё проверять тестами и воронок, где эффект виден быстро. Продукт вырос из стратегии, UX и инженерной координации, где ценность копится годами.
Отсюда четыре причины трения, и каждая встречается даже в сильных компаниях.
Первая: пересечение зон. Активация относится к росту или к продукту? Онбординг входит в основной опыт или в воронку? Пейволл принадлежит монетизации, UX или механике роста? Пока организация не ответит на эти вопросы явно, одни и те же споры возвращаются каждый квартал.
Вторая: разные горизонты. Продакт-менеджер думает о том, как продукт помогает пользователю и сохраняет доверие на годы вперёд. Команда роста думает о рычагах: где пользователь застревает, какой тест даст прирост, что ускорить в онбординге.
Третья: эксперимент против предсказуемости. Каждый тест вмешивается в путь пользователя, кодовую базу, аналитику и иногда в бизнес-модель. Без заранее заданных границ скорость экспериментов выглядит угрозой стабильности, а защита стабильности выглядит тормозом.
Четвёртая: раздельная аналитика. Рост смотрит на CAC, активацию, прирост и срок окупаемости. Продукт смотрит на North Star Metric, принятие ключевых сценариев и время до первой ценности. Когда эти показатели живут в разных дашбордах, команды видят разную картину, и хорошие решения начинают мешать друг другу.
Чем сильнее продукт зависит от данных, персонализации и быстрых итераций, тем острее противоречие. Вынести рост «за пределы продукта» уже не получится: он живёт внутри онбординга, монетизации и привычек пользователя. Продукт, в свою очередь, не может считать окупаемость или ARPU чужой территорией. Способ совместной работы приходится проектировать так же тщательно, как сам продукт.
То, что команды не умеют работать вместе, видно по повторяющимся симптомам, и у каждого есть быстрая проверка:
- Один и тот же спор о границах всплывает на планировании третий квартал подряд. Проверка: найдите в протоколах встреч решения по онбордингу или пейволлу за полгода и посмотрите, кто их принимал. Если каждый раз разные люди, владельца нет.
- Результаты тестов оспаривают после окончания. Проверка: посчитайте, у скольких из последних десяти экспериментов критерий успеха был записан до запуска. Если меньше чем у половины, спорить будут всегда.
- Продуктовая команда узнаёт о тесте роста от пользователей или поддержки. Проверка: есть ли общий календарь экспериментов, который видят обе команды.
- Квартальные цели двух команд нельзя сложить в одну цифру. Проверка: попробуйте вывести обе из North Star; если не получается, метрики живут в разных вселенных.
Продукт создаёт ценность, рост ускоряет её доставку
Лишнее напряжение проще всего снять, если развести логики и оставить команды связанными. Продакт-менеджмент отвечает за создание и развитие основной ценности: проблему пользователя, архитектуру продукта, ядро опыта и способность продукта удерживать. Рост отвечает за то, чтобы эта ценность доходила до человека быстрее: пользователь раньше её понимает, скорее получает первый значимый результат, чаще возвращается и охотнее платит. «Обходить» продукт в задачи роста не входит.
Это различие защищает от двух крайностей. В первой команда роста занимается только косметикой: тестирует кнопки, тексты и автоматические рассылки. Компания теряет рост, который могла бы получить. Во второй рост получает почти полную автономию и оптимизирует воронку в отрыве от продуктовой логики. Тогда ради локальных эффектов разрушается системная ценность продукта, как в истории с пейволлом.
На практике лучше всего работает модель из двух потоков. Развитие продукта и улучшение воронки ведут разные команды, но работают они как одно целое. Продуктовая команда отвечает за долгосрочную ценность и целостность опыта. Команда роста отвечает за привлечение, активацию, удержание и механику монетизации. Само по себе разделение зон мало что даёт. Работают понятные правила взаимодействия между ними: кто решает, по каким метрикам судят результат и в каком порядке идут тесты.
Граница между «ценностью» и «доставкой ценности» к тому же проходит не там, где её обычно рисуют. Скорость загрузки кажется инженерной темой, но медленный экран теряет людей на каждом шаге воронки, и новый текст кнопки этого не возместит. Качество продукта само работает рычагом роста. Проверка занимает полчаса: прежде чем тестировать формулировки на шаге, где пользователи отваливаются, откройте этот шаг на слабом мобильном соединении и засеките, сколько он грузится.
Иерархия метрик ловит тесты, которые выигрывают во вред
Никакая схема взаимодействия не устоит без общей иерархии метрик. Делиться дашбордами недостаточно. Обе стороны должны работать в одной системе координат.
Наверху стоит North Star Metric, главный индикатор того, что продукт создаёт ценность. Ниже рычаги роста: привлечение, активация, удержание, монетизация. Ещё ниже продуктовые метрики качества опыта: доля пользователей, освоивших ключевой сценарий, успех выполнения задач, время до первой ценности, частота возврата. На нижнем уровне метрики экспериментов: прирост по шагу воронки, конверсия в конкретное действие, реакция на вариант пейволла.
Смысл структуры в том, чтобы локальная оптимизация не отрывалась от общей ценности. Вернёмся к пейволлу из начала статьи и подставим числа. Допустим, в контрольной версии из 1 000 пробных пользователей платить начинают 200, ежемесячный отток подписчиков 8%. Средняя жизнь подписчика 1 / 0,08 = 12,5 месяца, при цене 10 долларов в месяц это 125 долларов выручки на подписчика и 25 000 долларов на всю когорту. В агрессивной версии платить начинают 230, но отток растёт до 11%. Жизнь подписчика сокращается до 9,1 месяца, выручка на подписчика до 91 доллара, на когорту примерно до 20 900 долларов. Тест, который поднял конверсию в оплату на 15% относительно (на 3 п.п.), проигрывает по выручке когорты около 16%.
Механика ловушки простая. Конверсия в оплату видна через две недели, отток через три месяца, и тест закрывают по той цифре, которая успела появиться. Краткосрочный эффект изменения может разойтись с долгосрочным даже по знаку, как здесь: плюс 15% на входе, минус 16% в деньгах. Поэтому у каждого эксперимента роста должна быть защитная метрика из уровня выше, которую он не имеет права ухудшать: удержание на 30-й или 90-й день, доля возвратов, жалобы. Если тест поднял активацию и уронил удержание, организация должна видеть системное противоречие.
Порог лучше записать заранее и числом. Например: если удержание на 30-й день в тестовой группе ниже контрольного больше чем на один процентный пункт, тест считается проигранным независимо от основной метрики. Один пункт здесь только пример, порог стоит подобрать по истории собственных когорт, но записанный порог заканчивает спор за минуту, а незаписанный растягивает его на квартал.
Отдельные тесты не показывают накопленного эффекта. Десять изменений, каждое из которых чуть подталкивает пользователя к оплате, вместе могут сделать продукт навязчивым. Против этого работает долгосрочная контрольная группа: небольшая доля новых пользователей, например 5%, в течение квартала не получает изменений роста. Сравнение с ней в конце квартала показывает суммарный эффект всей программы экспериментов, включая то, что каждый отдельный тест не поймал.
Обратное правило тоже работает. Если продуктовая команда улучшила освоение ключевой функции, а удержание и монетизация не сдвинулись, стоит спросить, туда ли вложено улучшение. Возможно, главный рычаг роста лежит в другом месте.
40 000 новичков в месяц вмещают два теста онбординга
В зрелой компании эксперименты устроены по общим правилам для продукта, роста, инженеров, дизайнеров и аналитиков. В эти правила входят шаблоны гипотез, правила приоритизации, требования к статистической достоверности, процедуры проверки качества и журнал решений.
Почему это касается обеих сторон, видно из арифметики. Допустим, онбординг проходят 40 000 новых пользователей в месяц. Чтобы заметить прирост активации с 30% до 32%, нужно около 8 400 пользователей на вариант (оценка по стандартной формуле при уровне значимости 5% и мощности 80%). Двухвариантный тест забирает почти 17 000 пользователей, то есть в месяц на онбординге помещается два таких теста, не больше. Если продуктовая команда одновременно хочет проверить новый первый экран, она конкурирует за тот же трафик. Без общего плана экспериментов команды либо пересекаются и портят друг другу результаты, либо спорят, чей тест важнее.
Рост остаётся естественным двигателем скорости. Продукт следит, чтобы эксперименты не жили в отрыве от стратегии, UX и технических ограничений. Рост, в свою очередь, не даёт продуктовой стратегии остаться на уровне дорожной карты и регулярно проверяет её поведенческими сигналами.
Общая очередь тестов нужна и по другой причине. Заметная часть тестов даже у опытных команд не сдвигает метрику, а угадывать заранее, какой из них выстрелит, команды умеют плохо: гипотеза, которую все считали мелкой, иногда приносит больше, чем флагманская. Поэтому спор «чья гипотеза лучше» полезнее заменить общим правилом приоритизации и общей очередью. У очереди нужен срок годности. Тест, который ждёт запуска дольше квартала, либо запускают на малой доле трафика, либо закрывают с записью в журнале, иначе бэклог превращается в кладбище идей, о котором спорят на каждом планировании.
Часть конфликтов за трафик снимает инфраструктура. Инженеры Google ещё в 2010 году описали на KDD (Tang и соавторы) систему пересекающихся экспериментов: тесты раскладываются по независимым слоям, и пользователь может одновременно участвовать в нескольких, если они не влияют на одни и те же элементы. Тесты, которые меняют один и тот же экран, всё равно приходится разводить во времени. Поэтому общий календарь экспериментов нужен даже при хорошей платформе: он показывает, какие тесты могут идти параллельно, а какие ждут очереди.
Последний элемент системы: журнал решений. По каждому эксперименту в нём записаны гипотеза, основная и защитные метрики, размер выборки, дата решения и само решение с владельцем. Через год такой журнал становится самой ценной базой знаний компании о своих пользователях, а без него команды повторяют уже проваленные тесты.
Кто решает, кто советует, кто делает
Многие трения возникают просто потому, что компания не зафиксировала права принятия решений. Кто решает, как выглядит основной онбординг? Кто вправе запускать эксперименты с активацией? Кто утверждает пейволл и модель подписки? Если вопросы остаются неявными, организация решает их через силу влияния, срочность или привычку.
Матрица прав не обязана быть бюрократической. Хватит ответа на три вопроса по каждой спорной зоне: кто принимает решение, кто консультирует, кто реализует. Типичное распределение выглядит так:
- Ядро онбординга: решает продукт, рост обязательно консультирует.
- Эксперименты с активацией: решает рост, продукт согласует системные риски и защитные метрики.
- Пейволл и модель подписки: совместное владение, но с заранее назначенным человеком, который решает при разногласии.
- Ценовые эксперименты: стратегическую рамку задаёт продукт, проверку гипотез ведут рост и коммерческая команда.
Матрица убирает лишнюю политику. Спор о том, кто имеет право участвовать, сменяется спором о том, какое решение лучше, и идёт он по заранее понятному процессу.
На спорный случай нужно правило эскалации. Допустим, рост хочет поднять цену годового плана на 15%, а продукт считает, что это ударит по новому тарифу для команд. Если стороны не договорились за неделю, вопрос уходит к заранее названному арбитру, обычно руководителю продукта или CPO, и тот решает в течение 48 часов, опираясь на защитные метрики и журнал прошлых ценовых тестов. Без такого правила спорный тест просто не запускается, и это тоже решение, только никем не принятое.
За каждой ролью при этом закреплён вклад в результат. Продакт-менеджер отвечает за стратегию продукта, ценностное предложение и долгосрочную связность системы. Он защищает продукт от оптимизации, которая выигрывает в одной точке и вредит общей логике, и при этом удерживает фокус на том, что именно должно расти. Growth PM отвечает за показатели воронки и план экспериментов. Хороший Growth PM рядом с приростом конверсии держит экономику: срок окупаемости, LTV, качество выручки. Обе команды выигрывают, если договорятся о границах экономики заранее и запишут их числами: во сколько раз LTV должен превышать CAC и за сколько месяцев должно окупаться привлечение. Тест, который поднимает конверсию ценой выхода за эти границы, тогда не нужно обсуждать.
Инженеры роста строят инструменты для тестов, сбор событий для аналитики и переключатели, которыми функции включают и выключают. Аналитики отличают причину от совпадения и следят за общими правилами чтения результатов. Дизайн следит, чтобы эксперименты не ломали целостность интерфейса. Маркетинг и рассылки на разных этапах жизни клиента отвечают за привлечение и удержание.
Структура зависит от стадии компании
Один и тот же набор ролей можно собрать по-разному, и универсальной структуры нет. Выбор зависит от стадии:
- Ранняя стадия, продукт ещё ищет активацию. Гибридная роль PM и роста в одном человеке. Работает, пока команд мало; риск в размытии фокуса, когда один человек тянет и ценность, и воронку.
- Масштабирование, растёт число команд. Выделенная команда роста. Встроенная в продуктовые команды держит рост ближе к продукту, но плодит локальные практики. Центральная лучше масштабирует стандарты, но отрывается от контекста, если не прописаны права решений и общие ритуалы.
- SaaS, который клиенты покупают и настраивают сами (self-serve). Гибридный PLG: экспертиза роста внутри продуктовых команд плюс центральная PLG-функция, которая задаёт стандарты и ведёт общую систему экспериментов.
- Высокая зрелость аналитики и управления. Команды-миссии вокруг активации, удержания или монетизации, где продукт и рост владеют результатом совместно. Слабое лидерство и незрелые данные такая модель не переживает.
Менять структуру стоит тогда, когда прежняя схема начала регулярно порождать одни и те же споры о границах. Календарь реорганизаций тут плохой ориентир. Признаки того, что стадия сменилась, обычно видны заранее. Гибридная роль перестаёт справляться, когда один человек больше не успевает прочитать результаты всех тестов. Встроенная модель требует центра, когда три команды независимо друг от друга построили три разных способа считать активацию. Центральная команда требует встраивания, когда продуктовые команды начинают узнавать о её тестах постфактум.
Сильнее всего функции нужны друг другу в петлях роста, то есть в замкнутых циклах, где результат одного шага становится входом следующего: приглашённый пользователь сам приглашает, опубликованный контент приводит новых авторов. В петле привлечения продукт задаёт ценностное обещание, а рост доставляет его в нужные каналы. В петле активации рост оптимизирует путь, а продукт гарантирует, что в конце пути человек получает реальную ценность и нажатие кнопки ничего не подменяет. В петле удержания продукт отвечает за причины возвращаться, рост за ритм напоминаний. В петле монетизации продукт задаёт логику предложения, рост проверяет готовность платить.
Когда отдельная команда роста не нужна
Многие руководители продукта не стали бы выделять рост в отдельную функцию вовсе. Их логика понятна. Любая граница между функциями создаёт интерфейс, а интерфейс требует матриц, ритуалов и согласований. Если один продакт-менеджер отвечает и за ценность, и за воронку, конфликт метрик решается в одной голове, без встреч. Отдельная команда роста, по их словам, лишь оформляет на оргсхеме проблему, которой могло не быть.
На ранней стадии и в небольших компаниях они правы: продуктовых команд одна-две, а трафика мало для параллельных тестов. Правы и там, где рост делают продажи, например в корпоративном B2B с длинным циклом сделки. Там выделенная команда роста будет оптимизировать воронку, которой почти нет. Особый случай представляют маркетплейсы. Там рост одной стороны зависит от качества другой, и тест, который ускоряет привлечение покупателей, может ухудшить жизнь продавцов. Отдельная команда роста без общей метрики здоровья обеих сторон здесь опаснее, чем её отсутствие.
С масштабом довод слабеет. Когда продуктовых команд пять и больше, каждая начинает изобретать свои эксперименты, свою аналитику и свои защитные метрики. Ценой становится несопоставимость результатов. Рабочее правило: пока трафика хватает на один-два параллельных теста в месяц, рост живёт внутри продуктовой роли. Когда тестов становится больше, чем один человек может спланировать и прочитать, нужна выделенная функция, хотя бы центральная и небольшая.
Сначала проектируют права решений, реорганизацию оставляют на потом
Реальные отношения между продуктом и ростом формируются в ритуалах. Еженедельный обзор воронки, совместное планирование экспериментов, ежемесячная встреча по стратегии, квартальная сверка метрик и ретроспективы по экспериментам делают взаимодействие устойчивым. Здоровый цикл выглядит так. Продукт формулирует проблемную точку, например лишние шаги в онбординге. Growth PM переводит её в набор гипотез. Инженер и дизайнер готовят варианты. Аналитик задаёт измерения и защитные метрики. Продукт проверяет удобство, технические ограничения и соответствие правилам. Рост запускает тест, и затем команды вместе решают: масштабировать, дорабатывать или отклонить.
Ритуалы стоят времени, и бюджет лучше задать явно. Обзор воронки раз в неделю на 45 минут, планирование экспериментов раз в две недели на час, квартальная сверка метрик на полдня. Для продакт-менеджера и Growth PM это примерно полтора-два часа в неделю совместной работы. За квартал набегает 20-26 часов на каждого, около трёх рабочих дней. Квартал спора о пейволле обходится дороже. Если ритуалы занимают заметно больше, часть решений принимается на встречах, хотя должна приниматься по матрице.
Начинать стоит с самого дешёвого шага, и ритуалы к нему не относятся. Выпишите спорные зоны (активация, онбординг, пейволл, цены) и для каждой назначьте, кто решает, кто консультирует и кто реализует. Затем сведите метрики обеих команд в одну иерархию под North Star и договоритесь, какие защитные метрики эксперимент не имеет права ухудшать. После этого пройдитесь по плану тестов на квартал: тест, который затрагивает зону без владельца решения, почти наверняка станет следующим местом конфликта.
Работает ли связка, видно по тому, сколько экспериментов получают решение в течение недели после окончания теста. Рядом стоит держать удержание когорт на 90-й день: если тестов становится больше, а удержание падает, быстрые решения принимаются за счёт продукта.
Реорганизацию лучше оставить на последнюю очередь. Без матрицы решений и общих метрик она просто переносит старые споры в новую структуру. Само напряжение между функциями никуда не денется, и беды в этом нет, пока оно разрешается по заранее понятным правилам.