Ключевые тезисы
- У MVP должен быть один основной сценарий, который создаёт ценность.
- Нельзя одновременно проверять все гипотезы продукта.
- Готовность к запуску определяется не количеством функций, а работоспособностью ключевого потока.
Зафиксируйте, что именно проверяет MVP
MVP нужен не для демонстрации всех будущих возможностей, а для проверки одной или двух главных гипотез: спроса, retention или готовности платить.
Если этого фокуса нет, бэклог разрастается и команда теряет темп.
Соберите launch scope до начала дизайна и разработки
Список обязательных функций должен быть коротким и неизменным на протяжении спринта. Всё остальное уходит в post-launch.
Полезно заранее определить, что можно заменить временным решением: ручной операцией, no-code формой или упрощённой аналитикой.
- основной пользовательский поток
- платёжный или регистрационный сценарий
- поддержка, аналитика и обработка ошибок
Подготовьте запуск как отдельный этап
MVP считается готовым только тогда, когда команда может привлечь первых пользователей, измерить их поведение и быстро внести изменения.
Поэтому перед релизом нужно проверить аналитику, каналы входящего трафика, онбординг и внутренний процесс поддержки.