Як Product Manager’у написати PRD — на прикладі реального продукту

PRD — один з основних документів у роботі продакт-менеджера. В ньому описують мету продукту, дослідження та сегментацію ринку, вказують очікувані результати. Завдяки такому документу стейкхолдери розуміють, яким вийде продукт, а команда чітко знає, як із ним працювати.

Павло Войцехівський в IT понад 8 років. Зараз він — Product Manager в компанії Lyft, раніше працював у WIX. Для Web Academy на прикладі власного продукту Павло розповів, як скласти PRD і на що звернути увагу.

Що таке PRD

Product Requirements Document (PRD) — це так зване ТЗ, документ, де чітко описані призначення, особливості, функціональність та поведінка продукту. PRD складає Product Manager, потім передає в роботу команді та ділиться ним зі стейкхолдерами.

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

PRD пишуть для того, щоб усі мали спільне бачення продукту.

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

Зміст PRD в продуктовій компанії

TL; DR (too long; didn’t read) — це короткий опис того, про що йтиме мова в документі. Зазвичай заповнюється наприкінці.
Бекграунд і мотивація — описуємо, для чого робимо продукт.
Дослідження ринку та сегментація.
Дослідження користувачів і їх проблем.
Постановка цілей і метрик: як будемо вимірювати успішність продукту.
Ключові елементи.
Роадмапа.
Вайрфрейми. Зазвичай в PRD не пишуть про те, як продукт працюватиме. Але в деяких компаніях продакт-менеджеру варто додавати вайрфрейм — скелет продукту. Він може бути намальований від руки або за допомогою певних інструментів (на курсі IT Product Management ми їх розглядаємо). Мені цей підхід подобається, бо тоді продакт-менеджер пропускає через себе бачення, як працюватиме продукт, краще сам його розуміє та може донести це бачення команді, стейкхолдерам. Так можна вже на ранній стадії побачити недоліки, які треба усувати.

Продукт Streetball.app та PRD для нього

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

Зараз у нас 1229 юзерів. Загалом користувачі створили 450 ігор.

Функціонал:

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

Структура PRD

Секція 1. Бекграунд та мотивація

Зараз існує проблема: ігор немає, бо не сезон. Але потрібно подумати про монетизацію продукту. Для цього команда збирається на брейншторм — це невіддільна частина роботи будь-якої команди.

Потенційна можливість заробити — це платні майданчики. Бо люди переходять з вулиць у зали й там вони зазвичай платять за оренду.

У нас були різні ідеї. Наприклад, додати карту з пінами баскетбольних кортів. Можна було запропонувати, щоб майданчики, які заплатять, отримували кастомні логотипи — це б виділяло їх з-поміж інших. Але корти не готові за це платити, бо це не приносить їм особливої користі.

Потім ми подумали, що потрібна CRM — система управління бронюваннями для власників платних майданчиків. Цього висновку ми дійшли, спілкуючись з представниками платних майданчиків. Вони сказали, що зараз немає системи управління резерваціями під їхні потреби. Сервіс, який використовують салони краси чи барбершопи, їм не підходить. Телеграм-канал — теж незручно, бо потрібно щодня робити дописи про те, які години вільні. Тому зупинилися саме на CRM.

Відповідно, Секція 1 у PRD може виглядати наступним чином. Я у цьому прикладі використовую для створення PRD Notion, але у великих компаніях часто працюють із Jira.

Найближчий курс IT Product Management

Секція 2. Дослідження ринку та сегментація

Тут слід дати відповіді на питання: «На що ми можемо розраховувати, коли робимо продукт?», «Чи є ринок взагалі, чи він дуже маленький?». Зазвичай продуктом ми задовольняємо потреби якогось сегменту ринку й нам необхідно цей сегмент виокремити. Вважати, що продукт роблять для всього ринку — помилка, яка насамперед виникає з вини продакт-менеджера. Нам потрібно знати свого користувача.

Розрізняють:

традиційні методи сегментації: за розміром, демографічними ознаками тощо;
альтернативні методики: Jobs To Be Done, Outcome Driven Innovation.

Ринкові сегменти Streetball.app:

1) платні баскетбольні зали (криті, просто неба);

2) платні зали для різних видів спорту;

3) шкільні та університетські зали, які здають приміщення в оренду (на жаль, нелегалізований спосіб);

