Product Discovery: що варто знати, перш ніж починати проєктувати?

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

Саме цю проблему покликаний вирішувати Product Discovery. Не для того, щоб команда стала абсолютно впевненою у всьому, це неможливо. Не для того, щоб виробити ще один великий документ, який ніхто не прочитає. І не для того, щоб нескінченно відкладати розробку. Мета значно практичніша: зменшити найнебезпечнішу невизначеність, перш ніж вона стане дорогою для зміни. Цифровий продукт не має починатись з екрана. Він має починатись з доказів.

Воркшоп може бути частиною discovery. Воркшоп не є discovery.

НЕ ЗУСТРІЧ

Discovery, це не зустріч

Одне з найпоширеніших хибних уявлень, що discovery, це воркшоп, кімната, дошка Miro, кілька стікерів, жменька зацікавлених сторін, і за дві години хтось виробляє customer journey і називає проєкт «дослідженим». Це не discovery. Воркшоп може бути його частиною. Так само як інтерв'ю, дослідження чи прототип. Але сам discovery, це процес зменшення невизначеності і зміни рішень на основі того, що дізнались.

Ця остання частина важить. Якщо дослідження виробляє двадцять сторінок висновків, і нічого в продукті не змінюється, команда, можливо, провела дослідження. Вона не обов'язково провела змістовний discovery. Корисний спосіб думати про це: питання, докази, інтерпретація, рішення. Щось відкрито, коли докази змінюють те, у що команда вірить, що має робити. Функція видаляється, цільова аудиторія зсувається, воркфлоу спрощується, припущення відхиляється. Іноді найцінніше відкриття просто: нам не варто це будувати. Це не провалений проєкт. Це може бути найуспішнішим результатом всього процесу.

ПРОБЛЕМА СПОЧАТКУ

Проблема перед рішенням

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

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

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

ЩО ЗНАХОДИТЬ

Що discovery реально намагається знайти

Корисний процес discovery не намагається дізнатись «все», це неможливо. Він шукає інформацію, що може суттєво змінити напрямок продукту, зазвичай у кількох категоріях. Люди: хто реально переживає проблему, хто ухвалює рішення, хто користується, хто платить, хто управляє системою внутрішньо, іноді пʼять різних груп. Проблема: що відбувається сьогодні, що робить це складним, як часто, кого це стосується, скільки це коштує. Контекст: коли зʼявляється проблема, що її оточує. Наявний обхідний шлях, особливо важливо, бо таблиця Excel, ланцюжок листів чи розмова у WhatsApp, що виглядає безглуздо ззовні, може існувати, бо вирішує щось, чого запропонований продукт ще не зрозумів. Бізнес-вплив: чому вирішення цього реально важить. І припущення, можливо, найважливіша категорія з усіх, бо discovery не про доведення, що команда права, а про з'ясування, де команда може помилятись.

ПОЧНИ З ПРИПУЩЕНЬ

Почни з припущень, не з питань

Перш ніж проводити інтерв'ю, сильна команда записує, у що вона зараз вірить: клієнти покидають чекаут, бо процес занадто довгий, дилерам потрібен мобільний інтерфейс управління інвентарем, корпоративним покупцям потрібні індивідуальні ціни, користувачі хочуть ШІ-рекомендацій. Це гіпотези, не факти, і ця різниця важить. Щойно припущення явні, їх можна ранжувати за важливістю, невизначеністю і вартістю помилки. Незначне припущення з низьким впливом не заслуговує на двотижневий дослідницький проєкт. Фундаментальне припущення про те, хто буде користуватись продуктом, може заслуговувати на найпершу розмову. Це один зі способів, як discovery лишається практичним, замість того щоб стати дослідженням заради дослідження.

ІНТЕРВʼЮ

Інтерв'ю потужні, і легко зробити їх неправильно

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

Люди, яких опитують, важать так само, як питання. Опитувати лише керівників, друзів чи людей, яким концепція вже подобається, поширена помилка, ці розмови корисні, але не автоматично репрезентативні. У клієнта одна перспектива, у продавця інша, у операційного менеджера третя, а адміністратор, що має справу з винятками, яких ніхто інший не бачить, може мати найважливішу інформацію з усіх. Для B2B продуктів це стає ще цікавішим, людина, що купує систему, може не бути людиною, що нею користується, а людина, що погоджує покупку, може не бути людиною, що страждає від наявного процесу. Розмови з зацікавленими сторонами розкривають дещо інше, організаційну реальність: які команди задіяні, де відбуваються передачі, які рішення політичні, не технічні. Технічно елегантний продукт може провалитись, бо організація не може його прийняти, тому discovery має розуміти організацію навколо продукту, не лише кінцевого користувача.

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

