Зоны ответственности: Discovery/Delivery/Growth

PM не обязан лично выполнять всю работу продуктового цикла, но отвечает за связность решений от проблемы до результата. Явно разделяйте ответственность за решение и вклад специалистов: исследователь может вести интервью, инженер — выбирать архитектуру, но контекст, trade-offs и критерий успеха должны быть общими.

Роли и контекст для продакта

Введение: зачем разделять зоны ответственности

Зачем нужны Discovery, Delivery и Growth

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

Когда разделение важно

В старте или небольшой команде ты как продакт часто закрываешь все три зоны. С ростом компании или продукта зоны обычно дробят между разными ролями — например, выделяют отдельного Growth Product Manager или команду Discovery. Это критично для согласованности процессов и скорости.

Discovery: поиск ключевых решений

Ключевая задача Discovery

Discovery (дискавери, стадия поиска) отвечает за изучение рынка, пользователей и проблем, а не за само решение. Главная работа — понять, за что стоит браться и почему. В зоне ответственности: глубинные интервью, формулы Jobs To Be Done, кастдев, прототипирование, ранние эксперименты.

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

Роль продукта

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

Ограничения

В Discovery не решают вопросы архитектуры, масштабирования или объема трафика. Зона доходит до этапа, когда можно четко сказать: это решение стоит или не стоит делать дальше.

Delivery: воплощение решения

Ключевая задача Delivery

Delivery (доставка, реализация) — вся работа по превращению валидированной гипотезы в работающий продукт или фичу. Сюда входят управление бэклогом, приоритезация, написание требований, постановка задач разработчикам, UX-дизайн, тестирование, выкаты и релизы.

Пример:
Когда в Discovery выяснили, что пользователям нужны удобные предзаказы в приложении, команда Delivery разрабатывает дизайн, пишет и тестирует код, следит за качеством и стабильно выпускает обновление.

Роль продукта

В этой зоне продукт-менеджер — связующее звено между заказчиками (бизнесом), инженерами, дизайнерами и аналитиками. Его задача — обеспечить релиз фичи в срок, с нужным качеством, без провала по цели Discovery (например, не потерять смысл для пользователя). Ошибка — не вовлекать исполнителей в планирование или жертвовать пользовательским опытом ради скорости.

Ограничения

В Delivery не валидируют изначальную ценность фичи или рынка — это уже следующая стадия. Delivery отвечает только за качественную реализацию и техническую зрелость.

Growth: масштабирование и рост

Ключевая задача Growth

Зона Growth (рост) — про масштабирование продукта, рост метрик активации, удержания, монетизации. Сюда входит оптимизация воронок, A/B-тесты, работа с платным и органическим трафиком, партнерские и кросс-продуктовые гипотезы. Фокус на data-driven решениях.

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

Роль продукта

Growth-продакт отвечает за формулировку гипотез роста (например, как увеличить LTV или сократить отток), запуск и анализ экспериментов, быстрые итерации. Производит аналитику не только по новым, но и по существующим пользователям. Частая ошибка — запускать эксперименты вслепую или фокусироваться только на одной метрике.

Ограничения

Growth не отвечает за полное перепроектирование продукта или стратегические решения по рынкам — его задача масштабировать через быстрые, измеримые изменения.

Ключевые пересечения и антипаттерны

Антипаттерны в зонах ответственности

Частые ошибки — размывание зон между командами, когда Discovery делает Delivery или Growth выдает задачи Delivery как A/B-тесты без подготовки. Это приводит к хаосу, простоям и снижению скорости. Еще один антипаттерн — слишком ранний переход к релизу без валидации гипотезы (минус Discovery), или наоборот, затягивание исследований уже на готовом продукте.

Практический кейс:
В продукте B2B SaaS команда начинающих продуктоводов совмещала Discovery и Delivery и часто недооценивала влияние нового флоу на существующие метрики. В итоге релизы были стабильны, но рост стагнировал. Исправили разделением функций и четкой документацией, что и кто валидирует.

Организационные границы

Границы между Discovery, Delivery и Growth должны быть видимы не только продакту, но и всей команде. Документировать договоренности, проводить воркшопы по ролям, внедрять чек-листы — хороший способ не затеряться в распределении ответственности.

FAQ

Зачем делить зоны ответственности в продукте?
Чтобы ускорить работу, снизить количество ошибок и снизить конфликты в команде.

В каких компаниях Discovery и Delivery совмещают?
Это часто в стартапах и небольших командах. С ростом бизнеса роли дробятся.

Можно ли продакт-менеджеру отвечать сразу за все зоны?
Можно на старте продукта, но на зрелой стадии лучше разделять по отдельным ролям для фокуса.

Какая главная ошибка при разделении Discovery и Delivery?
Рано переходить от поиска к реализации без проверки гипотез и пользовательских инсайтов.

Когда начинает работать Growth?
Когда продукт доказал продукт-рынок-фит и важно масштабировать метрики.

Чем отличается Discovery-продакт от Growth-продакта?
Первый ищет новые возможности и решения, второй тюнингует и развивает существующие метрики продукта.