Product Discovery

Квартал discovery на одному екрані — готовий

Більшість тих, хто шукає product discovery, хоче побачити, що команда насправді робить і що з цього виходить. Ось один квартал такої роботи — для клієнтської команди інтернет-магазину, що проходить крізь сторінки розділів «Декомпозиція» і «Процес релізу». Саме цей квартал дав епік про повторні замовлення і key result, якому той служить. Наступні розділи посилаються на рядки за номерами.

1. 1.Результат, команда, ритм

   1. 1.1Результат: повернення на 2-му тижні з 18% до 25% — продуктовий результат, який згодом записали як key result 1.1 на сторінці про OKROKRObjectives and Key Results — ціль із вимірюваними результатамиМетод постановки цілей, що поєднує одну якісну ціль із двома-п’ятьма вимірюваними key results, які доводять, що її досягнуто; їх ставлять і переглядають щокварталу. Він перестає працювати, коли key results стають списком задач або оцінки впливають на оплату.Докладніше в статті →Усі терміни
   2. 1.2Тріо: продакт-менеджер, дизайнер і техлід — усі троє на кожному інтерв’ю
   3. 1.3Два інтерв’ю на тиждень, у вівторок і четвер о 10:00. Клієнтів запрошує підказка, яку показують після третього замовлення, з ваучером за участь
   4. 1.4Дерево перемальовують кожні чотири тижні, після восьми інтерв’ю

2. 2.Що показали шістнадцять інтерв’ю і дані замовлень — словами клієнтів

   1. 2.1«Я купую те саме кожні два тижні, і знайти кожну річ знову — ціла вічність» — 11 інтерв’ю з 16. У даних замовлень 58% повторних замовлень містять щонайменше 70% якогось попереднього кошика
   2. 2.2«Я згадую про замовлення, лише коли щось закінчилося» — 7 з 16
   3. 2.3«Коли треба одну річ, доставка коштує більше за неї» — 6 з 16
   4. 2.4«Я ніколи не певен, що ціна та сама, що й минулого разу» — 5 з 16
   5. 2.5«Оплата не пройшла, і я не знаю, чи з мене списали гроші» — 4 з 16

3. 3.Цільова можливість — і порівняні рішення

   1. 3.1Ціль: 2.1 — найчастіша і єдина, яку дані замовлень підтверджують самі
   2. 3.2A — Повторне замовлення з історії: минуле замовлення потрапляє в кошик
   3. 3.3B — Збережені кошики: іменований список, який клієнт тримає
   4. 3.4C — Купівля одним дотиком: минуле замовлення оформлено й оплачено одразу
   5. 3.5D — Підписки з доставкою раз на кілька тижнів — відкладено як окрему ставку

4. 4.Припущення під A — наскільки кожне потрібне і що відомо

   1. 4.1Цінність: постійні клієнти повторюють більшу частину попереднього кошика — відомо, з 2.1
   2. 4.2Цінність: вони шукатимуть це в історії замовлень, а не в пошуку, — невідомо
   3. 4.3Зручність: вони помітять, чого немає в наявності і що змінило ціну, — невідомо
   4. 4.4Здійсненність: ERP може віддавати залишок кожного товару в реальному часі — невідомо; питання техліда
   5. 4.5Життєздатність: замовлення підтверджують кнопкою, яка каже, що це оплата, і з підсумком, показаним безпосередньо перед нею, — відомо, бо цього вимагає закон, і це виключає C

5. 5.Перевірки — кожен критерій успіху записано до запуску

   1. 5.1Дані замовлень, дві години, для 4.1: критерій — щонайменше 40% повторних замовлень повторюють попередній кошик; результат 58%
   2. 5.2Фальшиві двері, тиждень, 5% постійних клієнтів, для 4.2: кнопка «Повторити» в історії замовлень, що відкриває повідомлення «скоро буде». Критерій — щонайменше 8% відвідувачів історії натискають її; результат 14%
   3. 5.3Прототип, п’ятеро клієнтів, для 4.3: критерій — четверо з п’яти повторюють замовлення й помічають відсутній товар; результат — четверо з п’яти, але двоє з п’яти не помітили зміненої ціни
   4. 5.4Спайк, два дні, для 4.4: записано в епік як його рядок 4.3 — відповідь має бути до того, як фічу 1 почнуть будувати

6. 6.Рішення

   1. 6.1Будувати A як фічу 1 епіка про повторні замовлення, з історією 1.4 — змінену ціну показано до оплати, — доданою через 5.3
   2. 6.2B стає фічею 2. Нагадування, для 2.2, стають фічею 3 — її будують, лише якщо зрушать випереджальні показники
   3. 6.3C відкинуто: воно не проходить 4.5, а замовлення, зроблене помилково, не скасувати вимкненням прапорця, — рядок 4.3 плану релізу
   4. 6.42.3 передано команді ціноутворення; 2.5 — до цілі 2 на сторінці про OKR, оплати
   5. 6.5Результат лишається на наступний квартал. Discovery щодо 2.1 зупиняється, коли виконано умову закриття епіка

