Інтро в продакт-менеджмент та продуктове мислення

Мене звати Марк, я продакт-лід (читай — головний по продукту) в PawChamp (онлайн-платформа для тренування та навчання собак). У 2018 році я світчнувся з юриспруденції в продакт-менеджмент, веду подкаст і телеграм-канал Product Market Fat.

Це перша “пілотна” публікація із серії статей про роботу продакт-менеджерів, продуктове мислення, підходи до створення продуктів та про те, як “трушні” продакти додають цінність. А ще більше — як ми всі разом можемо робити це ще краще для:

• користувачів нашого продукту,
• компанії як бізнесу,
• колег, з якими ми проводимо ну дууже багато часу, створюючи різні круті штуки.

Disclaimer: під час написання цієї публікації та в процесі моєї роботи продактом жодна собака не постраждала. Все сказане тут — лише мої думки, а не істина в останній інстанції. Просто я так бачу. Це мої суб’єктивні когнітивні викривлення крізь призму персонального досвіду.

Коротко про історію продакт-менеджменту

Насправді в жарті «сучасні продакт-менеджери в IT — це наслідок «перелюбу» маркетингу та розробки» є трохи правди. Але все почалося ще в 1931 році, коли Ніл МакЕлрой (американський бізнесмен та 6-й міністр оборони США) описав нову позицію в компанії — «Brand Men». А також роль спеціаліста на цій позиції у просуванні й управлінні тогочасними офлайновими продуктами через (1) експерименти та (2) дослідження користувачів.

У середині XX століття засновники Hewlett-Packard вирішили, що бренд-менеджери, які тоді були частиною маркетинг-команд і займалися продажами, мають бути ближчими до інженерів та технологій. Тож вони ще й навантажили їх написанням Product Requirements Documentation (PRD).

За цими детальними PRD технологічні команди чітко створювали продукти, дотримуючись специфікацій. Smells like a waterfall!

Так, модель управління проєктами Waterfall цілком нормально працювала для офлайнових товарів та IT-продуктів аж до кінця 1990-х — початку 2000-х років, коли майже весь софт поширювали через дискети, диски та флешки. Тоді оновлення випускали не так часто, а інтернет був повільним. Але зараз ми так продукти не створюємо. Ми швидко реагуємо, швидко запускаємо та ще швидше ітеративно змінюємо продукти. Наш маркетинг взагалі осідлав невизначеність і на великих об’ємах миттєво тестує купу різних креативів і воронок у пошуках інсайтів та цільової маржі

Згодом інтернет прискорив розробку, а разом із цим ватерфол почав виглядати «як сова на глобусі». Побажання замовників або ситуація на ринку змінювалися швидше, ніж працівники встигали переписати PRD. Саме тоді, у 90-х, інженери вигадали методології Scrum Guide та Agile, щоб структурувати роботу, коли бізнес постійно приносив ідеї на вчора і детальні ватерфольні PRD втрачали сенс. Аби відокремити олдскульних продактів від «нової хвилі», автори Scrum вигадали грейд Product Owner, щоб підкреслити, що цей спеціаліст:

• ще ближчий до команди розробки;
• оунерить продукт;
• ухвалює рішення та пріоритезує;
• є містком між девелоперами та стейкхолдерами.

Та зрештою Product Owner не дуже прижився. Product Manager — це більш поширена назва, бо:

1. Scrum Guide легко прочитати, але важко впровадити «трушний» Scrum у компаніях;
2. Часто працівник має позицію Product Owner, але оунершипу над продуктом не має (сумно, але правда);
3. У компаніях із традиційними Product Managers замість зміни їхніх обов’язків просто поруч створювали роль Product Owner для фокусу на розробці фіч (SAFe framework передає привіт).

Product Owner vs Product Manager: що важливо знати?

У спрощеному вигляді можна сказати, що в ідеальному світі product owner ≈ product manager. Якщо детальніше, то:

• Product Manager — це ширше поняття;
• Product Owner прив’язаний до Scrum-фреймворку.

Детально про історію продакт-менеджменту та конфлікт тайтлів Product Owner vs Product Manager я писав у блозі на Medium.

Сучасний продакт-менеджмент в ІТ як професія сформувався наприкінці 90-х — на початку 2000-х і набув популярності у 2010-х. Традиційний продакт-менеджер із маркетингу поступово все більше залучався до розробки продукту. Компанії підтримували цей перехід, вибудовуючи продуктово-орієнтовані бізнес-процеси, які об’єднували маркетинг, продажі, розробку та інших у щоденній співпраці навколо продукту.

Згодом продакт-менеджер перестав бути просто менеджером з боку бізнесу чи маркетингу та став тим, хто об’єднує команду навколо єдиного бачення розвитку продукту.

Є дуже круте (і трішки пафосне) есе Бена Горовіца, інвестора та генерального партнера Andreessen Horowitz, про Good/Bad product managers. У ньому він ідеалізує, що продакт — це наче «CEO для продукту», який:

• відповідає за успіх продукту;
• глибоко розуміє контекст;
• ухвалює складні рішення;
• координує команду, не маючи повноважень CEO.

На мою думку, частково Горовіц має рацію, частково — ні. Наразі активно триває формалізація та стандартизація цієї професії:

• з’являються програми в університетах;
• формуються окремі продуктові кар’єрні треки (AI product manager, mobile product manager, product marketing manager, growth PM тощо).

Фактично продакт — не CEO, але він відповідає за продукт або його частину, щоб досягти цілей, поставлених перед продуктом і командою.

Про продуктове мислення та функцію продактів

В теорії місію продакта будь-якого грейду (від джуна до CPO) можна описати однією фразою, але функціональні обов’язки та очікування від нього залежать від досвіду та бізнес-викликів.

