Что такое продуктовая команда? Зачем она нужна и какие задачи должна решать?

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

За годы работы в разных компаниях мне посчастливилось быть частью продуктовых команд. В какой-то момент я сам начал их собирать под разные цели и задачи, но каждый раз это был свой путь, который хотелось систематизировать. “Зачем тратить столько энергии на это?”, – спрашивал я себя. В какой-то момент просто сел и написал алгоритм, которым хочу поделиться в данном материале.

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

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

Продуктовая команда это

Давайте посмотрим по какой логике должны собираться подобные команды.

Как собирать продуктовые команды

В реально жизни как только не собирают команды:

  • по платформам: команда сайта, приложения, смарт тв и пр…
  • по кускам продукта: команда личного кабинета, раздела “Избранное”, кнопки на главной страницы…
  • по воронке пользовательского опыта (мой любимый подход): команда за привлечения клиента, активацию, удержания…

Но это это все вторично. Прежде чем собирать команду, нужно определиться с целью, только потом думать о том какая команда нужна. Правильная последовательность такая:

  • определяем цель, например “Заработать Х денег в следующем году”
  • набрасываем стратегию с направлениями, через которые мы к этой цели придем (будем качать CRM, SEO и Активацию клиента в продукте)
  • под каждое направление формируем продуктовую команду со своими метриками, которые выходят из общей цели

Схематично так.

Как собирать продуктовые команды

Если мы не выдержим эту логику, то придется натягивать сову на глобус, не понимая почему не получается: расфокусировка, пересечение ответственности, конфликты и куча чего еще…

Окей, выбрали цель, прикинули направления в стратегии и решили собрать команды, но, из кого они должны состоять?

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

Я покажу вам целевую конфигурацию продуктовой команды, которая способна закрыть полный спектр задач разработки и выпуска продукта. В реальной жизни подобная структура может встречаться далеко не всегда, потому что требует больших ресурсов от компании (~20 млн.руб/год + инфраструктура вокруг, которая позволит этой самой команде работать на полную).

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

  • Продакт менеджер
  • Продуктовый аналитик
  • Дизайнер
  • Системный аналитик/архитектор
  • Разработчик
  • Тестировщик

Давайте коротко посмотрим на каждую роль и поймем, кто за что отвечает.

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

Отвечает за ключевые цели и метрики продукта. Создает стратегию и планирует работы всей продуктовой команды. Исследует клиентов, вытаскивает их боли/задачи и проверяет гипотезы.

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

Помогает продакту с анализом данных вокруг продукта: воронки, конверсии, отчеты, планирование экспериментов и расчеты финансовых результатов. Цифры тут.

Дизайнер

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

Системный аналитик/архитектор

Подготовка технического задания на разработку. Детальное описание будущего решения техническим языком, использование различных методов API (Application Programming Interface) и интеграций в текущей технологической системе. В общем, пишет на языке разработчиков, что конкретно хочет продакт менеджер по макетам дизайнера.

Разработчик

Реализация требований с помощью кода по техническому. То есть, производит то, что потом пользователи будут щупать руками в продукте, то, чем будут пользоваться. Инженер который непосредственно создает решение.

Тестировщик

Проверяет на закрытых от пользователя средах (сайтах, устройствах, платформах) функционал от разработчика согласно заявленным требованиям. Ищет ошибки, баги, несоответствия и возвращает на доработку разработчику задачу, пока та не будет корректно работать. Фильтр качества, по-простому.

Как работает продуктовая команда

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

Продуктовая команда: как работает
  • Продакт менеджер формулирует что именно нужно сделать в продукте для решения задач клиентов.
  • Далее дизайнер помогает спроектировать макеты того, как будет выглядеть это решение.
  • Продуктовый аналитик размечает события, чтобы потом собирались данные. Или же планирует эксперимент с выпуском задачи, используя различные показатели и метрики.
  • Системный аналитик сводит требования продакта, макеты дизайнера и аналитику в единое техническое задание. Указывает с точки зрения архитектуры зависимости, системы и методы, которые будут задействованы при реализации решения и передает все это разработчику.
  • Разработчик разрабатывает решение, используя код. После того, как решение готово, отдает его на закрытую среду в тестирование.
  • Тестировщик проверяет все сценарии, заложенные в требованиях. В случае ошибок, возвращает обратно в разработку на исправление, в случае успеха отправляет в релиз.

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

