Сформулируйте проверяемое предположение
Вместо «нужен сервис бронирования» запишите, для кого он нужен и что изменится: например, смогут ли клиенты самостоятельно выбрать доступное время. Это пример постановки задачи, а не результат клиентского проекта.
Определите пользователя, его текущий способ решения задачи и действие, которое покажет пользу новой версии. Регистрация сама по себе не всегда означает, что человек получил результат.
Нарисуйте один полный сценарий
Для примера с бронированием это может быть выбор услуги, выбор времени, подтверждение и изменение статуса. Важен законченный путь, включая понятное сообщение об ошибке.
Административные действия тоже входят в сценарий: кто добавит доступные часы, увидит заявку и исправит ошибочную запись. Без них красивый интерфейс может оказаться неудобным в работе.
Разделите функции по необходимости
Обязательное — без чего сценарий не работает. Следующее — улучшает уже работающий процесс. Экспериментальное — требует отдельной проверки спроса.
Рейтинги, сложные роли, программа лояльности и несколько способов оплаты могут быть полезны, но их место зависит от конкретной гипотезы. Отложенная функция должна иметь причину возвращения в план.
Согласуйте критерии готовности
Запишите примеры действий и ожидаемый результат. Какие данные нужны? Что происходит при повторном нажатии? Кто имеет доступ? Какие устройства должны поддерживаться?
Отдельно определите, как измерять использование и собирать обратную связь. Это позволяет отличить технический запуск от подтверждения продуктовой гипотезы.
Подготовьте короткий бриф
Для первого обсуждения достаточно описать пользователя, проблему, основной сценарий, имеющиеся материалы и ограничения. Если есть желаемая дата, объясните, с каким событием она связана.
После этого можно оценить первую часть работы и список неизвестных. Оценка становится полезнее, когда в ней видны допущения.