Discovery поруч із delivery, а не перед нею

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

Тож вони йдуть поруч. Дезіре Сай описала один спосіб у травні 2007 року — з досвіду дизайн-команди Alias: дизайнери працювали на цикл попереду розробників і перевіряли дизайн наступного циклу, поки будувався поточний. Джефф Паттон назвав цей підхід dual-track, а Марті Кейган популяризував його у вересні 2012 року з визначенням, яке варто запам’ятати: «Трек discovery — про швидке створення перевірених елементів беклогу продукту, а трек delivery — про створення програмного забезпечення, придатного до релізу».

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

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

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

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

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

Корінь має бути правильним видом числа. Торрес розрізняє три. Бізнесовий результат, як-от виручка, важливий для компанії, але на нього впливає забагато чинників, щоб одна команда могла ним кермувати. Метрика використання, як-от «натискання кнопки “Повторити”», завузька, бо вже називає рішення. Продуктовий результат — посередині: він вимірює поведінку клієнтів, на яку команда може впливати, і лишає рішення відкритим. «Я люблю бачити продуктовий результат угорі», — пише вона. Рядок 1.1 — саме такий: повернення на 2-му тижні, які могло б зрушити будь-яке з рішень від A до D.

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

Інтерв’ю — історії про минуле, а не думки про майбутнє

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

Книжка Роба Фіцпатріка «The Mom Test» (2013) названа на честь проблеми: навіть ваша мама збреше вам про вашу ідею — з доброти. Її три правила вміщаються на картку. Говоріть про їхнє життя, а не про вашу ідею. Питайте про конкретику з минулого, а не про загальне чи думки про майбутнє. Говоріть менше, слухайте більше.

Дві звички перетворюють інтерв’ю на дерево. Після кожної розмови тріо пише одну сторінку — хто клієнт, яку історію він розповів, які в ній можливості, його словами, — Торрес називає це знімком інтерв’ю (interview snapshot). І можливості рахують по всіх інтерв’ю, а не пригадують: «11 з 16» у рядку 2.1 — це підрахунок, а підрахунок переживає останнє яскраве інтерв’ю, чого не скажеш про пам’ять.

Чотири ризики — і припущення під рішенням

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

Рядок 4.5 — випадок, що зазвичай спливає надто пізно. За споживчим правом ЄС онлайн-замовлення, яке зобов’язує клієнта платити, має оформлюватися кнопкою, «позначеною… лише словами “замовлення з обов’язком оплати” або відповідним однозначним формулюванням», і з підсумком, показаним безпосередньо перед нею. Якщо це не так, клієнт «не зв’язаний договором чи замовленням». Це стаття 8(2) Директиви 2011/83/EU. Купівля одним дотиком зі списку замовлень не проходить цієї вимоги за самою конструкцією, і одне питання юристам вирішило те, що інакше виявив би місяць розробки.

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

Рішення рідко буває хибним цілком. Воно хибне тому, що не тримається одне переконання під ним. Карта припущень, яку Девід Бленд і Александр Остервальдер описали в книжці «Testing Business Ideas» (2019), — це крок між «ми могли б це збудувати» і «ось що ми перевіримо». Тріо записує кожне переконання, від якого залежить рішення, і розміщує його на двох осях: наскільки ідея від нього залежить — якщо воно хибне, ідея вмирає? — і скільки доказів уже є.

Перевіряти варто лише важливі припущення без доказів: 4.2, 4.3 і 4.4. На важливих із доказами, 4.1 і 4.5, можна безпечно будувати. Тріо магазину записало одинадцять переконань, і шість потрапили в нижню половину: правдиві вони чи ні, ідея виживе. Сортування забрало хвилин двадцять і одну стіну — і саме тому в групі 5 чотири перевірки, а не одинадцять.

Перевірки — від найдешевшої до найдорожчої

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

Нижній щабель дорожчий, ніж здається. Щоб відрізнити повернення на 2-му тижні в 18% від 19% зі звичною впевненістю — 5% хибнопозитивних результатів і 80% шансу помітити справжній ефект, — A/B-тесту потрібно близько 24 000 клієнтів у кожній групі. Для 18% проти 20% — близько 6000. Магазин із 3000 постійних клієнтів на тиждень чекав би першої відповіді шістнадцять тижнів. Тому в кварталі магазину не було A/B-тесту: рішення, яких він потребував, стосувалися того, чи будувати, а на це фальшиві двері відповіли за тиждень.

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

П’ять продуктів — і перевірка, яка обійшлася б дешевше

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

Zappos і Dropbox — цінність перевірили до того, як щось збудували

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

