Збираємо вхідні дані: життєвий цикл, ринок, клієнти, стейкхолдери

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

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

У Котокормі перша сторінка роадмапи дійшла до CEO Ian, і вона йому сподобалася. Але 14-го засідає рада директорів, і там спитають навіщо: чому саме ці дві цілі, чому зараз і звідки цифри. А частина цифр з'явилася після довгого вдивляння в таблицю.

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

Перше джерело — життєвий цикл продукту (product life cycle). Класична модель має чотири етапи: запуск, зростання, зрілість і спад. Деякі моделі додають п'ятий — розширення на суміжну потребу. Назви важать менше, ніж запитання: чого цей етап вимагає від роадмапи?

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

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

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

Тому в Ian дві цілі: одна частина бізнесу має утримувати людей, інша — рости.

Так само можна відповісти раді на «чому саме ці дві?» трьома реченнями, кожне з яких спирається на вхідні дані:

• Етап: підписка дозріває, тож зростання залежить від утримання підписників; канал клінік молодий і росте.
• Гроші: у зрілому бізнесі втримати підписника дешевше, ніж знайти нового.
• Ринок: лікувальний корм обирає ветеринар, тож саме клініки вирішують, який бренд купують власники тварин.

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

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

Далі гроші: хто платить, скільки коштує їх обслуговувати, де маржа. Досить ескізу бізнес-моделі на одну сторінку. Без нього доведеться вгадувати, які проблеми варто розв'язувати.

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

У B2B покупець і користувач часто різні люди, і їм потрібне різне: покупець вирішує про продовження, а користувачі — чи продукт справді працює. Перша угода Котокорму з клініками це показує. Менеджерка із закупівель PurrPoint погодилася на пілот у двох клініках із листопада замість квітневої дати. Вона підписує договір, але не зробить жодного замовлення; їх щотижня роблять адміністратори клінік.

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

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

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

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

Далі виріши, наскільки тісно працювати з кожним. Поширений інструмент — сітка «вплив / інтерес» (power/interest grid): скільки людина має впливу на роадмапу і наскільки їй це важливо.

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

Якщо всіх поставити у верхній квадрат, нікому не приділиш належної уваги.

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

• як часто це трапляється;
• кого це зачіпає;
• скільки це коштує (гроші, час, втрачені клієнти).

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

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

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

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

Тримай результат коротким: п'ять–десять проблем, кожна з джерелом.

Як це складається докупи: чотири джерела (життєвий цикл, ринок, клієнти, стейкхолдери) зводяться до цього короткого списку проблем із джерелами. Він живить бачення, цілі, а згодом і теми. Далі урок Бачення продукту й ціннісна пропозиція перетворить його на речення вгорі сторінки.