Експерт з продуктового менеджменту Марті Каган у книжці Inspired про створення продуктів, які люблять користувачі, пише: «Product management means working towards creating the right product for the right user». Якщо трактувати ширше, то кожен із нас трішки продакт-менеджер

Жарти жартами, та насправді кожен член команди може принести корисну ідею для покращення продукту:

• поділитися інсайтами з аналітики чи маркетингу;
• запропонувати якісне вирішення проблеми, над якою ламає голову продакт;
• щонайменше принести свіжий погляд на продуктові процеси.

Чи робить це всіх продактами? Ні. Та чи це круто і корисно для компанії? Абсолютно!

До недавнього часу на продактів не навчали в університетах, тож люди опановують цей домен еволюційно з різних сфер: розробки, дизайну, продажів, маркетингу, аналітики, сапорту, бізнес-аналізу, проєктного менеджменту й навіть юриспруденції.

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

Проактивність та залученість у досягнення бізнес-результатів через вплив на продукт — один із проявів продуктового мислення (product mindset).

При цьому product mindset — не монополія продактів. Це частина нашого growth mindset — мислення зростання.

Growth mindset — це переконання, що будь-які навички можна покращити завдяки зусиллям, навчанню та наполегливості. Люди з таким підходом частіше приймають виклики, вчаться на помилках і швидше адаптуються до змін.

Класично growth mindset стосується особистого розвитку, а в контексті product mindset — це прийняття змін і постійний пошук можливостей для зростання та покращення продукту.

Продакти мають product mindset by default — це проявляється в запитаннях, які ми постійно ставимо собі:

• Яку проблему ми вирішуємо? (Яку проблему користувачів закриває наш продукт? Чому люди ним користуються?)
• Для кого ми створюємо продукт? (Хто наша цільова аудиторія? Для яких саме користувачів ми його робимо? Тут важлива тісна співпраця з маркетингом)
• Чого ми хочемо досягти? (Які цілі в нашого продукту? Як вони обʼєднані з цілями бізнесу та інших команд?)
• Чому ми створюємо цей продукт? (Яка наша візія? Яке місце та роль продукту в бізнесі у майбутньому?)
• Як ми створюємо продукт? (Яка наша стратегія розвитку, щоб досягти поставлених цілей і реалізувати візію?)
• Що саме ми робимо? (Які фічі та функціональність нам потрібні для реалізації планів?)

Більшість із цих запитань не мають однозначної відповіді — це гіпотези, що базуються на даних, аналізі, аргументах і доступній інформації. Що вищий грейд і досвід продакта, то більше невизначеності він має приймати й більшу вагу мають його рішення для бізнесу.

Про бізнес-функцію продакт-менеджерів

Будь-яка роль у компанії — це цільова функція, яка покликана оптимізувати бізнес-результати:

• юристи зменшують юридичні ризики та стежать, щоб бізнес працював у правовому полі;
• маркетинг фокусується на залученні користувачів і пошуку ефективних стратегій просування;
• девелопери відповідають за реалізацію та підтримку технічних рішень, що вирішують бізнес-виклики;
• а продакт-менеджери максимізують цінність, яку продукт приносить користувачам, мінімізуючи time-to-market.

Саме тому продакти можуть приходити до девелоперів із запитаннями, «я як зробити цю фічу швидше», «а давайте ще цю таску затягнемо в спринт», «а, може, тут тимчасово «закостилити», щоб швидше релізнути та отримати фідбек від юзерів?» і так далі

Так, це може дратувати дев-команду, але для продактів важливіші швидші outcomes, ніж ідеальні outputs. Нам важливо якнайшвидше дізнатися, яку цінність приносить фіча користувачам, ніж створювати ідеально написаний код чи дизайн із першого разу. Якщо фіча дійсно корисна — тоді її можна вдосконалювати ітеративно.

Висновки

Вплив продакт-менеджера на бізнес можна оцінити по шкалі від:

Мінімальний рівень: продакт лише пише таски в Jira та є посередником між технічною командою та реальними decision-makers (CEO або іншими стейкхолдерами). Його роль — вчасно і в межах бюджету та скопу розробити фічу, на її результати та rollout він не впливає;

Максимальний рівень: продакт — це business impact manager, який:

• аналізує ринок і продукт;
• формує продуктову стратегію та роадмапу;
• шукає точки зростання продукту і бізнесу;
• залучений у бізнесові та навколопродуктові процеси;
• може ухвалювати рішення самостійно або може дійсно організувати ухвалення рішення іншими.

Фактично, продакт — це клей, що з’єднує ключові зони бізнесу в продуктових ІТ-компаніях. Він може організувати ефективну співпрацю між командами для створення цінних фіч та масштабування продукту.

• Немає окремого payment-менеджера, щоб оптимізувати прийом платежів? Дайте це продакту, він розбереться;
• Треба швидко зробити нову фічу під креативи, які класно конвертять юзерів на маркетингу, та ще й таким чином, щоб юристи це схвалили і юзерам сподобалося? Дайте продакту, він щось вигадає;
• Немає хеда сапорту, а треба будувати сапорт? Дайте це продакту — він і найме хеда, і сапорт-процеси почне будувати на користь продукту

Чому так? Бо маркетинг та розробка мають більш чіткі межі своїх функцій, а продакт-менеджмент гнучкіший. І якщо щось впливає на продукт, але за це поки немає відповідальної людини, якій можна делегувати цю функцію, то чому б не продакту? Недолік цієї системи в тому, що продакт може бути перенавантаженим і дефокусуватися, особливо якщо делегувати та планувати цей продакт тільки вчиться. А ще в нас може бути дуууже багато мітингів та зустрічей у календарі