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

Сформулируйте одно предположение

Вместо «сделать маркетплейс» попробуйте: «организаторы готовы публиковать свободные даты, а клиенты — бронировать их без звонка». В этой формулировке уже есть две стороны и действия, которые можно наблюдать.

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

Нарисуйте минимальный завершённый путь

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

Административную часть тоже нельзя забывать. Кто добавляет предложения, исправляет ошибки и разбирает обращения? Иногда на пилоте допустима ручная работа команды, но её границы должны быть понятны и пользователю, и исполнителям.

Разделите функции на три группы

  • Обязательное ядро: без него основной результат невозможен.
  • Снижение риска: доступы, защита от дублирования операций, обработка ошибок.
  • Улучшения: рекомендации, сложная лояльность, дополнительные витрины.

Сокращать проще третью группу. Удаление обработки ошибок ради экономии может испортить сам эксперимент: пользователь откажется из-за сбоя, а команда решит, что услуга ему не нужна.

Что можно проверить до разработки

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

Такой пилот не доказывает масштабируемость, но помогает выявить непонятные условия и неверные предположения раньше.

Зафиксируйте решение после пилота

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

В разработке MVP мы начинаем с задачи и границ эксперимента. Если первая версия пока выглядит как длинный список идей, бриф поможет их упорядочить.