MVP: минимальный жизнеспособный продукт или максимально плохой предлог не думать?
Все делают MVP. Никто не делает его правильно. Разбираем, что на самом деле значит «минимальный», почему большинство MVP обречены с первого спринта — и как сделать так, чтобы ваш не был...
Слово MVP давно превратилось в индульгенцию. Баг в продакшене? «Это MVP». Нет онбординга? «Это MVP». Интерфейс, который не понимает даже ваша мама? «Это MVP, потом доделаем». За этой аббревиатурой прячут всё что угодно — лень, страх, нехватку ресурсов и отсутствие понимания, что вообще строить.
Между тем Эрик Рис, который придумал этот термин, имел в виду совсем другое.
Ключевое слово здесь — цикл обратной связи. Не «что-то запустить побыстрее». Не «набросок продукта». А инструмент для проверки гипотезы.
Почему большинство MVP не работают
Есть три архетипа плохого MVP, которые встречаются снова и снова.
«Продукт без продукта»
Лендинг с формой подписки, за которым нет ничего. Метрика — email'ы. Инсайт — ноль.
«Все фичи сразу»
MVP с 40 функциями — это не MVP. Это бета. Тестировать нечего, потому что непонятно, что именно работает.
«Красивая пустышка»
Идеальный UI, zero-дефектов, но не решает реальную проблему пользователя.
По данным CB Insights, 35% стартапов закрываются из-за того, что строили продукт, который никому не нужен. MVP должен был это предотвратить — но не предотвратил, потому что команда тестировала не то.
Что такое настоящий MVP: три критерия
Одна проблема — один сценарий
MVP решает ровно одну проблему для одного типа пользователя. Не «помогает малому бизнесу», а «позволяет парикмахерской принимать онлайн-запись за 5 минут без звонков».
Есть конкретная гипотеза
До запуска вы формулируете: «Мы верим, что X пользователей сделают Y действие, потому что Z». Если гипотезы нет — нет MVP, есть просто продукт.
Есть метрика фальсификации
Вы знаете заранее, при каком результате признаёте гипотезу ложной. Без этого любой провальный MVP превращается в «мы просто ещё не нашли своего пользователя».
Что должно быть в MVP
- Основной пользовательский сценарий от начала до конца — работает без «позвоните нам»
- Механизм сбора обратной связи прямо внутри продукта
- Аналитика на ключевых действиях: куда нажали, где бросили, что сделали дважды
- Достаточный уровень качества, чтобы пользователь не решил, что это мошенники
Чего не должно быть в MVP
- Личный кабинет с настройками профиля — это не нужно на этапе MVP почти никогда
- Сложный онбординг — если продукт требует 10 шагов для старта, это проблема концепции, а не онбординга
- Масштабируемая архитектура — преждевременная оптимизация убила больше стартапов, чем отсутствие фич
- Мобильное приложение — если не доказали ценность в вебе, нативное приложение только замедлит итерации
Сколько времени должен занимать MVP
Есть простое правило: если вы не можете запустить за 4–8 недель — вы строите не MVP, а версию 1.0. Это не значит, что продукт будет плохим. Это значит, что вы уже приняли слишком много решений без валидации.
Dropbox не писал код для своего MVP. Дрю Хьюстон снял 3-минутное видео, показал идею — и за одну ночь получил 75 000 регистраций. Это и была валидация гипотезы: люди хотят синхронизировать файлы между устройствами.
Матрица: какой MVP подходит вашей идее
Лендинг + waitlist
Тестируем спрос до написания кода. Метрика — конверсия в регистрацию.
Консьерж-MVP
Делаем руками то, что потом автоматизируем. 5–10 клиентов, глубокие интервью.
Фейковые дверцы
Симулируем одну сторону рынка вручную, пока не доказана ценность для другой.
Wizard of Oz
Интерфейс есть, «алгоритм» — человек за экраном. Продукт имитирует автоматику.
MVP — это не про то, чтобы сделать меньше работы. Это про то, чтобы сделать правильную работу в правильный момент. Разница между «ленивым MVP» и «умным MVP» — это разница между стартапом, который пивотирует на основе данных, и стартапом, который пивотирует от безысходности.
Нужен продукт под ключ?
Обсудим задачу за 30 минут — roadmap и ориентир по срокам и бюджету.
Обсудить проект