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

Однак знайти правильну структуру може бути складно. Деякі менеджери проектів можуть приступити до виконання своїх обов'язків, і в компанії вже існує структура, яка діє вже давно... але вона не працює. Інколи компанія є абсолютно новою, і в цьому випадку доводиться пробувати різні структури, щоб знайти ту, яка підходить найкраще.

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

Але ось у чому справа – продукт – це СКЛАДНО. Як менеджер продукту, ви несете всю відповідальність, але маєте лише ілюзію влади.

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

Саме тут можуть допомогти фреймворки для менеджерів продуктів. Вони не тільки направляють вас і команду протягом усього процесу, але й є конкретними та доступними; ДИВІТЬСЯ, ОСЬ ЩО МИ РОБИМО, І ОСЬ ЧОМУ, — це те, що ви можете показати будь-яким скептикам у компанії.

Отже, без зайвих слів… ось величезний список фреймворків для управління продуктами.

Структура управління продуктом для DAYZ

Як зараз, вау

Структура How Now Wow, розроблена Gamestorming, є інструментом відбору ідей, який допомагає командам розробників продуктів визначити пріоритети того, що вони можуть запропонувати ринку.

Джерело: Gamestorming

Для оцінки ідей використовуються три критерії: «Як зараз», «Як зараз» і «Вау».

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

Тепер подивимося, як швидко можна реалізувати цю ідею.

Wow використовується для оцінки фактору «Wow!» функції або рішення.

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

Робота в зворотному напрямку, також відома як метод Amazon

Джерело: Modelthinkers.com

Структура «Working Backwards» досить проста. Ви працюєте у зворотному напрямку від готового до відправки продукту, повертаючись до вихідної проблеми. Ви починаєте процес із створення прес-релізу для вашого нового продукту, а потім працюєте у зворотному напрямку до лаконічного формулювання проблеми, яке можна використовувати як основу для досліджень, творчості та тестування.

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

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

Завдання, які потрібно виконати

Jobs-to-be-done (або JTBD) — це, перш за все, улюблена концепція тут, у tl;dv. Ми навіть написали цілу статтю про JTBD; вона нам настільки подобається. Концепція JTBD полягає у розумінні того, що мотивує ваших клієнтів купувати або потребувати продукт, і що користувачі можуть «найняти», щоб допомогти їм виконати «роботу», тобто досягти мети у своєму житті. Концепція JTBD зосереджена на клієнтах і допомагає їм виконувати завдання більш повноцінно, продуктивно та легко.

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

«Загалом, JTBD полягає у розумінні цілей, яких хочуть досягти люди, а досягнення цих цілей означає прогрес у їхньому житті».

Модель Кано

Модель Кано, розроблена в 1980-х роках японським дослідником Норіакі Кано, надзвичайно орієнтована на клієнта. В основі своєї суті вона допомагає вам глибше зрозуміти, чого шукають клієнти, шляхом класифікації функцій за п'ятьма категоріями:

Джерело: Prodify.com

Необхідні елементи: Це мінімальні вимоги, яким повинні відповідати ваші продукти, щоб бути життєздатними – вважайте це набором функцій, без яких ви не можете обійтися.

Характеристики продуктивності: це функції, які впливають на продуктивність продукту. Вони можуть бути необов'язковими, але допомагають поліпшити продукт.

Приємні дрібниці: це додаткові функції вашого продукту, які можуть порадувати ваших клієнтів.

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

Незадовільні фактори: це особливості, які клієнтам активно не подобаються. Можливо, без них було б краще.

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

Пріоритетність RICE

Джерело: ProductPlan

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

Акронім означає:

Охоплення: кількість людей або систем, на які вплине завдання.

Вплив: масштаб змін або поліпшень, які принесе виконання завдання.

Впевненість: Рівень впевненості в оцінці охоплення та впливу завдання.

Зусилля: Кількість часу та ресурсів, необхідних для виконання завдання.

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

Це до певної міри дуже спрощена модель, і хоча вона може дати дуже чіткі рекомендації, їй бракує нюансів.

Бізнес-модель Canvas

Бізнес-модель Canvas — це візуальний інструмент, який використовується для опису та аналізу основних елементів бізнес-моделі. Олександр Остервальдер представив його у своїй книзі «Створення бізнес-моделі». Модель складається з дев'яти блоків, які відображають основні елементи бізнес-моделі:

Сегменти клієнтів: це визначення різних груп клієнтів, на які орієнтується бізнес.


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


Канали: тут описується, як бізнес досягає своїх клієнтів та взаємодіє з ними.


Відносини з клієнтами: це визначає тип відносин, які бізнес має зі своїми клієнтами.


