что такое продуктовая команда
Продуктовая команда
Сегодня постараюсь рассказать, что такое продуктовая команда. Ее состав и роли, на примере большой организации.
ПРОДУКТ — Предмет, являющийся результатом человеческого труда (книжн.).
В IT — продукт это программное обеспечение решающее какие-то задачи или потребности.
Отличие продуктовой команды от сервисной
Сервисная разработка заканчивается после запуска проекта.
В продуктовой разработке после запуска происходит анализ обратной связи, генерация новых идей. За тем цикл повторяется вновь, и длится это бесконечно.
Состав команды
В зависимости от специфики продукта состав команды может меняться. Чаще всего в команду входят Владелиц продукта, Аналитик, Разработчики, Дизайнер, Тестировщик.
Давайте рассмотрим каждого из них и поймем чем они занимаются.
Задача Владельца продукта вести разработку в нужном направлении. Формулировать потребности пользователя, изучать обратную связь и формулировать задачи для команды, расставлять приоритеты и помогать команде выполнять свою работу в максимально комфортных условиях.
Составляет Бэклог Продукта.
В некоторых случаях владелиц проводит командные ритуалы, такие как дейли, ретроспективу и планирование.
Продуктовый аналитик — должен уметь работать с данными. Чем больше данных, тем выше вероятность принять правильное решение. Для этого необходимо изучать метрики, строить воронки, следить, к каким результатам приводят малейшие изменения.
У дизайнера в команде бывает несколько задач. Проектирование взаимодействия пользователя с системой и отрисовка ui компонентов. На этапе проектирование, он плотно взаимодействует с аналитиком, создает UX карты, вайрфремы сценариев. За тем они превращается в полноценные макеты и связываются в прототипы. После тестирования и доработки, макеты передаются разработчикам
Разработчики это те люди которые превращают идеи и картинки в рабочее приложение с которым в последствии взаимодействует пользователь. Обычно разработка разделяется на серверную и фронтальную часть.
Серверные разработчики пишут программно-аппаратную часть сервиса. Работа с базой данных, API.
Frontend разработчик отвечает за визуальную часть сервиса, с которым взаимодействует пользователь.
В продуктах для мобильных платформ это часто бывает один и тот же человек.
Тестировщики люди которые отвечают за то, чтобы новый код работал корректно и решение соответствовало поставленной задаче, чтобы не было пропущено ни одного запланированного сценария и чтобы после внедрения новых частей кода, старые оставались в рабочем состоянии.
Ритуалы
В зависимости от принятых в компании метод управления проектами в продуктовых командах проводят свои ритуалы. В нашем случае это дейли, ретроспектива и планирование.
Дейли — проводится каждый день, на нем каждый член команды рассказывает что было сделано вчера и что планируется к исполнению сегодня. Цель мероприятия не контроль исполнителя, а своевременное выявление осложнений и выработка решений.
Ретроспектива — встреча команды в конце каждого спринта для улучшения совместной работы. На ней участники обсуждают, хорошо ли они взаимодействовали между собой. К концу встречи участники составляют план улучшения работы для внедрения в следующем спринте.
Планирование — это встреча для определения цели и объёма работы в будущем спринте. На ней обсуждают, в каком направлении развивать продукт и сколько задач взять в спринт, чтобы к этому прийти. Благодаря встрече они чётко представляют, что и как улучшить в продукте.
Chapter
Когда в компании несколько продуктовых команд, одинаковые роли из разных команд образуют чаптер.
Из этих сотрудников выбирается чаптер лидер, который несет ответственность за консистентность и за то, как именно будут решаться те или иные задачи в командах. Так же чаптер лидер устанавливает иерархию и ответственен за развитие членов чаптера.
Вся нагрузка ложится на него в дополнение к той которую несет на себе каждый участник чаптера.
Tribe
Когда в компании много команд и подразделений коммуникация между ними может стать проблемой. Здесь и возникают Трайбы.
Трайб — это совокупность команд объединенных одной миссией.
Трайбы координируются Лидером трайба, который выступает гарантом того, что знания и понимание является общим, управляет приоритетами и распределяет бюджет. Лидер так же обеспечивает взаимодействие с другими трайбами компании.
Сервисные команды
Иногда для эффективного выполнения работы команде не нужна на постоянной основе какая-то роль. Например один дизайнер, в состоянии обслуживает 4–5 команд, но в этом случае не может полноценно участвовать в жизни команды. Такие роли исключают из продуктовой команды и образуют из них сервисную структуру, которая берет заказы от продуктовых команд. Часто бывает что такими командами являются аутсорсовые ресурсы.
8 ключевых ролей в продуктовой команде
И почему некоторые из них недооценивают (а зря).
Состав продуктовой команды зависит от продукта, его сложности, целей и темпов роста. Но есть «стандартный набор», которого зачастую достаточно для создания продукта, его вывода на рынок и привлечения первых пользователей.
Нам Александр рассказал о ключевых ролях в продуктовых командах — в чем их ценность, когда они необходимы, а когда ими можно пожертвовать.
#1. Product Manager / Product Owner
PM отвечает за создание и развитие продукта (определяет его стратегию, User Flow, наполняет бэклог), управляет бюджетом, коммуникациями с клиентами и внутри команды (планирует, приоритизирует и контролирует выполнение задач). Зачастую РМ отвечает и за успешный вывод продукта на рынок, его масштабирование, а также за монетизацию. На ранних стадиях развития стартапов роль РМ’а может выполнять фаундер.
В Agile-фреймворке Scrum есть позиция Product Owner (владелец продукта). Она близка к РМ’у, но больше сфокусирована на разработке и развитии: РО создает концепцию, руководит реализацией на всех этапах жизненного цикла, зачастую глубже погружен в техническую часть. Его ответственность — получить продукт, который отвечает ожиданиям клиентов (через анализ обратной связи пользователей, коммуникации с коллегами и создание для них комфортных условий).
Также в Agile-командах, работающих по фреймворку Scrum, часто есть отдельная роль Scrum Master. В таких коллективах РМ/PО отвечают за продукт, а SM — за соблюдение Scrum-артефактов (стендапы, daily-митинги, ретроспективы, фасилитации и т. д.).
По моему опыту, выделять эту роль необходимо не всегда, даже если команда работает по фреймворку (по крайней мере, full-time). Например, в компании MacPaw есть Scrum Masters, которые «шерятся» между командами. Также эта роль не всегда обязательна на ранних стадиях развития проекта, когда критично оптимизировать косты. Не все команды четко следуют артефактам фреймворка, многие настраивают его под себя — и это тоже работает. Ведь главное — не теоретические выкладки, а результат (успешный продукт).
#2. Разработчик
Это обязательная роль в продуктовой команде, но количество и потребность в экспертизе девелоперов зависят от:
Например, простой продукт может разработать и один «универсальный» девелопер на кроссплатформенных фреймворках типа Flutter или React Native.
#3. Дизайнер
Дизайнер в продуктовой команде отвечает не только за визуальную часть (например, разработку макетов) — он должен знать потребности бизнеса, как продукт будет решать проблемы пользователей и зарабатывать деньги.
Если команда не просто разрабатывает продукт, но еще и выводит его на рынок или масштабирует, часто выделяют две разные роли:
#4. QA (тестировщик)
Этот специалист проверяет продукт на наличие багов, тестирует пользовательские сценарии. Помогает обеспечивать нужное качество, соответствие техзаданию и корректность работы продукта на девайсах, которые будут использовать юзеры.
QA-специалисты могут поспорить, но мое личное мнение — чем выше seniority команды, тем меньше потребность в этой роли. Зачастую опытные разработчики допускают мало багов, могут сами написать и провести тесты.
Хотите получать дайджест статей?
#5. Копирайтер
Необходимость в этой роли зависит от объемов копи (текстов). Часто копирайтер вовлечен в работу продуктовой команды на part-time — или же привлекается подрядчик. Он пишет UX-копи (тексты для интерфейса) и маркетинговые материалы — например, для продвижения в соцсетях. Также стратегия развития продукта может включать органические охваты (например, блог с SEO-контентом).
#6. Product Marketing Manager
Создает маркетинговую стратегию и план, ищет эффективные каналы привлечения пользователей и масштабирования, а также устанавливает метрики, по которым будет оцениваться успешность продукта. Это важная роль, но не во всех командах ее выполняет отдельный специалист.
Например, создание приложения Gemini Photos в MacPaw началось именно с того, что мы с Product Marketing Manager провели
User Research и обнаружили запрос на продукт. А в medtech-компании Bioniq моей экспертизы на позиции Chief Product Officer было достаточно.
#7. UA Manager / PPC Manager
User Acquisition Manager — это специалист по привлечению пользователей, PPC Manager — по контекстной рекламе. Они планируют кампании для разных каналов, отслеживают их эффективность, работают с копирайтерами и маркетинг-дизайнерами над созданием перформящих креативов.
Я считаю эту роль важной, но недооцененной. Необходимо грамотно работать с paid-трафиком (платными каналами привлечения пользователей), прежде всего — это Google, Facebook, Instagram и TikTok. Иначе невозможен быстрый и предсказуемый рост продукта.
Александр Емельянов,
Chief Product Officer at Kama.co
Волк Ірина,
General Manager у Dell Technology Group, Ukraine and West CI
#8. Аналитик
Роль может называться по-разному: Data Analyst, Product Analyst, Business Analyst. Этот специалист помогает команде принимать data-driven решения о развитии продукта. Аналитик собирает и исследует данные, изучает продуктовые метрики (в привлечении, удержании, вовлеченности пользователей и т. д.), отслеживает влияние изменений в продукте на поведение юзеров. Мониторит конверсию и находит инсайты, направляющие команду.
Специфика данных, с которыми работают аналитики, зависит от продукта. Например, в medtech-компании Bioniq такие специалисты занимались процессингом (обработкой) и созданием баз медицинских данных.
Не существует единого, оптимального состава продуктовой команды — и эти рамки не нужны. Сначала формируются цели — например, надо создать MVP, — а затем определяются необходимые компетенции и состав команды.
В одном коллективе с задачей справятся два девелопера, в другой — понадобится еще Machine Learning Engineer или 3D-художник. Продуктовая команда собирается в определенном бизнес-контексте.
Весь бизнес-контент в удобном формате. Интервью, кейсы, лайфхаки корп. мира — в нашем телеграм-канале. Присоединяйтесь!
Как организованы продуктовые команды в Lamoda, Skyeng, «Авито» и других компаниях
Канал о продакт-менеджменте No Flame No Game узнал у продактов из девяти компаний, по какому принципу у них организованы команды.
На английском языке есть две прекрасные заметки на эту тему — от Buffer и Spotify — и я давно уже хотела сделать нечто подобное для NFNG. И вот, случилось. Спасибо всем спикерам, кто смог поучаствовать.
В RealtimeBoard есть две группы продуктовых команд — Core Product и Product Growth.
В Core-продукте разделение по опыту пользователя, компонентам — Core features, Integrations, Platform, Mobile, Enterprise. В Product Growth — по Customer journey: Activation, Engagement & Retention, Monetization.
Разделение на две части связано с тем, что разная скорость разработки ключевого продукта и экспериментов, для этого нужен разный скиллсет людей. Мы для себя понимаем, что задача ключевого продукта — проверять гипотезу ценности и эту ценность доставлять до пользователя, а задача команды роста — масштабировать это.
Cхема работы между командами такая: Core product исследует потребности и workflow пользователей и занимается глубокой проработкой ценности и UX-фичей, а Product Growth уже встраивает их в «каналы доставки» (онбординг, нотификации и так далее) и монетизацию.
Чтобы все это не тащилось в разные стороны, есть три важные вещи:
1. OKRs, которые декомпозированы на инициативы, и каждая команда понимает, на что влияет
2. Общая для всех встреча по продуктовым инсайтам, где мы делимся результатами исследований
3. Встреча по продуктовому фидбэку, где мы обсуждаем решения.
Основной продукт «Авито» разделен на два ключевых сегмента — частники и бизнес. Далее продуктовые команды делятся по направлениям, которые приносят пользователям конкретную ценность.
Например, для частников это: опыт покупателя, опыт продавца, взаимодействие между покупателем и продавцом, безопасность и доверие и так далее по похожей логике. В каждом направлении одна или несколько продуктовых команд, у каждого направления свои цели и метрики.
Мы не страдаем догматизмом и стараемся адаптировать структуру под действительность, а не наоборот. Нам важно поддерживать стратегию компании соответствующими ударными силами, давать командам достаточно автономии и свободы, минимизировать толкание локтями между командами и всегда быть готовыми к изменениям.
Мы в Qlean организуем продуктовые команды по принципу «Цепочки ценностей» Майкла Портера. Инструмент цепочки ценностей в классическом варианте используется для стратегического анализа компании. Этот подход применяют, когда нужно очень сложный процесс декомпозировать на части и определить, где «узкое место». Мы подумали, что это можно адаптировать под нужды нашего бизнеса и продуктовой команды.
Почему мы выбрали такой подход?
1. Все бизнес-процессы укреплены продуктовой экспертизой. Мы видим всю цепочку, на каждое звено ставим часть продукта. Продукт «обволакивает» каждую функцию и думает вместе с ней об эффективности и автоматизации. Это сокращает затраты на коммуникацию, позволяет продакту больше погружаться в проблемы конкретного бизнес-процесса, а бизнес-заказчикам иметь прямой доступ к разработке.
2. Продукт развивается равномерно, нет «перекосов» — в мобильном приложении одна функциональность, на сайте другая, и все это не синхронизировано. Конечно, если мы не разделяем функциональность специально, чтобы вырастить какую-то из метрик.
3. У каждой продуктовой команды есть понятные бизнес-заказчики. Там, где их нет, процесс максимально автоматизирован. Не возникает путаницы и беспощадных Google Docs, куда тысяча бизнес-заказчиков ставят кучу своих «требований» к продукту.
4. Очень легко считать, за какую часть P&L отвечает команда: каждое звено цепочки ценности представлено в отдельной строке, блоке строк в отчетности. Это помогает лучше ставить цели, планировать эффект работы продукта на бизнес.
5. У продакт-менеджеров развивается большая экспертиза и глубокое понимание бизнеса. Им нужно мыслить в рамках отдельного звена бизнеса и контролировать коммуникации с соседними звеньями — они чувствуют себя полноценными «генеральными директорами» небольшой части компании.
Названия команд для примера — Customers Acquisition, Customers Retention, Cleaners Acqusition, Cleaners Retention, Customer Service.
Как мы работали раньше?
Над продуктом работали команды, которые поделены по типу создаваемой ценности. В старой структуре у нас было пять команд: веб-разработка, десктоп-разработка, маркетинг, развитие бизнеса и команда product ownership (по сути — PM, PO, PMM и стейкхолдеры). Все жили в квартальном цикле планирования с одной метрикой. И с этим были проблемы:
1. Долгий цикл планирования.
2. Огромное количество зависимостей между командами.
3. Сложные коммуникации между командами.
4. Принятие даже самых мелких решений превращается в боль.
5. Декомпозиция метрик.
Основа бизнеса Setapp — customer acquisition funnel. Также у нас есть несколько стратегических feature-направлений, в которые мы верим. Поэтому мы решили выстроить новую структуру вокруг того, что считаем важным. Так появился драфт нашей организационной структуры 2.0.
1. Growth team (закупка трафика, оптимацизация воронки, все, что происходит с юзером до начала триального периода).
2. Membership team (фокус на retention).
3. Revenue team (продажа базового плана, апселы, прайсинг).
4. Recovery (работа с churn, у нас он 2,5%, поэтому пока даже не начали ее формировать).
1. Setapp for Teams (задача — валидировать и запустить спин-офф потребительского продукта на b2b-рынке.
2. SEO and Editorial (нам дешевле и выгоднее содержать свое медиа, чем платить за трафик из Google или Facebook, поэтому выделяем отдельную команду, которая заточена на создание контента вокруг проекта).
1. Core dev team (фокус на фичах, которые пока что не имеют отдельного PM).
2. Core marketing (общая координация всего брендинга и закупки).
Что мы выучили, пока пытались придумать идеальную структуру:
1. Идеальной структуры не будет, нужно итерировать. Мы потратили большое количество времени, чтобы все продумать, но все равно в реальности в процессе реализации меняется все.
2. У команд должны быть PM. Мы попробовали запустить эксперимент с Growth командой без PM — затея не удалась.
3. При планировании новой структуры — фокусируйтесь на минимизации зависимостей между центрами создания ценности.
У нас нет сильного дробления, мы работаем продуктовыми командами, в которых продукт — отдельный сервис. У нас есть команда «Ленты», команда «Чемпионата» и так далее. Единственный бренд, в котором у нас есть дробление, — портал «Рамблер».
Он большой, поэтому там существуют продуктовые команды отдельных его частей: «Новости», «Погода», «Топ-100» и так далее. Такое разделение связано с тем, что у каждого проекта своя специфика, разная бизнес-логика и решаются разные задачи. При этом в наших медийных продуктах мы не видим смысла более узкого дробления, так как ряд ролей закрывают редакция и маркетинг.
Наша структура представляет собой несколько компаний (вертикалей). Каждая компания сфокусирована на определенном рынке и пользователе. Одна компания работает с гитаристами (самые массовые музыканты), другая на «классических» музыкантах, играющих по нотам и так далее.
Внутри компаний команды сформированы вокруг важных для нас метрик на пути пользователя. Каждая команда самоорганизующаяся и автономная: в ней есть все ресурсы для выдвижения идей по достижению метрики, преобразованию идей в гипотезы, запуску экспериментов, анализу экспериментов и формированию новых идей.
Важно, что все наши сервисы подписные. Существует большой объем бесплатного контента и ограниченный объем выверенного профессионалами платного контента.
Стандартный набор команд:
1. Команда DAU или MAU: привлечение и удержание пользователей бесплатной части сервиса
2. Команда активации: привлечение неплатящих пользователей в платную версию и оформления триального периода на Pro
3. Команда подписок: конверсия пользователей из триального периода в подписку и снижение оттока из подписки.
На сегодня такое разделение представляется нам наиболее эффективным, поскольку каждая из трех команд имеет свою специфику, свои компетенции и свои приемы.
Например, команда активации проводит минимум продуктовых изменений, но сильна в продвижении триала и мотивации пользователей опробовать платную версию. Команда DAU или MAU сильна в изменениях свойств самого продукта. Команда подписок должна обладать обеими компетенциями, вносить ценные изменения в продукт и продвигать Pro-подписку.
Несколько лет назад команды Lamoda были сфокусированы на создании отдельных систем, например, системы процессинга заказов или управлением доставкой. Минусы такого подхода заключались в том, что для запуска проектов надо было синхронизировать планы всех команд, которые участвовали в создании продукта. В результате проходило много времени от начала разработки до запуска, и не было фокуса на финальном продукте.
Когда мы формировали продуктовые команды, выбрали деление по платформам, в итоге одни занимались приложениями, другие — десктопным и мобильным сайтами. У такой организации несколько плюсов:
— Сокращается время до запуска продуктов.
— Если одна команда сделала сервис, то другой остается лишь поддержать клиентскую часть.
— При таком подходе получается хорошо фокусироваться на платформенных фичах (таких, как поиск по фото в приложениях) и развивать продукт на отдельной платформе в целом (например, мы серьезно изменили мобильный сайт).
Но есть и минусы, которые мы видели с самого начала. Например, надо внимательно следить за тем, чтобы кросс-платформенные фичи запускались с одним и тем же скоупом, а иногда и в одно и то же время.
Все это влечет за собой необходимость частой синхронизации между менеджерами. Этот подход также плохо масштабируем, при росте команды надо либо создавать несколько команд одной платформы, либо команды будут очень большие.
В итоге мы пришли к тому, что поочередно запускаем команды, которые отвечают за решение конкретной задачи пользователя. У каждой из команд есть заранее определенная бизнес-метрика, на которую должна повлиять их работа.
Например, у нас есть команда Sizes, которая решает одну из важных задач для онлайн fashion-ecommerce: делает так, чтобы люди не ошибались в выборе размера одежды и обуви. Особенность Lamoda в том, что онлайн и офлайн у нас тесно пересекаются.
Если в одном случае это означает автоматизацию и роботизацию склада, то в подборе размера — учет особенностей размерных сеток разных производителей и их соотношение с привычными для человека обозначениями.
Поэтому в Sizes участвуют не только менеджер продукта и разработчики, но и директор по планированию ассортимента. И в этом случае бизнес-метрикой улучшения будет сокращение возвратов из-за неподошедшего размера.
Сейчас в компании очень интересный переходный период: мы нанимаем новых продактов, как раз нужно принимать решения о разделении зон ответственности. Мы экспериментируем и изучаем опыт других компаний, но на текущем этапе склоняемся к разделению мобильного продукта по фичам плюс отдельный человек на веб, потому что там много web-specific-моментов.
От разделения по платформам (iOS, Android) мы отказались, так как нам важно сохранить консистентность между приложениями — и кажется логичным, что одну и ту же фичу под Android и под iOS будет продумывать и контролировать один и тот же человек. Делить продукт по экранам тоже не хочется, так как существенную долю фичей нужно протаскивать через все приложение.
В таких вопросах очень важна специфика компании, команды, конкретных менеджеров, разработчиков — нельзя просто посмотреть, как круто все устроено в компании N, повторить один в один и жить счастливо. Поэтому будем экспериментировать и обсуждать с командой.
У нас есть и горизонтальное (по платформам) и вертикальное (по частям customer journey) разделение. В целом, даже 3D-кубик получается.
Есть команда Product Core:
Это платформы, к ним приходят остальные заказчики — своеобразный baseline продукта.
Отдельно есть команды на разных этапах customer journey — своеобразный усиливающий спецназ:
— команда C1 (первой оплаты);
— команда C2 (второй оплаты);
— команда Teachers (у нас двусторонний рынок).
У них максимальный фокус на конкретные жизненно важные метрики.
И еще есть команды на новые направления:
Они выступают заказчиками к платформам или пилят какие-то вещи сами, если это нужно только им.
Для синхронизации команд — есть квартальные OKR, сквозные проекты и правила, чтобы они не буксовали, есть еженедельные встречи продактов (для обучения и иногда синхронизации).
Больше полезных заметок о продакт-менеджменте, аналитике и стратегии — на No Flame No Game.