З чого Product Manager починає роботу над новим проєктом? З дослідження? Чи спочатку збирає команду? А може насамперед треба прорахувати бюджет?

Product Manager у компанії WIX, співзасновник стартапу Atletude і маркетплейсу EBazar Павло Войцехівський ( тренер Web Academy) розповів, який шлях треба проробити, аби з нічого отримати MVP — мінімально життєздатний продукт. 

Хто такий Product Manager

Щоб зрозуміти, хто такий Product Manager і які в нього обов’язки, слід розібрати це поняття по словах.

Слово «product» — це речовий або інтелектуальний результат людської праці. Воно походить від англ. «produce» — «створювати». По суті, ви створюєте товар у компанії чи стартапі, щоб задовольнити потреби користувачів. Щоб товар не загубився на ринку, потрібно вигадувати стратегію: самостійно чи в команді. Стратегію ж створюють на основі даних, які генерує продукт. Продукти бувають різні: b2b, b2c, маркетплейс, e-commerce, software та ін. Неважливо, над яким продуктом ви працюєте, — для кожного потрібен зручний інтерфейс, дизайн, створений на основі потреб користувачів, аналізу ринку тощо.

Друга складова — manager, що означає «керувати». В нашому випадку це управління розробкою продукту. Але продукт розробляють в команді й Product Manager насамперед командний гравець. Втім, щоб навчитися управляти командою, спочатку треба навчитися управляти собою, своїм часом, пріоритетами. Бути командним гравцем – означає бути лідером, постійно брати на себе відповідальність та приймати складні рішення в умовах обмежених ресурсів. Product Manager — це про постійні комунікації: всередині команди, з користувачами, виступи на публіці, підготовка візуальних презентацій і їхній захист, мітинги, мітинги й ще раз мітинги.

Виходить, що робота Product Manager складна: вимагає креативності, енергійності, концентрації тощо. Але є хороша новина: згідно з інформацією ресурсу «Replaced By Robots!?» (сайт, створений на основі даних академічної праці «Майбутнє зайнятості: Наскільки робочі місця сприйнятливі до комп’ютеризації?», Бюро статистики праці США та O*NET, – Прим. ред.), професія Product Manager має маленький шанс бути заміненою роботом чи штучним інтелектом.

6 кроків у створенні продукту від 0 до MVP

Крок 1 — встановлення продуктової проблеми

Часто ми кажемо «У мене є ідея продукту». Ідея — це вміння автора ідентифікувати якусь проблему й знайти для неї рішення. Тому кожен  продукт починається з визначення та валідації проблеми, яку він покликаний розв’язати. Цікавий момент: хоча продукт покликаний розв’язати проблему, після запуску він автоматично створюватиме інші, для яких потрібно буде вигадувати нові рішення.

Але як зрозуміти, наскільки проблема велика? Як її розв’язують зараз? Найбільш логічний варіант — звернутися до користувачів. Спілкування з користувачами — те, що відрізняє справжніх Product Manager’ів від теоретиків.

У будь-якого продукту може бути широкий сегмент користувачів, тому насамперед потрібно визначити сегменти, на яких ви сфокусуєтеся, а далі — визначити так званих «персон». Персона — користувач, який є яскравим представником ширшого сегмента користувачів. Я рекомендую, щоб це був не вигаданий персонаж, а конкретна людина, якій дійсно потрібен продукт. Ваше завдання – знайти таких людей, запропонувати й обговорити продуктове рішення з цією персоною

Наприклад, одна з персон проєкту EBazar — Петро, якому 34 роки. Ми знайшли його через Viber-групу, де він продає свою продукцію. Чоловік проживає в місті Ковель і вирощує сезонні й тепличні овочі. Поспілкувавшись, дізналися, що він відвозить раз на тиждень товар на торгову точку, має автомобіль, працює охоронцем на фермі в селі тощо.

Для себе перед таким спілкуванням потрібно визначити, про які аспекти говоритимете. У випадку EBazar нас цікавило, чим займається господарство, як організована логістика, які канали збуту продукції використовує персона для реалізації продукту.