Джерела доходу: тут описуються джерела доходу для бізнесу.


Ключові ресурси: Це визначає найважливіші ресурси, необхідні для ведення бізнесу.


Ключові види діяльності: Тут описано ключові види діяльності, які підприємство повинно виконувати для реалізації своєї ціннісної пропозиції.


Ключові партнери: Тут перелічені ключові партнери та постачальники, на яких покладається компанія для реалізації своєї ціннісної пропозиції.


Структура витрат: тут викладено витрати, пов'язані з веденням бізнесу.

Бізнес-модель Canvas забезпечує структурований підхід до розробки та тестування нових бізнес-ідей. Вона допомагає організаціям чітко донести свою бізнес-модель до зацікавлених сторін. Вона охоплює майже всі можливі випадки і є дуже зручною для зацікавлених сторін, що робить її чудовою основою для переконання в необхідності більш глибоких інновацій (читай, БІЛЬШЕ РИЗИКУ!).

Дорожня карта подорожі клієнта

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

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

Зазвичай дорожня карта клієнтського шляху включає такі етапи:

Усвідомлення: Етап, на якому клієнт дізнається про компанію та її пропозиції.


Розгляд: Етап, на якому клієнт оцінює компанію та її пропозиції порівняно з конкурентами.


Придбання: Етап, на якому клієнт приймає рішення про купівлю продукту або послуги.


Доставка: Етап, на якому клієнт отримує та використовує продукт або послугу.


Лояльність: етап, на якому клієнт встановлює відносини з компанією і може стати постійним клієнтом.

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

Мінімально життєздатний продукт

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

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

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

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

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

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

AAARR, також відомий як Pirate Metrics

О, якби ж це все було справжнім піратським спорядженням. З папугою на плечі, шаблею, скринею Дейві Джонса. Але, на жаль! Фреймворк AAARR є піратським лише в частині AAAARR.

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

П'ять етапів цієї структури:

Придбання: Кількість нових клієнтів, яких вдалося залучити.


Активація: кількість клієнтів, які отримали цінний перший досвід використання продукту або послуги.


Утримання: Кількість клієнтів, які продовжують користуватися продуктом або послугою протягом тривалого часу.


Рекомендація: Кількість клієнтів, які рекомендують продукт або послугу новим клієнтам.


Дохід: Сума доходу, отриманого від клієнтів.


Ходіння по дошці: Ні. Це неправда. Ми просто дуже хотіли, щоб у грі були справжні пірати. 🙁

Метод «гачка»

Зачеплений Нір Еял

Метод Hooked — це система, розроблена Ніром Еялом, яка допомагає компаніям завоювати лояльність клієнтів. Ми навіть рекомендували книгу Ніра в іншому пості.

Модель Hooked Method базується на створенні продуктів або послуг, які є «гачками», що привертають і утримують увагу клієнтів та змушують їх повертатися за новими покупками. По суті, вони викликають залежність. Це спірне питання, але давайте продовжимо.

Згідно з моделлю «Hooked», успішний гачок складається з чотирьох ключових компонентів:

Тригер: будь-яка подія, яка спонукає клієнта до дії.


Дія: будь-яка дія, вчинена клієнтом у відповідь на тригер.


Винагорода: стимул, який заохочує клієнтів повторювати дії.


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

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

Навіть використання пошукової системи, такої як Google, або наявність Alexa у вашому домі, багато в чому віддзеркалює методологію Hooked. У вас є питання; ви не сидите і не розмірковуєте над ним, не йдете до бібліотеки і навіть не питаєте друга. Ви вводите його в Google або кричите: «Alexa, скільки горобців можна помістити в Dodge Charger?» Як у собаки Павлова, що слинить, відбувається подія, наприклад, думка, і ви тягнетеся до продукту.

Надмірна залежність від фреймворків?

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

Перш ніж ви зможете вирішити, яку платформу використовувати, вам потрібно заручитися довірою та підтримкою всіх зацікавлених сторін. Це можуть бути керівництво вищої ланки, інженери, дизайнери, маркетологи, навіть команда продажів, яка продовжує продавати нові функції, яких ще не існує (ми ❤️ ви дійсно продаєте!)

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

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

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

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

Зробіть одну річ простішою

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

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

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

Насправді, tl;dv забезпечити, tl;dv вся підготовча робота була виконана ще до того, як ви почнете думати про фреймворки. Продуктові команди використовують Zoom Google Meet для документування зустрічей, щоб легше відстежувати завдання, прогрес і тримати в курсі відсутніх співробітників. А найкраще те, що це безкоштовно!