Корисний бриф MVP ухвалює три рішення до початку дизайну: для кого призначений продукт, що перша версія навмисно залишить поза межами та які користувацькі докази виправдають наступні інвестиції. Тому бриф — не паперова робота. Це перше продуктове рішення.
Засновники часто приходять із брифом, який насправді є описом ідеї: кілька абзаців про ринок, перелік функцій і речення про те, куди продукт може колись дійти. Цього досить, щоб почати розмову, але недостатньо для розробки. Команді потрібен менший, чіткіший документ, що перетворює амбіцію на послідовність перевірних виборів.
Корисний бриф виконує три завдання
1. Він називає людину, яка має проблему
«Малий бізнес» — це ринок. Це не перший користувач. Хороший бриф називає людину, момент, у якому вона перебуває, і обхідний шлях, яким вона користується сьогодні. Менеджер клініки, що намагається заповнити завтрашні скасування, має іншу проблему, ніж пацієнт, який шукає новий запис, навіть якщо обидва належать до сфери охорони здоров’я. Що конкретніший перший користувач, то легше вирішити, що продукт має робити далі.
2. Він проводить межу навколо першої версії
Список функцій каже, що було уявлено. Межа обсягу каже, що буде створено. Опишіть основний цикл одним реченням, а тоді перелічіть роботу, яка робить його надійним: головний екран, одну значущу дію, дані за нею та зворотний зв’язок, що повідомляє користувачеві про успіх. Усе інше — кандидат на пізніше, а не мовчазна вимога до запуску.
3. Він визначає наступний доказ
«Запустимо й подивимося, що станеться» — це не план навчання. Вирішіть, що очікуєте побачити в перші кілька тижнів: завершений сценарій, повторну дію, платну конверсію або інтерв’ю засновника з конкретним типом користувача. Метрика не мусить бути складною. Вона має бути досить близькою до поведінки користувача, щоб змінити наступне продуктове рішення.
Що записати до першого екрана
- Перший користувач: одна роль, одна ситуація та один болісний обхідний шлях
- Основний цикл: найменша дія, що створює цінність і може повторюватися
- Межа запуску: що явно поза обсягом першої версії
- Вимога довіри: що користувач має побачити, контролювати чи зрозуміти перед дією
- Наступна точка доказу: поведінка чи розмова, що заслуговує ще одного раунду розробки
Перевірка обсягу, якою ми користуємося
Візьміть кожну запропоновану функцію й поставте одне запитання: чи робить вона успіх основного циклу для першого користувача імовірнішим? Якщо ні — винесіть її з першого релізу. Якщо можливо — запишіть припущення, яке вона захищає, і знайдіть дешевший спосіб його перевірити. Так корисна функція не стає постійним виправданням затримки продукту.
Мета брифу — не зафіксувати все, що ви могли б створити. Її мета — зробити очевидним наступне рішення про розробку.
— правило, яким ми користуємося на продуктових стартах
Поширені запитання
Якої довжини має бути бриф MVP?
Досить коротким, щоб прочитати за один раз, і досить конкретним, щоб робити компроміси. Однієї-двох сторінок зазвичай досить, якщо в них названі перший користувач, основний цикл, межа запуску, вимоги довіри та наступна точка доказу.
Чи має бриф містити повний перелік функцій?
Додайте функції, що забезпечують роботу основного циклу, а решту тримайте в розділі ідей на потім. Окремий список очікування захищає хороші ідеї, не дозволяючи їм непомітно стати вимогами до запуску.
Що, якщо цільовий користувач іще невизначений?
Запишіть двох найсильніших кандидатів і докази, що дали б змогу розрізнити їх. Невизначеність корисна, коли вона явна; вона стає дорогою, коли прихована в широкому обсязі продукту.
Чи треба завершити бриф до початку дизайну?
Він має бути досить ясним, щоб спрямувати перший етап дизайну, але не застиглим назавжди. Дизайн може виявити краще запитання, проте кожна зміна має оновлювати обсяг і доказ, який ви намагаєтеся зібрати.