Состав продуктовой команды зависит от продукта, его сложности, целей и темпов роста. Но есть «стандартный набор», которого зачастую достаточно для создания продукта, его вывода на рынок и привлечения первых пользователей.
У Александра Емельянова — 9+ лет опыта в IT и управлении продуктами. Он запустил с нуля приложение Gemini Photos в MacPaw (награда Mobile App of the year от Product Hunt и Annual Recurring Revenue (ARR) — $1 млн за первый год). Создал цифровую экосистему в medtech-компании Bioniq и способствовал поднятию раунда инвестиций в $15 млн. Скоро в Laba стартует курс Александра «Продакт-менеджмент».
Нам Александр рассказал о ключевых ролях в продуктовых командах — в чем их ценность, когда они необходимы, а когда ими можно пожертвовать.
#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. Разработчик
Это обязательная роль в продуктовой команде, но количество и потребность в экспертизе девелоперов зависят от:
- сложности решения (чем она выше — тем больше специалистов и уровень seniority)
- стека технологий
Например, простой продукт может разработать и один «универсальный» девелопер на кроссплатформенных фреймворках типа Flutter или React Native.
Если команда создает продукт для iOS и Android — привлекаются специалисты с соответствующими навыками (например, разработчики SWIFT/Objective-C и Java/C#). Для создания бэкенда (внутреннего устройства) продукта нужны backend-девелоперы (например, Node.js, Python или .NET).
#3. Дизайнер
Дизайнер в продуктовой команде отвечает не только за визуальную часть (например, разработку макетов) — он должен знать потребности бизнеса, как продукт будет решать проблемы пользователей и зарабатывать деньги.
Если команда не просто разрабатывает продукт, но еще и выводит его на рынок или масштабирует, часто выделяют две разные роли:
- продуктовый дизайнер занимается оформлением непосредственно продукта (макеты, UX/UI-прототипы)
- маркетинг-дизайнер отвечает за создание инициатив для привлечения пользователей (лендинги, баннеры, креативы для социальных сетей и т. д.)
#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. Иначе невозможен быстрый и предсказуемый рост продукта.
#8. Аналитик
Роль может называться по-разному: Data Analyst, Product Analyst, Business Analyst. Этот специалист помогает команде принимать data-driven решения о развитии продукта. Аналитик собирает и исследует данные, изучает продуктовые метрики (в привлечении, удержании, вовлеченности пользователей и т. д.), отслеживает влияние изменений в продукте на поведение юзеров. Мониторит конверсию и находит инсайты, направляющие команду.
Специфика данных, с которыми работают аналитики, зависит от продукта. Например, в medtech-компании Bioniq такие специалисты занимались процессингом (обработкой) и созданием баз медицинских данных.
Не существует единого, оптимального состава продуктовой команды — и эти рамки не нужны. Сначала формируются цели — например, надо создать MVP, — а затем определяются необходимые компетенции и состав команды.
В одном коллективе с задачей справятся два девелопера, в другой — понадобится еще Machine Learning Engineer или 3D-художник. Продуктовая команда собирается в определенном бизнес-контексте.
Весь бизнес-контент в удобном формате. Интервью, кейсы, лайфхаки корп. мира — в нашем телеграм-канале. Присоединяйтесь!
Хотите получать дайджест статей?