Якщо узагальнити, те, що цікавить Product Manager у спілкуванні з потенційними користувачами, це проблеми персони, як ці проблеми задовольняються зараз, чи користується людина продуктами конкурентів, а також будь-яка інсайдерська інформація про ринок.

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

Наприклад, для валідації проблеми платформи для тенісу Atletude я знаходив людей за фото в інстаграмі, де вони відзначали локацію кортів, на яких грали. Також знаходив їх офлайн на самих кортах або  форумах. Доходило до того, що я просто чіплявся до перехожих з тенісною ракеткою за спиною. Але це було досить ефективно.

Мій улюблений спосіб — створити лендинг-сторінку, описати продукт, проблеми й додати запрошення підписатися на бета-версію продукту. Так ви пропонуєте стати ексклюзивним користувачем, а людей це цікавить. Ще цей спосіб корисний тому, що ви приблизно можете оцінити вартість залучення одного споживача для планування маркетингового бюджету. Ви запускаєте рекламу, відтак протестуєте, чи залишають люди відповіді. А якщо витратили бюджет і не змогли нікого знайти, варто ще раз замислитися над доцільністю продукту. Якщо проблема нікому не болить, створювати продукт не потрібно.

Крок 2 — скоуп MVP

Якщо проблема існує і є відгуки, переходьте до визначення обсягу робіт – так званого скоупу.

Перша версія розробки — мінімально життєздатний продукт (той самий MVP), який можна дати раннім користувачам для розв’язання наявної продуктової проблеми в них.

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

Сфокусувавшись на базовому функціоналі, ви спрощуєте собі шлях до розвитку продукту. Адже жоден Product Manager не може сказати, як розвиватиметься продукт після того, як потрапить до користувача.

Якось ми зробили MVP, який не приносить цінності, і за це поплатилися. В рамках роботи над стартапом Atletude створили додаток для гравців в теніс, де вони могли знайти партнерів і корти. Функціонал був дуже простий. Але ми помилково вирішили, що нам потрібно до платформи залучити ще й тенісні клуби. І почали розробку системи управління бронюваннями для тенісних клубів, не провалідувавши проблеми, а тільки проаналізувавши конкурентів на ринку. Ми витратили кілька місяців розробки на сервіс, який виявився не потрібен клубам, хоча це було й безкоштовно. Їм було достатньо навіть дошки, на якій крейдою писали, хто в який час грає.

Тому ми змінили стратегію — вручну додали інформацію на мапу про тенісні корти в додаток. І коли користувач бронював корт, я отримував сповіщення, телефонував в тенісний клуб, представлявся співробітником Atletude і просив забронювати корт на ім’я нашого користувача. Дзвінків ставало більше і пропонувати нашу систему кортам стало простіше, адже клуби відчували нашу цінність. Зрештою кілька клубів погодилися використовувати нашу систему. Але нам з нуля довелося все переписувати, бо більшість функцій не були потрібні.

Або можемо уявити, що Bolt — єдиний сервіс виклику таксі через мобільний, який тільки планує запуститися. В такому випадку основна функція MVP Bolt — замовити таксі з пункту А в пункт Б через смартфон. Я би до скоупу MVP включив мобільний додаток, де можна прокласти маршрут і дізнатися тривалість поїздки. Це потрібно користувачам. Далі — показ тарифу. Це якраз та цінність і унікальна пропозиція, яку Bolt давав би, якби був першим на ринку.

Водночас я б не включав:

  •       додаток для водіїв — у разі замовлення через додаток працівник компанії може зателефонувати водієві і сказати, куди потрібно їхати, щоб забрати клієнта, навіть називати тариф;
  •       час очікування авто — це зручно, але без інформації про місцезнаходження водія неможливо.
  •       онлайн-платежі — вони створюють «вау-ефект», але це достатньо витратна функція.
  •       інформацію про водія та авто — це важливо, але в MVP можна й без неї.

Мій must have для MVP — це аналітика. Успішні компанії побудовані на великих даних. Хороша новина в тому, що великі дані зараз доступні будь-кому. Особисто для мене важливі Facebook pixel та Google Analytics — за ними стоять гіганти інтернету. Особливо корисною інтеграція буде, якщо ви плануєте запускати рекламу. Інструментів безліч, їх варто підбирати, залежно від специфіки продукту.

