Як ефективно управляти продуктом у B2B

Привіт, мене звати Макс Куниця, я Group Product Manager у продуктовій IT-компанії iDeals. У статті поділюся нашим досвідом побудови продуктового процесу та докладно опишу кожен з етапів.

Матеріал стане у пригоді всім, хто прагне налагодити управління продуктом та підвищити ефективність процесів. Зокрема тим, хто працює у ніші B2B-рішень, адже створення продукту для бізнесу і для споживача відрізняються. Звісно, продуктовий менеджмент у B2B схожий на B2C: тут теж є користувацькі проблеми та досвід, гіпотези та вимоги, цілі й метрики. Але є й важлива відмінність: у В2В рішення про придбання продукту можуть ухвалювати одні люди, а користуватися ним інші.

Тому витрати на початок користування продуктом для бізнесу значно більші, ніж на споживчому ринку. Однак компаніям складніше відмовитися від продукту, ніж окремим користувачам. Понад те, у В2С-сегменті вхідний трафік, як правило, значно вищий.

Ми в iDeals маємо досвід створення рішень для бізнесу з 2008 року. Свій процес будували передусім для флагманського продукту компанії — віртуальних кімнат даних (VDR), інструмента для захищеної спільної роботи з конфіденційними документами. Нещодавно вийшли на ринок ПЗ і в категорії Board Management. Уточнюю це, щоб приклади далі були більш зрозумілими.

Тож розберімось у нашому продуктовому процесі.

Ілюстрація Марії Рибак

Для чого потрібно налагоджувати процес

Продуктовий процес:

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

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

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

Ідея

Усе починається з ідеї. Вона може з’явитися з різних джерел. Наприклад:

  • аналізу ринку та конкурентів;
  • якісних досліджень користувачів і клієнтів (інтерв’ю, опитування тощо);
  • кількісних досліджень користувачів і клієнтів (Heap, BigQuery, Google Analytics тощо);
  • зворотного зв’язку від потенційних і нинішніх клієнтів і користувачів;
  • ідей від стейкголдерів або інших команд;
  • внутрішніх запитів від інших команд;
  • висновків після вимірювання показників успіху.

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

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

Приклади ідей

Привіт!
А чи можна якось побачити всі свої нотатки з кімнати даних? Я хотів би бачити їх в одному місці, щоб не клікати по різних файлах, де я їх робив.

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

Гіпотеза

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

Яку проблему вирішуємо? Ідея у форматі гіпотези: тут є інформація про аудиторію, проблему та умови, за яких вона виникає.

На кого вплине? Більш докладна інформація про аудиторію чи персону, яка стикається з проблемою.

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

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

Гіпотеза може змінювати, доповнювати чи розширювати суть початкової ідеї. Часто так і відбувається. Ідеї нерідко надходять з джерел, які не володіють усіма знаннями про продукт. Є певні ситуації, коли задум у своєму первісному вигляді не працюватиме або приховуватиме геть інші проблеми — у порівнянні з тими, на які вказує першоджерело.

На цьому етапі до процесу додається пріоритезація. Вона покликана боротися із суб’єктивізмом і орієнтувати на роботу лише з найбільш впливовими та важливими ідеями. Для цього в iDeals ми використовуємо модифікований підхід RICE від Intercom (reach, impact, confidence, effort). Його ми доповнили ще одним параметром — strategy (S) — і в підсумку отримали RICSE:

  • Reach (охоплення) визначає, на яку кількість користувачів, транзакцій чи, як у нашому випадку, проєктів (віртуальних кімнат даних) вплине розв’язання проблеми з гіпотези.
  • Impact (вплив) — умовний коефіцієнт того, наскільки сильно вирішення проблеми з гіпотези вплине на користувацький досвід аудиторії. Для цього ми застосовуємо шкалу від 0 до 3 з кроком у 0,25. Кожен з кроків позначає силу впливу: від 0 (немає впливу) до 3 (дуже сильний вплив).
  • Strategy (стратегія) показує, наскільки це рішення вкладається у наші довгострокові плани. Тут ми використовуємо три значення стратегії: 0,3 — не відповідає стратегії; 0,8 — часткова відповідність; 1 — повна відповідність.
  • Effort (трудовитрати) — високорівнева оцінка, для якої ми використовуємо числа Фібоначчі. До них прив’язані календарні періоди: 1 — до 2 тижнів, 3 — до місяця; 5 — до кварталу; 8 — до пів року; 13 — пів року та більше (або за фактом, коли оцінка неточна, але зрозуміло, що рішення потребує значних вкладень).
  • Confidence (впевненість) — умовний коефіцієнт впевненості в усіх інших показниках. Він набуває значення від 0,1 до 1. Зазвичай ми використовуємо крок у —0,2 для кожного показника, який викликає сумніви. Наприклад, якщо ми не певні щодо охоплення, то confidence отримує індикатор у 0,8; якщо ще й у впливі — тоді 0,6 тощо.

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

Приклад гіпотези

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

На кого вплине? Користувачі з увімкненою двофакторною аутентифікацією, незалежно від ролі та прав доступу.

