Продуктовая команда: роли

Из кого состоит продуктовая команда

«Продуктовая команда» — это не общий пул сотрудников компании, а небольшая автономная группа, которая отвечает за один продукт или направление. В классическом виде это так называемая product trio: продакт, дизайнер и тимлид разработки. Плюс к ним — разработчики, аналитик и часто QA.

Размер команды редко превышает 8–10 человек. Это не правило, а здравый смысл: больше — теряется коммуникация, нужны лишние процессы и менеджеры. Если продукт растёт — лучше разбить на две автономные команды, чем раздуть одну.

Главный принцип здоровой команды — кросс-функциональность. То есть команда умеет сама решать продуктовые задачи от идеи до релиза, не бегая за помощью к смежникам по каждому шагу. Это сильно отличается от старой модели, где дизайн, разработка и аналитика были отдельными отделами и работали по запросу.

Дальше — по каждой роли подробнее.

Продакт-менеджер

Зона: «что и зачем».

• Формулирует продуктовые цели команды на квартал.
• Ведёт discovery: интервью, гипотезы, приоритизация.
• Пишет PRD на ключевые фичи.
• Отвечает за метрики продукта.
• Защищает приоритеты от внешнего шума.
• Коммуницирует со стейкхолдерами.

Продакт не управляет командой иерархически — он координирует через влияние и общие цели. Подробнее про роль — в отдельной статье.

Продуктовый дизайнер

Зона: «как пользователь это увидит».

• Проводит UX-исследования (часто вместе с продактом).
• Проектирует пользовательские сценарии.
• Делает прототипы и итерации.
• Работает с дизайн-системой компании.
• Участвует в QA-сессиях, чтобы релиз не отличался от макета.
• Тестирует прототипы с пользователями.

В сильных командах дизайнер — равноправный партнёр продакта, а не «исполнитель макетов по ТЗ». Он сам приносит инсайты из исследований и предлагает решения.

В небольших командах один дизайнер закрывает и UX, и UI. В больших — это разные люди, плюс может быть отдельный UX-исследователь.

Разработчики и тимлид

Зона: «как это построить».

Тимлид (или engineering manager):

• Отвечает за техническую сторону команды.
• Принимает архитектурные решения.
• Управляет ресурсами и сроками со стороны разработки.
• Растит разработчиков, занимается ревью и наймом.
• Партнёр продакта в принятии решений.

Разработчики (frontend, backend, mobile):

• Реализуют фичи по PRD и макетам.
• Участвуют в груминге задач, дают оценки.
• Поднимают технические долги и риски.
• В сильных командах — приносят свои продуктовые гипотезы, не только ждут ТЗ.

Размер технической части обычно 2–5 человек на команду. Если меньше — ползёт скорость, если больше — растёт коммуникационная нагрузка.

Продуктовый аналитик

Зона: «правда ли это работает».

• Строит и поддерживает дашборды по ключевым метрикам.
• Проектирует и анализирует A/B-тесты.
• Отвечает на ad-hoc вопросы команды («сколько у нас пользователей сегмента X?»).
• Помогает с decomposition больших метрик.
• Участвует в discovery — собирает количественные сигналы о проблемах.
• Учит команду читать данные.

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

Подробнее про эту роль — в сравнении продакта и аналитика.

Расширенная команда: QA, маркетинг, саппорт

Эти роли не всегда входят в core-команду, но активно с ней взаимодействуют.

QA-инженер. Тестирует фичи перед релизом, пишет автотесты, участвует в bug-bash перед запусками. В современных командах часто часть тестирования делают сами разработчики, и выделенного QA нет — но в продуктах с высокой ценой ошибки (банкинг, медицина) он обязателен.

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

Саппорт. Не часть core-команды, но критически важный партнёр. Саппорт первым видит реальные проблемы пользователей. Сильные продакты регулярно слушают звонки и читают тикеты.

Технический писатель. В B2B и сложных API-продуктах — отдельная роль. В B2C обычно совмещается с маркетингом или дизайном.

Как роли взаимодействуют

Здоровая команда работает в нескольких регулярных ритмах.

• Daily standup. 15 минут утром, что у кого статус, есть ли блокеры.
• Sprint planning. Раз в 1–2 недели, что берём в работу.
• Refinement. Раз в неделю — детализация задач из бэклога.
• Retrospective. Раз в спринт — что улучшить в процессе.
• Quarterly planning. Раз в квартал — цели и крупные направления.

Между этими ритмами идёт постоянная асинхронная переписка в Slack, ad-hoc созвоны и встречи 1:1. Хорошая команда не зависит от формальных встреч — большая часть решений принимается в небольших группах по мере необходимости.

Конфликты неизбежны. Типичные:

• продакт vs дизайнер: «нужно быстро» vs «нужно красиво и правильно»;
• продакт vs тимлид: «выкатим как есть» vs «надо рефакторить»;
• разработка vs QA: «тут нет бага» vs «есть, я воспроизвёл»;
• продакт vs маркетинг: «давайте подождём с анонсом» vs «нам надо план выполнить».

Это нормально. Признак нездоровой команды — когда конфликтов не видно, потому что все молчат.

Частые ошибки

• Раздувание команды. Если в продуктовой команде 15 человек — это уже не команда, а отдел. Делите на две.
• Дизайнер как исполнитель. Если дизайнер только рисует по ТЗ от продакта, команда теряет половину креативной мощности.
• Аналитик «по вызову». Если аналитик не сидит в команде, а выполняет тикеты — данные приходят с задержкой и теряют контекст.
• Технический долг как «не наша проблема». Если команда выпускает только новые фичи и не платит за тех долг, через год скорость падает в 3 раза.
• Игнорирование саппорта. Команда, которая не слышит саппорт, узнаёт о проблемах от ушедших пользователей.

Связанные темы

• Кто такой продакт-менеджер
• Что такое продуктовый менеджмент
• Что делает CPO
• Продакт vs аналитик
• Продуктовая аналитика

FAQ

Какой минимальный состав продуктовой команды?

Самый минимум — продакт, дизайнер и 1–2 разработчика. Без аналитика можно жить первые месяцы, но с ростом он становится обязательным.

Может ли один человек быть продактом и дизайнером?

В очень маленьком стартапе — да. В средней компании — нет, навыки слишком разные, и в итоге плохо страдают обе роли.

Кто главный в продуктовой команде?

В здоровой команде — никто. Продакт, дизайнер и тимлид разработки — равные партнёры. У каждого своя зона. Если в команде есть «главный», обычно это сигнал, что роли распределены плохо.

Сколько разработчиков на одного продакта?

Здоровое соотношение — 3–6 разработчиков на одного продакта. Меньше — продакт перегружен координацией маленькой команды. Больше — не успевает работать с каждым.

Должен ли аналитик быть в команде или в общем пуле?

Лучше в команде — даёт скорость и контекст. Если ресурс ограничен, делят одного аналитика на 2 команды, но это уже компромисс.

Что делать, если в команде нет дизайнера?

Либо нанимать срочно, либо использовать готовую дизайн-систему и не лезть в кастомные интерфейсы. Продакт за дизайнера — плохая идея на длинном горизонте.

---

Готовишься к собесу в продуктовой команде? Открой тренажёр Карьерника — 1500+ вопросов по SQL, A/B-тестам и метрикам.