У березні 2008 року Дрю Г’юстон опублікував коротке демовідео Dropbox, розраховане на спільноту Digg, — ще до того, як продукт був для неї готовий. За його словами, які цитує Ерік Ріс у «The Lean Startup», «наш лист очікування бети буквально за ніч зріс із 5000 до 75 000 людей». Записатися в лист очікування коштує небагато, але все-таки щось коштує, і сімдесят тисяч людей, що це зробили, — це фальшиві двері з дуже широкою рамою.

Juicero і Quibi — спершу збудували, потім спитали

Juicero залучила близько $120 мільйонів, щоб збудувати під’єднаний до мережі прес, який вичавлював сік із власних запечатаних пакетів. На питання здійсненності відповіли ґрунтовно: машина була вражаюча. Цінність ніхто не перевірив на верхньому щаблі. У квітні 2017 року журналісти Bloomberg вичавили пакети руками й отримали майже стільки ж соку, і прес за $400 став виглядати непотрібним. 1 вересня 2017 року компанія зупинила продаж преса й пакетів і запропонувала повернення коштів упродовж 90 днів.

Quibi запустилася 6 квітня 2020 року з $1,75 мільярда залучених коштів і бібліотекою преміальних шоу в епізодах по десять хвилин чи менше, створених для телефонів у дорозі. Про закриття оголосили 21 жовтня. Відкритий лист засновників назвав дві можливі причини: «бо сама ідея була недостатньо сильною, щоб виправдати окремий стримінговий сервіс, або через наш таймінг». Після $1,75 мільярда компанія не змогла відрізнити своє припущення про цінність від невдачі. Перевірка, задумана розрізнити ці два варіанти, коштувала б мізерну частку цієї суми.

Bing — ідея з низьким пріоритетом

Цю історію розповідають Рон Кохаві й Стефан Томке в Harvard Business Review (2017). Працівник Bing запропонував змінити, як показуються заголовки реклами. Збудувати це можна було за кілька днів, але ідея була однією із сотень, програм-менеджери визнали її низькопріоритетною, і вона «пролежала понад шість місяців». Потім інженер запустив простий A/B-тест. Виручка зросла на 12% — понад $100 мільйонів на рік лише в США, — і це стала найприбутковіша ідея в історії Bing. Експерти погано вгадують, які ідеї спрацюють, — зокрема й власні.

Де він вироджується — і чого discovery не може

Чесна причина, чому discovery пропускають, — він виглядає як «нічого не випускаємо». Квартал, у якому збудували чотири фічі, відчувається продуктивним; квартал, у якому перевірили вісім ідей і збудували дві, здається повільним — рівно доти, доки хтось не порахує, що зробили ті чотири. Кохаві й Томке наводять числа з контрольованих експериментів: «У Google і Bing лише приблизно 10–20% експериментів дають позитивні результати. У Microsoft загалом третина виявляється ефективною, третина дає нейтральні результати, а третина — негативні». І це ідеї, досить добрі, щоб дійти до експерименту.

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

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

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

• МенеджментРоадмапінгРоадмапінг — це робота з вирішення й донесення того, куди рухається продукт, у якому порядку й чому, із зобов’язаннями щодо результатів і дуже небагатьох дат. Складне тут не намалювати таймлайн, а відмовитися обіцяти фічі за датами саме тоді, коли команда найменше знає, чи вони спрацюють. Сторінка починається з готового роадмапу однієї команди; далі — що таке роадмап і два способи, якими датований роадмап помиляється, Now/Next/Later, три читачі й три версії, чотири способи впорядкувати пункти, дати після discovery, дві публічні обіцянки й дві команди, що змінили формат, і де все це вироджується.
• МенеджментМетрики та KPIМетрика — це число із записаним визначенням, за яким команда керує, а KPI — одна з небагатьох метрик, за якими команда чи компанія погодилася, щоб її оцінювали. Майстерність — у тому, щоб збудувати ланцюг від того, що команда може зрушити цього тижня, до того, що потрібне бізнесу цього року, тримати кожне число чесним під тиском і читати його, не обманюючи себе. Сторінка починається з готового набору метрик однієї команди; далі — слова й ланцюг, як записати визначення, закон Гудхарта й захисні метрики, одне число нагорі й дерево під ним, як читати число, чотири числа, що ввели в оману своїх власників, і де все це вироджується.
• МенеджментЕпіки, фічі, задачіЕпіки, фічі й задачі — це рівні ієрархії роботи: від ставки, яку керівник робить на квартал, до кроку, який інженер робить сьогодні. Жоден стандарт їх не визначає: у Scrum Guide немає жодного з цих трьох слів, а Jira, Azure DevOps і SAFe ставлять епік на різний розмір. Сторінка починається з усіх рівнів на одному екрані й одного епіка, розкладеного до задач; далі — звідки ці слова, для чого кожен рівень, епік як ставка з виходом, фічі, enabler-и й задачі, чому підсумовані оцінки вводять в оману, п’ять епізодів з історії ієрархії і де все це вироджується.