Склад продуктової команди залежить від продукту, його складності, цілей і темпу зростання. Але є «стандартний набір», якого достатньо для створення продукту, його виведення на ринок і залучення перших користувачів.
Олександр Ємельянов має 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-художник. Продуктова команда збирається у певному бізнес-контексті.
Весь бізнес-контент у зручному форматі. Інтерв'ю, кейси, лайфхаки корп. світу — у нашому телеграм-каналі. Приєднуйтесь!