Потреби клієнтів як теми: дерево можливостей

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

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

Три речі схожі на теми, але ними не є. Метрика на кшталт «відтік із 9% до 6%» — твоя цифра, а не їхня, тож її місце серед ключових результатів. Рішення на кшталт «нагадування про повторне замовлення» — лише одна можлива відповідь, і наступного місяця вона може змінитися. Внутрішня робота на кшталт «замінити складську систему» клієнтам не видна, доки ти не пов'яжеш її з результатом, який вони відчують.

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

Дерево можливостей і рішень (opportunity solution tree) — рамка, у якій ключовий результат перетворюється на теми: воно не дає результатам, потребам та ідеям злитися в одне. У ньому чотири рівні.

Угорі — один результат, за який відповідає команда, зазвичай ключовий результат: частка скасувань через те, що закінчився корм, падає з 30% до 15%. Нижче — можливості (opportunities): потреби, болі й бажання, почуті від клієнтів, як-от власники не помічають, що корм закінчується, доки пакет не спорожніє. Під кожною можливістю — кілька рішень, як-от листи-нагадування чи гнучкі дати доставки. Під рішенням — невеликі експерименти, що дешево його перевіряють: вручну надіслати нагадування 200 підписникам і порівняти їхні повторні замовлення з рештою.

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

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

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

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

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

А рядок, що не веде до жодної цілі, як-от привітання котів із днем народження, — тривожний сигнал, а не тема. Не втискай його під найближчий заголовок, аби лише зберегти.

Карта шляху користувача (user journey map) розкладає кожен крок людини від моменту, коли вона помічає проблему, до моменту, коли проблему розв'язано, разом з обхідними шляхами, які вона сама вигадала. Вона перетворює розмиту скаргу на кшталт «у клініках закінчується корм» на історію, яку можна розібрати крок за кроком.

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

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

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

Кожен болючий крок на шляху може стати підтемою (subtheme): вужчою потребою всередині теми, теж записаною як результат. Зі шляху клініки: «Адміністратори знають, що закінчується, ще до того, як спорожніє полиця», «Замовлення приходять повністю», «Повторне замовлення не потребує дзвінка».

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

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

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

Тема каже, що має стати правдою. Джоб-сторі (job story) під нею показує, чому це важливо, у ситуації клієнта: «Коли [ситуація], я хочу [мотивація], щоб [очікуваний результат]».

Звична юзер-сторі («Як [користувач], я хочу…, щоб…») починається з персони. Джоб-сторі натомість починається з моменту, а момент зазвичай пояснює потребу краще, ніж опис того, хто ця людина. Та сама адміністраторка клініки хоче зовсім різного спокійного понеділкового ранку й пізно в п'ятницю, коли закінчується лікувальний корм.

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

Ситуації бери з доказів — нотаток з інтерв'ю, дзвінків у підтримку, карт шляху, — а не з уяви.

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

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

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

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

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

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

Уникай двох коротких шляхів. Дата біля рішення («до березня») перетворює його на обіцянку, нічого не пояснивши. Технічне вподобання («сучасний стек») не дає читачам нічого, що можна перевірити. Якщо не можеш сказати, який результат захищає робота, розпитуй інженерів, доки не зможеш.

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

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

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