Что такое продуктовая команда? Зачем она нужна и какие задачи должна решать?
Основной движущей силой продукта является его команда. Без нее мало, что получится. Ты можешь попробовать затащить что-то в одно лицо, но рано или поздно упрешься в ограничение
За годы работы в разных компаниях мне посчастливилось быть частью продуктовых команд. В какой-то момент я сам начал их собирать под разные цели и задачи, но каждый раз это был свой путь, который хотелось систематизировать. “Зачем тратить столько энергии на это?”, – спрашивал я себя. В какой-то момент просто сел и написал алгоритм, которым хочу поделиться в данном материале.
Продуктовая команда – это команда, которая создает и развивает продукт. Основная цель – удовлетворение пользовательских задач или потребностей, которые влияют на бизнес результат. Простыми словами продуктовая команда стремиться сделать пользователя счастливым с помощью продукта, чтобы тот заплатил больше денег.
Давайте посмотрим по какой логике должны собираться подобные команды.
В реально жизни как только не собирают команды:
Но это это все вторично. Прежде чем собирать команду, нужно определиться с целью, только потом думать о том какая команда нужна. Правильная последовательность такая:
Схематично так.
Если мы не выдержим эту логику, то придется натягивать сову на глобус, не понимая почему не получается: расфокусировка, пересечение ответственности, конфликты и куча чего еще…
Окей, выбрали цель, прикинули направления в стратегии и решили собрать команды, но, из кого они должны состоять?
Я покажу вам целевую конфигурацию продуктовой команды, которая способна закрыть полный спектр задач разработки и выпуска продукта. В реальной жизни подобная структура может встречаться далеко не всегда, потому что требует больших ресурсов от компании (~20 млн.руб/год + инфраструктура вокруг, которая позволит этой самой команде работать на полную).
Итак, из кого состоит продуктовая команда:
Давайте коротко посмотрим на каждую роль и поймем, кто за что отвечает.
Отвечает за ключевые цели и метрики продукта. Создает стратегию и планирует работы всей продуктовой команды. Исследует клиентов, вытаскивает их боли/задачи и проверяет гипотезы.
Помогает продакту с анализом данных вокруг продукта: воронки, конверсии, отчеты, планирование экспериментов и расчеты финансовых результатов. Цифры тут.
Проектирование клиентского опыта в интерфейсе продукта. Создает визуальное решение пользовательских задач, которые приносит продакт менеджер. Сценарии, кнопки, формы, стили, подготовка макетов для разработки – все сюда.
Подготовка технического задания на разработку. Детальное описание будущего решения техническим языком, использование различных методов API (Application Programming Interface) и интеграций в текущей технологической системе. В общем, пишет на языке разработчиков, что конкретно хочет продакт менеджер по макетам дизайнера.
Реализация требований с помощью кода по техническому. То есть, производит то, что потом пользователи будут щупать руками в продукте, то, чем будут пользоваться. Инженер который непосредственно создает решение.
Проверяет на закрытых от пользователя средах (сайтах, устройствах, платформах) функционал от разработчика согласно заявленным требованиям. Ищет ошибки, баги, несоответствия и возвращает на доработку разработчику задачу, пока та не будет корректно работать. Фильтр качества, по-простому.
Если посмотреть сверху на работу продуктовой команды, то получится что-то вроде завода с цехами, где слева-направо каждый закрывает свой кусок.
И вот очередной ночью (часто релизы делают ночью, чтобы в случае ошибок поменьше людей с ними сталкивались) или днем пользователь видит в интерфейсе своего сайта новый сценарий, кнопку, сервис. И радуется, наверное.
Я привел вам пример целевой структуры продуктовой команды – это стандарт/эталон, который неплохо себя зарекомендовал на рынке, но жизнь она разная, поэтому давайте чуть шире посмотрим на то, как оно еще бывает.
На деле, конфигурации команд могут сильно отличаться друг от друга. Расскажу про те, которые видел в своей практике и дам небольшие пояснения причин, почему получилась та или иная конструкция.
Это самый распространенный тип команд. По составу может состоять из одного или нескольких человек. Как вы понимаете, такая команда постоянно горит, потому что вынуждена тащить на себе кучу функций. Спрашивают за все и вся, по умолчанию виноваты во всем.
Причины появления таких команд:
Подобные команды долго не живут, потому что внутри выгорают люди. Обновление команды болезненно для компании: как правило, дела от ушедших не передаются новым, базы знаний нет и каждый новый член команды начинает практически с нуля.
Состав команды определен под конкретный проект. Надо затащить что-то конкретное в срок. Требования точные и понятные, придумывать ничего не нужно. Нет ответственности за финансовый результат продукта.
Причины появления таких команд:
Отлично встраиваются в любую компанию и контекст. Легко масштабируются под разные масштабы задач.
Фиксированный состав участников, кросс-функциональный профиль компетенций, позволяющий полностью создать решение пользовательских боли/задач. Ответственность за финансовые показатели продукта.
Причины появления таких команд:
Данный тип команд хорошо работает с ситуациями неопределенности. Нужно прокачивать продукт, но непонятно в каком направлении? Поможет продуктовая команда. Запустят гору экспериментов, провалидируют потребность на клиентах и соберут решение.
По моему опыту нет идеального типа команд, но лучше всего комбинировать проектные и продуктовые команды. С одной стороны у тебя есть крупные проекты/запуски со сроками. которые тащат проектные команды. С другой продуктовые команды, которые постоянно тюнят и развивают продукт.
Подобный подход позволяет выдерживать большое кол-во запросов и изменений. Различные заказчики могут приходить с запросами, далее эти запросы проходят валидацию через цель/стратегию и распределяются по командам в зависимости от типа. Понятный проект к сроку? В проектную команду. Что-то сложное, что нужно придумать, спроектировать, проверить? В продуктовую.
Можно. Обратите внимание, что описывая продуктовую команду, я упоминал слово “кросс-функциональная“, то есть состоящая из разных функций. В этом и заключается следующий виток эволюции. Мы можем связать продуктовую команду с другими функциями компании, например:
Грубо так.
Обвязываем маркетологов едиными целями с продуктовой командой. Собираем единый план действий, и вот они вместе тащат компанию к успеху: маркетолог собирает рекламные кампании под продукт, а продукт приземляет и конвертит в клиентов. Шик, блеск, бурлеск!
И так далее вяжем команды под другие функции компании, на сколько это позволяет ресурс и полномочия. Пока это лучшее, что я видел/делал. Подобная конструкция максимально фокусирует усилия на достижении общих целей и убирает кучу конфликтов на горизонтальных уровнях. Дальше система разгоняется и начинает выдавать бОльший результат.
В реальной жизни возможны различные типы команд в зависимости от контекста и возможностей компании. Продуктовая команда – это не истина в последней инстанции, но возможная конструкция. Комбинируйте ее с другими типами, ищите собственные конфигурации и затачивайте систему под себя.
Алексей А.
P.S. Проводил детальный семинар про команды в IT продуктах с нюансами и спецификой развертки, можно посмотреть тут – п.6.
Читайте также:
Кстати, я уже давно веду авторские семинары по управлению IT продуктами, если интересно, посмотреть их можно тут.
Психодел с одного рекламного хит-парада. Какие-то шмотки рекламируют.
Продуктовый подход в управлении IT продуктами: Как извлечь максимальную пользу и избежать распространенных ошибок. (далее…)
Что такое культура компании? Зачем она нужна и какие задачи решает? Подготовил алгоритм сборки, поделюсь.…
На этой странице я собрал все семинары, которые когда-либо разрабатывал и проводил. Каждый из них,…
Какой должна быть оценка компетенций и как выстроить систему на примере продакт менеджеров. (далее…)
Про то, как ребята из Basecamp управляют продуктом "под капотом". (далее…)
View Comments
Почему в составе продуктовой отсутствует руководитель проектов? На какое количество человек рассчитана "идеальная" команда?
Как правило, проджекты не входят в продуктовые команды.
В зависимости от размера компании:
- эту роль может выполнять сам продакт (в небольших организациях)
- проджект может быть "сбоку от команды" синхронизируя ее, например, с другими функциями (маркетинг, продажи и т.д.)
- но бывает, что и внутри в роли delivery manager, того, кто отвечает непосредственно за выпуск изменения на прод
То, что сам видел в больших корпорациях - этот как раз "сбоку".