Я привел вам пример целевой структуры продуктовой команды – это стандарт/эталон, который неплохо себя зарекомендовал на рынке, но жизнь она разная, поэтому давайте чуть шире посмотрим на то, как оно еще бывает.

Типы команд

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

Горящая жопа

Продуктовые команды: конфигурация нет ресурсов

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

Причины появления таких команд:

  • Нет или не хотят выделять деньги на полноценную продуктовую команду (20 лямов в год попробуй найди, да еще инфраструктуру вокруг построй).
  • Нет знаний про то, как должна выглядеть целевая команда.
  • Так сложилось. Работает и ладно, зачем что-то менять.

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

Проектная команда

Продуктовые команды: проектная команда

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

Причины появления таких команд:

  • Есть крупные большие проекты/задачи привязанные к жестким срокам.
  • Нет необходимости искать что именно делать.

Отлично встраиваются в любую компанию и контекст. Легко масштабируются под разные масштабы задач.

Продуктовые команды

Продуктовые команды - описание и причины возникновения

Фиксированный состав участников, кросс-функциональный профиль компетенций, позволяющий полностью создать решение пользовательских боли/задач. Ответственность за финансовые показатели продукта.

Причины появления таких команд:

  • Есть необходимость постоянного развития существующего продукта или запуск нового.
  • Система готова к изменениям процессов на более “гибкие” рельсы: гипотезы, эксперименты, спринты и т.д.
  • Кто-то сверху услышал, что это модно и решил попробовать у себя, вдруг что-то дельное получится.

Данный тип команд хорошо работает с ситуациями неопределенности. Нужно прокачивать продукт, но непонятно в каком направлении? Поможет продуктовая команда. Запустят гору экспериментов, провалидируют потребность на клиентах и соберут решение.

Какой тип команд выбрать

По моему опыту нет идеального типа команд, но лучше всего комбинировать проектные и продуктовые команды. С одной стороны у тебя есть крупные проекты/запуски со сроками. которые тащат проектные команды. С другой продуктовые команды, которые постоянно тюнят и развивают продукт.

Комбинированный тип команд: проектные и продуктовые

Подобный подход позволяет выдерживать большое кол-во запросов и изменений. Различные заказчики могут приходить с запросами, далее эти запросы проходят валидацию через цель/стратегию и распределяются по командам в зависимости от типа. Понятный проект к сроку? В проектную команду. Что-то сложное, что нужно придумать, спроектировать, проверить? В продуктовую.

А еще лучше можно?

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

  • маркетинг
  • продажи
  • и т.д. в зависимости от цели и стратегии компании

Грубо так.

Кросс-функциональная команда продукта

Обвязываем маркетологов едиными целями с продуктовой командой. Собираем единый план действий, и вот они вместе тащат компанию к успеху: маркетолог собирает рекламные кампании под продукт, а продукт приземляет и конвертит в клиентов. Шик, блеск, бурлеск!

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

Итого

В реальной жизни возможны различные типы команд в зависимости от контекста и возможностей компании. Продуктовая команда – это не истина в последней инстанции, но возможная конструкция. Комбинируйте ее с другими типами, ищите собственные конфигурации и затачивайте систему под себя.

Алексей А.

P.S. Проводил детальный семинар про команды в IT продуктах с нюансами и спецификой развертки, можно посмотреть тут – п.6.


Читайте также:

Кстати, я уже давно веду авторские семинары по управлению IT продуктами, если интересно, посмотреть их можно тут.


Психодел с одного рекламного хит-парада. Какие-то шмотки рекламируют.