Product Discovery

Безперервно, а не фазою

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

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

Чому це мають бути троє

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

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

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

Дерево можливостей і рішень

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

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

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

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

Від ідеї до перевірки: карта припущень

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

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

Чотири ризики

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

• Цінність — чи це комусь потрібно?

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

• Зручність — чи зможуть розібратися?

  П’ятеро людей, які пробують виконати задачу на прототипі, виявлять більшу частину задовго до розробки. Дивіться, як вони роблять; не питайте, чи було зрозуміло.

• Здійсненність — чи можемо ми це зробити?

  Обмежений у часі spike, а не дискусія. Інженери мають бути в discovery заради цього, а не отримувати рішення постфактум.

• Життєздатність — чи варто це нашому бізнесу?

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

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

Драбина перевірок, від найдешевшої

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

Як це виявляється в реальній поставці

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

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

Де він вироджується

• Інтерв’ю, що питають, чого людина хоче, замість того, що вона робила востаннє.
• Фаза discovery з датою завершення повертає його до збору вимог.
• Можливості, сформульовані як фічі, — тоді кожна альтернатива під ними є варіацією однієї ідеї.
• Одне рішення на можливість — отже, нічого насправді не порівнювали.
• Інженерів не залучають, доки рішення не обрано, — здійсненність стає пізнім сюрпризом.
• Ручний рекрутинг — і саме тому ритм помирає в перший же напружений тиждень.
• Дослідження, яке не змінить понеділка, але все одно проводиться, — це прокрастинація з методологією.

Коли це застосовувати

Пов’язані сторінки

• МенеджментРоадмапінгРоадмапінг — це робота з донесення того, куди рухається продукт і чому. Складне тут не намалювати таймлайн, а встояти перед проханням зафіксувати фічі за датами: це прив’язує вас до обсягу робіт саме тоді, коли ви найменше знаєте, чи спрацює задумане. На цій сторінці — формат на основі результатів, для кого який роадмап, як упорядковувати пункти і коли дата справді потрібна.
• МенеджментМетрики та KPIМетрика — це число, за яким команда керує, а KPI — той невеликий набір, за яким вона погодилася, щоб її оцінювали. Майстерність не в тому, щоб узяти вражаючі метрики, а в тому, щоб побудувати ланцюг від того, на що команда може вплинути цього тижня, до того, що потрібне бізнесу цього року, — і розуміти, на якій саме ланці ви дивитесь. На цій сторінці — цей ланцюг, закон Гудхарта й обмежувачі, два фреймворки-чеклісти та як читати число, не обманюючи себе.
• МенеджментUser StoriesUser story — це короткий опис потреби з погляду користувача, написаний, щоб почати розмову, а не замінити її. Шаблон — найменш важлива частина; справжня навичка полягає в нарізанні роботи так, щоб кожна історія давала користувачеві щось справді придатне до використання. На цій сторінці — три C, критерії приймання, шість способів розділити історію, story mapping, spike та призначення story points.