Бриф MVP ваше первое продуктовое решение

Основатели часто приходят с брифом, который на деле является описанием идеи: несколько абзацев о рынке, список функций и фраза о том, куда продукт когда-нибудь может прийти. Этого достаточно, чтобы начать разговор, но недостаточно для разработки. Команде нужен меньший и более точный документ, который превращает амбицию в последовательность проверяемых выборов.

Полезный бриф выполняет три задачи

1. Он называет человека, у которого есть проблема

«Малый бизнес» это рынок, а не первый пользователь. Хороший бриф называет человека, момент, в котором он находится, и обходной путь, которым он пользуется сегодня. У менеджера клиники, пытающегося заполнить отмены на завтра, проблема отличается от проблемы пациента, ищущего новую запись, даже если оба относятся к здравоохранению. Чем конкретнее первый пользователь, тем легче решить, что продукт должен делать дальше.

2. Он проводит границу вокруг первой версии

Список функций говорит, что было придумано. Граница объёма говорит, что будет создано. Опишите основной цикл одним предложением, затем перечислите работу, которая делает этот цикл надёжным: главный экран, одно значимое действие, данные за ним и обратную связь, подтверждающую пользователю успех. Всё остальное кандидат на потом, а не молчаливое требование к запуску.

3. Он определяет следующее доказательство

«Запустим и посмотрим, что будет» не план обучения. Решите, что вы ожидаете увидеть в первые недели: завершённый сценарий, повторное действие, платную конверсию или интервью основателя с конкретным типом пользователя. Метрика не обязана быть сложной. Она должна быть достаточно близка к поведению пользователя, чтобы изменить следующее продуктовое решение.

Что записать до первого экрана

• Первый пользователь: одна роль, одна ситуация и один болезненный обходной путь
• Основной цикл: наименьшее действие, создающее ценность и способное повторяться
• Граница запуска: что явно не входит в первую версию
• Требование доверия: что пользователь должен увидеть, контролировать или понять перед действием
• Следующая точка доказательства: поведение или разговор, оправдывающие ещё один этап разработки

Проверка объёма, которой я пользуюсь

Возьмите каждую предложенную функцию и задайте один вопрос: повышает ли она вероятность успеха основного цикла для первого пользователя? Если нет вынесите её из первого релиза. Если возможно запишите предположение, которое она защищает, и найдите более дешёвый способ проверить его. Так полезная функция не станет постоянным оправданием задержки продукта.

Цель брифа не зафиксировать всё, что вы можете создать. Его цель сделать очевидным следующее решение о разработке.

правило, которое я использую на продуктовых стартах

Как я использую это в Sirajov

До оценки разработки я превращаю идею основателя в одностраничный объём: один пользователь, один основной цикл, экраны и инфраструктура, которые его поддерживают, и доказательства, которые должны изменить следующее решение. Документ становится передачей между стратегией, дизайном, инженерией и запуском и точкой отсчёта, когда новая функция пытается незаметно попасть в первую версию.

Часто задаваемые вопросы

Какой длины должен быть бриф MVP?

Достаточно коротким, чтобы прочитать за один раз, и достаточно конкретным, чтобы делать компромиссы. Одной-двух страниц обычно хватает, если в них названы первый пользователь, основной цикл, граница запуска, требования доверия и следующая точка доказательства.

Должен ли бриф включать полный список функций?

Включите функции, которые обеспечивают основной цикл, а остальные оставьте в разделе идей на потом. Отдельный список ожидания защищает хорошие идеи, не позволяя им незаметно стать требованиями к запуску.

Что, если целевой пользователь всё ещё не определён?

Запишите двух наиболее вероятных кандидатов и доказательства, которые позволят различить их. Неопределённость полезна, когда она явна; она становится дорогой, когда скрыта внутри широкого объёма продукта.

Нужно ли завершить бриф до начала дизайна?

Он должен быть достаточно ясным, чтобы направить первую итерацию дизайна, но не обязан навсегда оставаться неизменным. Дизайн может выявить лучший вопрос, однако каждое изменение должно обновлять объём и доказательство, которое вы пытаетесь собрать.