Minimum Viable Product — минимальная версия ценностного предложения, позволяющая получить достаточное знание для следующего решения. Минимальность относится не к количеству экранов, а к объёму инвестиций, необходимому для проверки главного риска. Viable означает, что проверка остаётся честной, понятной и способной дать валидный сигнал.
MVP не обязан быть программным продуктом. Иногда достаточно прототипа, ручной услуги или фиксации намерения. Иногда, напротив, доверие, безопасность или интеграции требуют более качественного исполнения.
| Риск | Возможный метод | Что узнаём |
|---|---|---|
| Понимание интерфейса | Кликабельный прототип, usability-тест | Может ли пользователь выполнить сценарий |
| Интерес к ценности | Лендинг, сообщение, fake door | Переходит ли пользователь к следующему шагу |
| Готовность платить | Предзаказ, депозит, предложение цены | Готов ли подтвердить намерение действием |
| Полезность результата | Concierge MVP | Получает ли пользователь ценность |
| Повторяемость процесса | Wizard of Oz | Работает ли опыт до полной автоматизации |
| Техническая реализуемость | Spike, proof of concept | Снимается ли инженерный риск |
Клик по кнопке не доказывает удержание, а позитивное интервью не доказывает готовность платить. Не требуйте от метода вывода, который он не способен поддержать.
По мере роста стоимости решения стремитесь к более сильному сигналу:
Сильный сигнал не всегда доступен сразу. Задача продакта — честно обозначить, что именно уже проверено.
Карточка проверки включает:
Fake door не должен обманывать пользователя о списании денег, доступности критической услуги или обработке чувствительных данных. Объясните отсутствие функции после клика, предложите безопасную альтернативу и не собирайте лишние данные. В медицине, финансах, безопасности и детских продуктах цена ошибки требует отдельной экспертизы.
Допустим, команда хочет добавить бронирование товара с временной блокировкой денег. Полная реализация затрагивает платёжную инфраструктуру, споры, возвраты и поддержку. Но главный ранний вопрос может быть проще: готовы ли покупатели подтверждать серьёзность намерения небольшим резервом, а продавцы — откладывать товар.
Кликабельный прототип проверит понимание сценария, fake door — интерес к функции, ручное сопровождение нескольких сделок — работоспособность процесса, а настоящий возвратный депозит — готовность принять финансовое обязательство. Это разные доказательства. Нельзя показать макет пяти людям и заключить, что экономика сервиса работает.
Покупатели жалуются, что интересный товар продают другому человеку по дороге на встречу. Продавцы жалуются на покупателей, которые бронируют товар и не приезжают. Команда предполагает, что резерв в 500 ₽ на 24 часа снизит число сорванных договорённостей.
Карта предположений и сравнительная таблица трёх проверок. Не проектируйте полноценную платёжную систему: цель задания — получить достаточное знание с минимальными инвестициями.
Ты — Product Discovery Lead. Проверь три моих дизайна MVP/эксперимента.
Для каждого определи: какое предположение реально проверяется; насколько силён сигнал; какие есть альтернативные объяснения; что метод не сможет доказать; стоимость, срок и пользовательский риск. Попробуй предложить более дешёвый способ получить то же необходимое знание.
Не выбирай автоматически самый простой вариант и не придумывай данные. Сначала поставь каждому варианту оценки 1–5 по силе сигнала, скорости, стоимости, этичности и пригодности для решения. Затем задай вопросы. Один улучшенный дизайн покажи только после критики и явно перечисли его ограничения.
Моя гипотеза и варианты:
[вставить работу]