Опять про Growth

Добью темку 😉
A few years ago Growth-хакерство было на пике популярности. Говорящие головы всех мастей ходили по конференциям и рассказывали друг другу сказки, как изменив цвет кнопки, они улучшили конверсию на 146% и заработали дофигаллиард. Многие попытались повторить этот успешный успех, но когда дело дошло до дела, рынок остыл, и теперь к Growth подходят более осознанно. В основном через призму двух вопросов:

Когда стоит выделять Growth в отдельную функцию?
Как это сделать правильно?

Прежде чем перейти к ответу, определимся с понятиями (на всякий 😉)

✔️ Core — это про создание и максимизацию ценности продукта для пользователя.
- Отвечает за: фундаментальная ценность, функциональность и UX.
- Метрики: CSAT, CES, D30-90-180 Retention, добавленной ценности (NSM), СLTV, MRR (удержание), Adoption.

✔️ Growth — это про то, как донести эту ценность до максимального числа пользователей.
- Отвечает за: оптимизация воронки, снижение friction в CJM, онбординг, каналы коммуникации.
- Метрики: конверсии, активация и TTV, K-factor, CLTC, СLTV (монетизация и churn), ARPPU, MRR, NRR, GRR.

💡Growth в B2C ориентирован на массовые каналы, viral & referral, в B2B строится на новых сегментах и рынках и глубокой интеграции в бизнес-процессы клиента.

Очевидно, что эти функции тесно переплетаются:
🔘 Core-фичи могут менять поведение пользователей в воронке и влиять на монетарные метрики (например, новые сценарии использования влияют на Expansion, ARPPU, LTV и даже конверсии).
🔘 Growth-эксперименты могут выявить потребность в изменении Core-функций (например, A/B-тестирование разных сценариев онбординга может подсветить необходимость редизайна).

Часто Growth не выделяют в отдельную функцию. Когда выделяют, возможны разные форматы, и почти всегда возникают конфликты с core и маркетингом: за ресурсы, приоритеты, атрибуцию заслуг. Но главный риск — слишком увлечься оптимизацией локальных максимумов или скатиться в антипаттерны.

Нужно ли выделять Growth? Как?

Сугубо ИМХО: конфигурацию Growth-функции (не выделять/отдельная команда/сервис/аналитика) можно выбрать в зависимости от фазы продукта + good practice по типу роста + бизнес-модели + capacity команды в широком смысле.

Вырисовывается алгоритм:

1️⃣Решение «Выделять/не выделять»

1.1. Есть ли PMF?
❌ Нет → Не выделять. Экспериментируйте внутри Core-команды.
🔘 Да → Переходите к 1.2.

1.2. Рост стагнирует?
❌ Нет → Не выделять.
🔘 Да → Переходите к 1.3.

1.3. Есть ресурсы (в т.ч. data)?
❌ Нет → Не выделять.
🔘 Да → Если много гипотез, но нет процесса быстрой проверки, или эксперименты отнимают >30% времени — есть смысл выделить Growth.

━━━━━━━━━━━━━━

2️⃣Решение «Как выбрать конфигурацию?»

2.1. Определите стадию продукта и характерный для нее тип роста (МакКормак):

📦 Pre-PMF → Viral+Sticky внутри Core.
☢️ Медленно, ресурсы распыляются.

🚀 Scaling → Отдельная команда (Sticky + Paid).
☢️ Конфликты с Core/маркетингом, общий код.

📈 Maturity → Сервисная команда (Expansive + Paid).
☢️ Мало персонализации, бюрократия.

❌ Decline → Аналитика + R&D (если боремся).
☢️ Нет ownership.
(Слайд 1)

2.2. Сделайте поправку на бизнес-модель (она влияет и на тип роста, и на метрики):

📌 Если у вас высокая частота использования и сильное удержание → делайте ставку на Sticky Growth.
📌 Если у вас контентный продукт или сильный социальный эффект → используйте Viral Growth.
📌 Если у вас высокая маржинальность и возможность инвестировать в привлечение → можно масштабировать через Paid Growth.
(Слайд 2)

Как избежать конфликтов между Growth и Core?

Чётко определите зоны ответственности и работайте в команде:

✔️ Поделите метрики
✔️ Разрабатывайте совместную стратегию
✔️ Синхронизируйтесь в фазе реализации (внедрите RACI, если у вас отдельная growth-команда с инженерами, то нужен жесткий процесс ревью, Feature Flags, sandbox-среды)
✔️ Заранее договоритесь как действовать, если одна команда повлияет на метрики другой.

💡Самое сложное — не принять решение "выделять ли", а понять где продукт и что происходит с ним и рынком 😉

Pro Product

#Стратегия #Процессы #Метрики