Користувач, JTBD і метрика успіху

1. Ідея без користувача не працює

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

До цього user, pain, result і scope працювали фільтрами ідеї: вони допомагали зрозуміти, чи є у проєкту взагалі робочий кут. Тепер їх треба зафіксувати жорсткіше — як поля специфікації. Назвіть конкретного користувача — і проєкт приземляється: з’являються робоча ситуація, обмеження, мова інтерфейсу, критерії користі, майбутні guardrails. Оператору підтримки потрібні inbox, швидкий розбір тикетів і безпечна робота з поверненнями; менеджеру магазину — dashboard, зведення, тренди. Зовні одне «AI для підтримки». Усередині — два різні продукти.

Невелика таблиця це дуже швидко показує:

Дуже корисно тримати в голові простий ланцюжок:

flowchart TD
    A[Ідея] --> B[Конкретний користувач]
    B --> C[Конкретний біль]
    C --> D[JTBD]
    D --> E[Метрика успіху]
    E --> F[Demo-сценарій]

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

2. Persona — робоча картка, а не роман

Опис користувача в MVP — не біографія і не анкета з відділу маркетингу. Улюблений колір, знак зодіаку та ставлення до авокадо-тостів вам не потрібні. Потрібне те, що рухає інженерні рішення: де він працює, що робить щодня, яким інструментом користується зараз, у який момент починається біль. Перевірка: можете після persona назвати потрібний інтерфейс, дані й виграш — текст корисний. Хочеться сказати лише «цікава людина» — текст симпатичний, але марний.

Ось які поля зазвичай дають найбільшу користь:

Такий фрагмент уже можна покласти в поточну специфікацію:

## Користувач

Роль: оператор підтримки невеликого інтернет-магазину  
Робочий день: 60–100 тикетів на день  
Інструменти: inbox магазину, пошта, нотатки із шаблонами  
Поточний обхідний шлях: копіює типові відповіді вручну  
Головний біль: типові звернення забирають час у складних кейсів

Зверніть увагу на одну важливу річ: на старті достатньо однієї persona. Навіть якщо продукт стане у пригоді і менеджеру, і оператору, і власнику магазину, — поки що залиште це в спокої. MVP ламається не від «занадто мало користувачів», а від спроби догодити всім і в підсумку — нікому.

3. Старт — з workaround, а не з AI

Користувач не прокидається з думкою «як шкода, що в мене немає класифікатора звернень на базі LLM». Він прокидається з думкою «inbox переповнений, половина зміни йде на копіпаст, а ризиковане refund потоне серед запитань про доставку». З цього й починайте.

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

Для нашого прикладу це можна оформити так:

## Проблема

Оператор витрачає значну частину зміни на типові запитання
про статус замовлення, доставку та правила повернення.

## Поточний обхідний шлях

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

Чому це так важливо? Тому що без обхідного шляху проблема залишається занадто гладкою — «підтримка працює повільно». Опишіть поточний спосіб — і підуть практичні запитання: що небезпечніше, повільна відповідь чи пропущене дороге повернення? І з’ясовується: продукт потрібен не для «автоматизації відповідей», а для розділення типових і ризикованих випадків. Тут же вперше з’являється human-in-the-loop, хоча багато хто чекає його пізніше: з типовими тикетами система допомагає, а refund > $100 не можна віддавати AI на автопілот. Межу вказала сама проблема.

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

4. JTBD: одна формула, яка прибирає туман

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

Канонічна формула виглядає так:

Коли [ситуація],
я хочу [виконати роботу],
щоб [отримати результат].

У нашому прикладі це може звучати так:

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

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

Зручно перевіряти JTBD за такою маленькою таблицею:

Є ще один корисний трюк. Спробуйте підставити в JTBD іншого користувача — і подивитися, як поїде продукт:

Це дуже тверезить. Зовні тема одна — підтримка інтернет-магазину, — а продукт щоразу інший. JTBD корисний не для краси документа: він вчасно ловить момент, коли ви непомітно будуєте вже не той MVP.

5. Метрика успіху: видима користь MVP

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

Для навчального MVP метрика не зобовʼязана бути надскладною аналітикою з красивими графіками — цілком достатньо, щоб вона була спостережуваною і відтворюваною на demo. Не декоративною, а перевірюваною. Reviewer після demo не розуміє, чи стало користувачеві краще, — метрика занадто туманна.

Порівняйте формулювання:

Для AI Support Agent хороший набір метрик може виглядати так:

## Метрика успіху

- На 10 sample tickets точність класифікації не нижча за 80%
- На типових запитаннях AI draft потребує не більше 2 правок оператором
- Повернення вище $100 не може бути надіслане без ручного approval
- В audit trail видно, що запропонував AI і що зробив оператор

Тут важливо, що метрика перевіряє не лише «розумність» моделі, а й користь, безпеку та спостережуваність результату. Це важливо, бо початківці дуже люблять зводити success metric до однієї цифри якості моделі. Але MVP рідко провалюється через точність класифікації — частіше тому, що не вписався в робочий день, не дав безпечного сценарію або не показав зрозумілий результат на demo.

Саме звідси потім природно виростає демонстрація. Метрика про 10 sample tickets — їх і показуєте; метрика про блокування повернення вище порогу — у demo обов’язково кейс із таким поверненням. Хороша метрика економить сили двічі: під час проєктування і під час показу.

6. Збірка фрагмента MVP_SPEC.md

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

Ось як це може виглядати для нашого AI Support Agent:

## Користувач
Оператор підтримки невеликого інтернет-магазину.
За зміну обробляє 60–100 звернень і працює в inbox магазину.

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

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

## JTBD
Коли я вранці відкриваю inbox із десятками звернень,
я хочу швидко закривати типові тикети,
щоб у мене залишався час на складні й ризиковані кейси.

## Метрика успіху
На 10 sample tickets система правильно класифікує щонайменше 8,
а refund вище $100 завжди потребує ручного approval.

Якщо ваш capstone — чистий MVP, фрагмент живе в MVP_SPEC.md. Якщо ні — не виносьте його в окремий паралельний файл: вбудуйте той самий блок у наявний SPEC.md як уточнення продуктової частини. Логіка не змінюється: чесно відповідайте, хто отримує користь, у якій ситуації і за якою спостережуваною ознакою ви зрозумієте, що проєкт полегшує життя.

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