Крок 3 — вайрфрейми

Після визначення скоупу MVP переходимо до вайрфреймів чи мокапів. Це — скелет майбутнього продукту, схематичне розміщення елементів на сторінці. Ви окреслюєте шлях, який повинен пройти користувач для отримання цінності продукту. Це суперсила Product Manager’а, інструмент, який дозволяє відобразити логіку роботи продукту. Його потрібно пропустити через себе й потім ділитися з командою та навіть показувати потенційним користувачам.

Інструментів, за допомогою яких можна створити мокап, чимало. Папір та олівець непогані, на перший час можна й ними користуватися. Але онлайн-інструменти все ж необхідно опанувати, наприклад: Basiliq, Framer, Sketch, Miro.

У мокапі має бути мінімум кольорів і реальний контент. Вайрфрейми передають в роботу дизайнеру, який розмістить елементи правильно, розбавить графікою тощо.

Крок 4 — продуктова команда/ MVT

Залежно від цілей продукту, команди можуть формуватися по-різному. Я пропоную сфокусуватися на Minimum Viable Team — мінімально необхідній команді для створення MVP версії продукту:

  • Product Manager — його роль — донести, що є цінністю. На стадії MVP він зобов’язаний взяти на себе роль девелопера, бізнес-аналітика й інші суміжні ролі;
  • UI/UX-дизайнер — він відповідає за вигляд продукту й простоту шляху отримання цінності для користувача;
  • веб-розробники — фронтенд, бекенд та інші. Можна знайти фахівців серед друзів, можна найняти фрілансерів.   

Пізніше до продуктової команди можуть входити Data Scientist, продуктовий дизайнер, контент-райтер й ін.

Крок 5 — розробка MVP

Все, що було до цього, важливо, але управління розробкою продукту — центральна роль PM. Спочатку це декомпозиція вебпродукту на завдання, потім — пріоритезація й далі — планування.

Декомпозиція означає розбити весь скоуп MVP на завдання для розробників. Так зв’являються user stories або ж, по-простому, — «таски». В описі тасків я пропоную дотримуватися наступного порядку: хто виконує щось та чому, як, та яку цінність отримає користувач, коли таска буде виконана. Наприклад, опис таски на сторінці EBazar може звучати так: «Як новий користувач я хочу створити акаунт за допомогою номера телефону, щоб мати змогу розміщувати свої оголошення».

Опис кожної таски повинен мати критерії завершеності завдання — це спрощує розуміння вимог і роботу для розробників. Їх потрібно провалідувати з розробниками на плануванні.

Наступний крок — пріоритезація. Є безліч способів для цього. Для MVP я пропоную базовий спосіб. Найважливіші таски позначати як «can not fail» — це ті завдання, які забезпечують користувачу отримання цінності від продукту. Далі — «must have» — те що потрібно продукту, без чого він не має сенсу. І останнє — «nice to have» — на стадії MVP це побажання PM, які можна реалізувати, якщо у розробників буде хороший настрій або у вас з’являться вільні ресурси. З «nice to have»  здебільшого формується продуктовий беклог. Це місце, де народжуються, живуть і часто помирають мрії кожного Product Manager’a.

Крок 6 — планування

Планування — це організація роботи. Й здебільшого роботу виконують спринтами. Спринт — це визначений проміжок часу (зазвичай тиждень чи два), протягом якого продуктова команда працює над вирішенням заздалегідь запланованих завдань. Найкраще спринт планувати всією командою. Мітинги можуть бути раз на день, на тиждень — все залежить від потреб.

І не забувайте, що ретроспектива важлива. Це час, коли обговорюють, що виконали, та як можна покращити роботу команди.

Для планування раджу використовувати Jira, Trello чи Notion. На мою думку, останній — найкращий для невеликих команд, Trello — найпростіший, а Jira підійде великим компаніям.

Найкраще, що можна зробити, аби навчитися створювати продукти — це почати. Зрештою, до роботи Product Manager’a подібні багато справ, які ми виконуємо в повсякденному житті: обираємо машину, виховуємо дитину абощо.