На що вплине?

  • Зменшення витрат на посилання кодів для двофакторної аутентифікації через СМС і дзвінки.
  • Зменшення кількості випадків, коли через неможливість отримати код користувачу не вдається увійти в систему.
  • Підвищення рівня задоволеності користувачів.

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

Валідація

Під час валідації ми намагаємося отримати якомога правдивішу оцінку всіх показників RICSE, а також максимально наблизити confidence (впевненість) до 1. Тож весь етап валідації — це спроба «оцифрувати впевненість» і оцінити невизначеність. На цьому етапі ми залучаємо продуктового аналітика, разом збираємо дані й будуємо перші прогнози щодо гіпотези.

Тут ми маємо два можливі шляхи до рішення.

  1. У нас є всі необхідні дані, щоб підтвердити гіпотезу та рухатися далі.
  2. У нас бракує даних для підтвердження гіпотези.

У першому випадку ми перевіряємо ретроспективно, з огляду на вже наявні дані. Для цього використовуємо типові інструменти: Google Analytics, Heap, BigQuery; опитування — для кількісних даних, інтерв’ю, запити та відгуки клієнтів — для якісних.

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

На закінченні етапу маємо оновлені показники RICSE і звіти, Excel-таблиці, записи інтерв’ю та інші дані, які підтверджують їх.

Гіпотези з найбільшою пріоритезацією далі опрацьовуємо.

Приклад гіпотези та валідації

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

Дані для валідації: за інформацією за 4-й квартал 2020 року, близько 30% всіх проєктів мають більше як один архів у форматі ZIP, RAR або 7Z, але при цьому тільки у 1,7% проєктів з архівами хоч раз використовували функцію розархівування.

Рішення (PRD)

Цей етап цілком і повністю присвячений самому рішенню і створенню product requirements document (документа з вимогами до продукту). Він складається з таких кроків:

  • дослідження ринку щодо того, як проблему в основі гіпотези вирішують прямі та непрямі конкуренти, а також продукти з інших галузей;
  • визначення людей, які є покупцями та користувачами рішення;
  • визначення можливих флоу, які є типовими для різних персон;
  • створення користувацьких історій (User Stories) для розуміння повної картини і всіх нюансів;
  • обговорення вже отриманих напрацювань з технічною командою щодо того, чи є це все можливим, чи потрібно проводити додаткові технічні дослідження або створювати технічні концепти (proof of concept);
  • детальна робота з користувацьким досвідом та інтерфейсом (UX/UI);
  • опрацювання UX/UI та консультації з технічною командою можуть бути ітеративними;
  • створення динамічних прототипів для підтвердження життєздатності та зручності розробленого рішення з реальними або максимально схожими за профілем користувачами;
  • визначення необхідних маркетингових активностей: комунікація через імейл/продукт; матеріали для маркетинг-сайтів, вплив на ціни й тарифні плани тощо;
  • визначення індикаторів і показників успіху, які будуть вимірюватися після запуску рішення, для розуміння, що воно справді розв’язує первинну проблему, є корисним для користувачів і цінним для бізнесу.

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

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

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

Таким чином виходить, що формула RISCE отримує підтвердження за всіма елементами. Гіпотези/рішення знову пріоритезуються вже з огляду на всі змінні у формулі.

Дорожня карта (Roadmap)

Наприкінці кожного кварталу продакт-менеджери разом з інженерними менеджерами та командами складають дорожню карту (Roadmap) на найближчий квартал для кожної технічної команди (а їх у нас 6). До неї потрапляють уже підготовлені рішення. Іноді — й гіпотези для технічного або продуктового опрацювання, які мають найвищі значення пріоритету за RICSE.

Також виділяємо частину інженерного часу (до 15–20%) на доопрацювання, пов’язані з інструментами для внутрішніх споживачів (команди підтримки, продажів тощо), технічним боргом та ідеями, які не мають твердого підтвердження даними, але здаються перспективними.

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

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

Імплементація

В iDeals команди працюють за підходом, який дуже близький до Scrum, з усіма відповідними артефактами: це ітеративна розробка, щоденні зустрічі на 5–10 хвилин для швидкої синхронізації, щотижневі зустрічі для обговорень нових користувацьких історій, що два тижні — планування чергової ітерації (спринту) і проведення ретроспективи щодо попередньої.

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

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

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

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

Верифікація

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

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

Висновки

Незалежно від того, створюєте ви продукт у B2B чи B2C, він повинен бути зрозумілим, простим у використанні та ефективним. В обох випадках користувачі — такі ж люди, як ви. Тому для роботи з продуктом потрібне спілкування з ними, дослідження і відстеження різних метрик.

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

Як влаштований продуктовий процес у вашій компанії? Розкажіть у коментарях!

P. S. Дякую Дмитрові Ковалю за допомогу в написанні статті.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось8
До обраногоВ обраному6
LinkedIn

Схожі статті




2 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Спасибо, что поделились опытом.

Дякую за корисну статтю.

Підписатись на коментарі