4) баскетбольні майданчики в приватних житлових будинках.

Коли говоримо про CRM для залів, можемо сфокусуватися лише на перших двох — це фокус сегменти.

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

Типи досліджень:

кількісні — все, що стосується числової оцінки сегментів, які у нас є;
якісні — все, що стосується причинно-наслідкових зв’язків. Якісні дослідження знаходяться на перетині дослідження ринку і користувачів.

Кількісне дослідження для Streetball.app

Мета дослідження ринку — зрозуміти обсяг сегменту, який ми можемо покрити, щоб порахувати, який прибуток може приносити цей продукт.

Отже, ми дізналися, що:

Потенційне охоплення продукту — близько 200 залів. Краще, щоб цифра була песимістичною, а не оптимістичною, хоча це залежить від цілей. Коли ви хочете продати чи запітчити ідею, можна трохи збільшити цифри, якщо немає точних даних.
Вартість резервації за годину — від 50 до 800 грн. Все залежить від населеного пункту. Зазвичай, чим він менше, тим дешевше.
Кількість робочих годин на день — від 6 до 24.
Заповнюваність майданчиків (визначили через опитування) — від 30% до 80%.

Бізнес-модель Streetball.app

Це може бути:

підписка, залежно від кількості кортів або доступного функціоналу;
відсоток з кожної резервації.

Тут важливо прораховувати цифри, аби в компанії обґрунтувати, чому важливо робити цей продукт, а у стартапі — щоб запітчити й мотивувати команду.

Секція 3. Дослідження користувачів

Streetball.app — не просто продукт, а маркетплейс. І він має свою специфіку. Це масштабований продукт, який заробляє багато грошей, але складний у запуску. Окрім того, що в нас є визначений сегмент — платні зали, є ще інший сегмент — гравці. І зал — не наш користувач. Наші користувачі — власники залів, які управляють реєстрацією, отримують прибутки. Або ж адміністратори, які управляють бронюваннями.

Платні зали можна розділити на ті, що мають і не мають системи резервації. Тих, в яких немає такої системи, залучити буде простіше. А іншим доведеться проводити додаткові презентації.

Сегментація користувачів-гравців:

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

Дослідження користувачів — платних майданчиків

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

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

Все це так чи інакше стосується бронювання майданчика.

Визначення продуктових проблем

Щоб зробити якісний продукт, нам потрібно зрозуміти, які є проблеми у користувачів та як вони їх вирішують. Це називається визначення продуктових проблем. В основі методики лежить Jobs To Be Done і те, що походить з нього — Outcome Driven Innovation.

Jobs To Be Done — це «роботи», які користувачі повинні виконати, щоб досягти певної мети. В нашому випадку користувач — це адміністратор, який управляє резерваціями. Нам потрібно зрозуміти, які в нього є повсякденні «роботи».

Jobs To Be Done широко використовують, бо:

характеристика не належить користувачу чи продукту. Це основна функціональна «робота», яку намагається виконати користувач.
ринки й сегменти не визначаються навколо продуктів. Вони визначаються навколо груп людей, які намагаються виконати «роботу». Наш сегмент — це якраз адміністратори, які виконують цю «роботу».
користувачі — не покупці продукту, а виконавці «робіт».
потреби в продукті не є розмитими, прихованими та невпізнаними. Вони є показниками, за допомогою яких клієнти вимірюють успіх під час «роботи».
конкуренти — не компанії, які виробляють продукти, подібні до вашого. Конкуренти — будь-яке рішення, яке використовується для виконання «роботи».
клієнтські сегменти не базуються на демографічних показниках чи психографічних даних. Вони базуються на тому, що клієнти по-різному страждають, щоб виконати «роботу». Є методика, яка визначає та оцінює болі користувача через опитування. Розв’язувати треба ту проблему, яка болить найбільше.

Основні принципи дослідження:

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

Все це проводиться через дослідження користувачів. Як їх робити, ми більш докладно вивчаємо на курсі.

У випадку з баскетбольними майданчиками є адміністратор платного корту, який має певні болі. До них належить прийом замовлень вручну (через месенджери чи телефон), управління бронюванням, скасування бронювань, прийом оплати, блокування таймслотів для інших потреб, комунікація з користувачами, додаткові послуги (оренда м’яча, форма, вода). Процес бронювання — це вже біль, бо користувачі можуть захотіти забронювати корт в неробочий або в уже заброньований час. Тобто адміністратор просто витрачає ресурси на те, аби це пояснити.

