Product discovery: як знаходити ідеї для нових фіч

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

У цьому матеріалі HBJ розбирає, як працює discovery-процес на практиці. 

Що таке product discovery і чому він важливий

Product discovery — це валідація доцільності розробки. Якщо етап delivery відповідає за якість коду та терміни, то discovery фокусується на цінності для користувача. Сучасний стандарт — це dual-track agile, де дослідження та розробка йдуть паралельно.

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

Основні цілі процесу discovery

Головне завдання product discovery — замінити припущення фактами. Тоді команда може фокусуватися на чотирьох напрямках:

• контекст користувача. Замість абстрактних портретів — реальні обмеження та «болі» живих людей.

• валідація до розробки. Це суттєво дешевше за виправлення готового коду.

• пошук точок росту, нереалізованого потенціалу продукту та причин відтоку користувачів.

• мінімізація ризиків. 

  
  

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

Цей парадокс ілюструє кейс Джека Черевка, Product Manager в OBRIO:

«Ми запускали нове позиціонування й були впевнені, що „біль“ реальний: це підтверджували маркетинг-дослідження та ринок. Креативи працювали добре, але щойно юзери потрапляли в продукт — конверсія була занизькою, щоби звести юніт-економіку. Аналітика, дослідження та внесення змін у зони відтоку результату не показували. 

Тоді ми вирішили піти на інтерв’ю та зробити кількісне опитування. З’ясувалося, що ми неправильно зрозуміли основну ціль юзера. Користувачі заходили у воронку і відпадали, бо розуміли: це не те, що їм потрібно. Лише після аналізу справжніх Jobs to be Done ми повністю переробили продукт. Це дало нам одне з найкращих позиціонувань, яке успішно працює й досі».

Методи збору ідей для нових фіч

Щоб отримати об’єктивні дані, методи варто комбінувати. Серед способів: 

• інтерв'ю;

• опитування;

• аналітика;

• конкурентний аналіз. 

• Customer Journey Mapping (CJM).

Кожен метод має свою «ціну» та ефективність. Вибір залежить від контексту продукту, пояснює Джек Черевко.

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

Але якщо ми створюємо щось принципово нове, «щільність інсайтів» найвища в інтерв’ю. Разом з аналізом Quora, Reddit та TikTok це дає глибинне розуміння аудиторії, яке неможливо отримати, спостерігаючи за конкурентами».

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

Як перевіряти гіпотези перед запуском

Коли ідея пройшла відбір, її тестують найдешевшим способом без залучення розробки. Основні інструменти:

• Прототипування у Figma. Інтерактивний макет і тести на 5-7 користувачах виявляють помилки логіки до написання коду.

• A/B-тести. Порівняння варіантів інтерфейсу на реальному трафіку для прийняття рішень на основі цифр.

• Fake Door Test — це додавання кнопки неіснуючої фічі для заміру клікабельності. Нульовий інтерес — привід скасувати розробку без втрат.

• MVP для перевірки головного припущення.

  
  

Головне питання — коли зупинити дослідження й почати розробку. Джек наголошує: пріоритет — швидкість, а не «полірування»:

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

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

Окрім швидких тестів, Джек радить проводити попередній аналітичний чек перед запуском будь-якого дослідження:

«Ми використовуємо простий фреймворк: чи може продакт-менеджер або аналітик за 1-2 години знайти в наявних даних підтвердження масштабу ідеї? Часто гіпотеза на папері виглядає привабливо, але аналіз показує, що вона зачіпає лише 0,1% аудиторії. Навіть якщо ми отримаємо по цій групі 100% конверсію — це ніяк не вплине на загальну окупність продукту. 

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

Інструменти, які допомагають у discovery-процесі

Вибір інструментів не замінює стратегічного мислення, але структурує роботу. 

• Для збору фідбеку та пріоритезації зазвичай використовують Productboard. 

• Для візуалізації сценаріїв та CJM — Miro. 

• Для швидкого прототипування — Figma. 

• Для збору поведінкових даних, що стають фундаментом для гіпотез у it discovery — аналітичні платформи на кшталт Amplitude або Mixpanel.

Проте в екосистемних продуктах стандартного набору інструментів часто недостатньо. Оксана Голубець, Product Manager у My Kyivstar App, вважає найбільш недооціненим підходом аналіз мультисервісних когорт (multi-service cohorts):

«Більшість команд оптимізують окремі функції, що дає лише лінійний приріст. Справжній стрибок у Retention та LTV відбувається, коли користувач переходить з одного сервісу у декілька (наприклад, зв’язок + ТБ + інтернет). Ми використовуємо такі комбінації як "радар": якщо бачимо аномальну "липкість" (stickiness) на перетині послуг, це стає пріоритетом для product discovery. Наша мета — перетворити випадкову кореляцію на керовану причинність».

Як інтегрувати discovery в щоденний процес розробки

Discovery — це не передпроєктний етап, а постійна діяльність, що триває паралельно з написанням коду. Практично це реалізується через регулярність: 2-3 інтерв'ю на тиждень та щотижневі обговорення інсайтів усією командою. Залучення розробників до цього процесу критично важливе — розуміння реального «болю» клієнта дозволяє інженерам пропонувати точніші технічні рішення.

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

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

Для цього в команді інтегрували «голос клієнта» у Slack: відгуки та метрики аналізують ШІ-агенти, які структурують теми та визначають критичність фідбеку. 

Ще один інструмент для прискорення it discovery — інтерактивні Stories у додатку. У розділі «Зробимо додаток кращим» команда запускає немодеровані тести на конкретні когорти. Через сервіси на кшталт Lyssna користувачі взаємодіють із прототипами, а команда за лічені дні отримує тисячі відповідей. Так можна збирати success rate, час виконання завдань, міскліки,  хітмапи та інші дані. В результаті Discovery стає природним «спільнотворенням» продукту разом із його аудиторією.

Часті запитання (FAQ)

Чим product discovery відрізняється від product delivery?

Discovery — це про вибір: що і для кого будувати. Delivery — про реалізацію: як це зробити. У discovery працюємо з гіпотезами й невизначеністю, у delivery — з конкретними задачами і термінами. Тож обидва процеси мають іти паралельно.

Скільки часу має тривати discovery-процес?

Фіксованого терміну немає. Проста UX-гіпотеза може перевірятися за день, новий сегмент — тижнями. Орієнтир один: витрачати рівно стільки часу, щоб зняти ключовий ризик перед розробкою. 

Хто відповідає за генерацію ідей у команді?

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

Як зрозуміти, що ідея готова до розробки?

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