СПОСТЕРІГАЙ

Спостерігай за роботою, не лише питай про неї

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

Ми бачили саме цей розрив з роздрібним клієнтом, Sport Discount. Команда описувала свій сайт як такий, що працює добре, залученість виглядала нормально, нічого не здавалось терміново зламаним. Накладення даних теплових карт з Yandex Webvisor і Plerdy поряд з потоками поведінки Google Analytics розповіло іншу історію, більшість посилань у хедері майже не отримували кліків, а відвідувачі застрягали в місцях, яких ніхто не очікував. Ніхто нікого не вводив в оману в розмові, команда просто не бачила того, що показували записи, бо перестала помічати тертя роками раніше. Спостереження, це те, де discovery заробляє свою цінність в операційному софті і будь-якому проєкті з наявним, обжитим воркфлоу.

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

ВОРКШОПИ

У воркшопів є мета, не монополія на істину

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

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

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

ТЕАТР ВАЛІДАЦІЇ

Театр валідації, і як виглядає справжня валідація

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

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

НЕ КОЖНА ГІПОТЕЗА

Не кожна гіпотеза потребує прототипу

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

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

ТЕХНІЧНИЙ DISCOVERY

Технічний discovery теж має статись

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

Уяви концепцію, де клієнт налаштовує складний товар і отримує миттєву персоналізовану ціну. UX можна спроєктувати і прототипувати, але звідки реально береться ціна, що станеться, коли двигун ціноутворення недоступний, чи може CRM зберегти конфігурацію, чи може ERP її зрозуміти, чи бачить клієнт ту саму ціну всюди. Це не пізніші деталі реалізації, вони впливають на те, чи концепція продукту взагалі життєздатна, тому технічний discovery не має починатись після того, як Product Design «завершено». Він має інформувати його з самого початку, та сама дисципліна, розібрана з боку продукту у Product Design проти UX/UI.

СКІЛЬКИ ЧАСУ

Скільки часу це має зайняти, і коли зупинятись

Немає універсальної відповіді, сфокусована функція може потребувати днів, складна B2B система з кількома відділами і наявною інфраструктурою може потребувати значно довше. Але discovery не має ставати нескінченним дослідницьким проєктом, мета ніколи не була знати все, вона в тому, щоб знати достатньо для розумного наступного дорогого рішення. Це дає природну умову зупинки: чи може команда відповісти, з розумною впевненістю, яку проблему вирішує, для кого, як вона вирішується сьогодні, які основні обмеження, які припущення лишаються ризикованими, і що перша версія має явно не робити. Розумна впевненість, не впевненість повна. Очікування на повну впевненість може стати власною формою уникнення.

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

Чекліст рішень discovery

РЕЗУЛЬТАТИ

Результати мають змінювати рішення, не просто існувати

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

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

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

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

Від Discovery до Product Design

Щойно критичну невизначеність зменшено, питання змінюється. Discovery питає, що ми дізнались. Product Design питає, чим має стати продукт через це, точна межа й передача, яку ми розбираємо напряму у Product Design проти UX/UI. Дві дисципліни перетинаються, але не є однаковими, discovery створює докази і зменшує невизначеність, Product Design перетворює це знання на продуктову модель, UX/UI перетворює модель на досвід, цифрова архітектура визначає, як має працювати система, розробка перетворює систему на реальність. Послідовність рідко ідеально лінійна, і на кожному етапі нова інформація може рухати процес назад. Це не неефективність. Це навчання.

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

Discovery додає реальну роботу до початку розробки, це правда, і звучить як витрата. Але чесне порівняння ніколи не було вартість discovery проти відсутність вартості discovery, це вартість discovery проти вартості з'ясування тієї самої правди після реалізації. Дізнатись під час інтерв'ю, що клієнти не хочуть функцію, дешево. Дізнатись про це після трьох місяців розробки, дорого. Мета ніколи не була повністю прибрати невизначеність, вона в тому, щоб перемістити дешевий тип невизначеності раніше, до того, як він стане дорогим. Хороший продукт не починається в момент, коли хтось відкриває Figma. Він починається, коли команда може сказати, з розумною впевненістю, ось проблема, ось кого вона стосується, ось чому це важить, і ось рішення, яке ми готові ухвалити через те, що дізнались. Лише тоді наступне реальне питання стає, що взагалі проєктувати.

Чим Product Discovery відрізняється від kickoff-дзвінка чи збору вимог?

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

Чи потрібна кожному проєкту повна фаза discovery?

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

Яка найбільша ознака, що процес discovery провалився?

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

Чи може discovery статись після того, як проєкт вже почався?

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