Ще одна проблема — пошук нових клієнтів чи низький відсоток заброньованості. Витрати на онлайн-присутність теж можна віднести до переліку болей.

Які виграші принесе CRM

Це прибуток від резервації, позитивні відгуки, соціальна функція, нові знайомства, потворний досвід.

На скріншоті нижче наведений профіль нашого користувача і його Jobs To Be Done. На основі цього можемо сформулювати Value Propositions Canvas. По суті, нам треба запропонувати функціонал — CRM. Можна подумати про календар з резервацією, налаштувати обмеження часу на безоплатне скасування резервації, прийом платежів онлайн, створити лист очікування, щоб зменшити ризики скасування бронювань.

Далі може йти інтеграція з Google Business, використання push-сповіщень чи інших каналів комунікації. Працюємо над тим, щоб було менше тяганини з розрахунками. Можемо додати автоматичне нагадування користувачам про гру тощо.

Написання use cases

Описуємо, як мінімум, основні use cases, які покриватиме продукт. Приклад, як це можна зробити, наведений на скріншотах нижче. РО, Р1, Р2… — це пріоритетність.

Секція 4. Цілі продукту

Мета продукту — максимізація зайнятості платних баскетбольних майданчиків. Перш за все, це цінність для них. Але це цінність і для нас: чим більше резервацій, тим більше заповнених майданчиків, гравців і, відповідно, наших доходів. Про маркетплейси варто говорити окремо, бо це складна система зі своїми бізнес-моделями, метриками, проблемами.

Є різні методики постановки цілей продукту:

SMART (specific, measurable, attainable, relevant, time-bound);
OKRs (objective and key results). Вона була сформована ще у 1983 році. Її суть полягає в тому, що є цілі й ключові результати. Останні повинні бути вимірювані. В кінці періоду, протягом якого ми вимірюємо результати, ми повинні сказати без аргументів, чи досягли цілі, чи ні. Лише «так» чи «ні» — без жодних суджень.

У нас новий продукт. Його ціль — створення ефективної системи управління бронюваннями, яка буде корисна для платних майданчиків. Наш time-frame — три місяці. Тобто за наступні три місяці ми маємо запустити MVP системи резервації з можливістю оплати онлайн. Це й буде наш ключовий результат. Другий ключовий результат, який може іти в паралелі, — підписаний договір з п’ятьма баскетбольними майданчиками про використання системи управління резерваціями SBA. Третій — збільшити наповненість платних майданчиків на 20%.

Легко ставити ключові результати, коли є історичне знання про продукт. Але коли немає цифр, ми ставимо таргет, який буде достатньо амбітний. Якщо ми досягли цілі, значить, вона не була амбітна, тож наступного разу ми це врахуємо і поставимо амбітнішу. Якщо не досягли, теж скоригуємо — це не означає, що команда погано працювала. Це має слугувати приводом для постановки більш точних OKRs на подальші періоди.

Метрики успішності продукту

Тут використовують поняття Northstar — Полярна зоря. Це основна метрика нашого продукту.

Наша Northstar — кількість годин, заброньованих через SBA, а також кількість робочих годин майданчика мінус кількість годин, заброньованих вручну. Визначаємо в період за тиждень. Бо кількість заброньованих годин через додаток — це та цінність, яку ми приносимо користувачам. Віднімаємо показники броні вручну, бо ми на цьому не заробляємо: не ми принесли цю цінність, і комісію з цього не отримуємо.

Інші метрики:

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

Секція 5. Ключові елементи

Це те, що потрібно зробити чи збудувати, аби досягти поставлених цілей.

Бекенд-сервіс:

CRUD сервіс для управління резерваціями;
інтеграція платіжної системи.

Фронтенд для власників майданчиків:

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

Додаток SBA для користувачів:

пошук платних майданчиків;
резервація тайм-слоту та оплата онлайн.

Секція 6. Роадмапа

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

Далі визначаємо пріоритетність завдань: потрібно зрозуміти, що ми робимо в поточній версії продукту, а що в наступній.

На основі списку завдань будуємо роадмапу.

Коли все це сформували, записуємо (TL; DR).

Секція 7. Вайрфрейми

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