Что такое MVP и чем он не является
Аббревиатура расшифровывается как минимально жизнеспособный продукт. Ключевое слово тут не «минимальный», а «жизнеспособный»: версия должна реально решать задачу человека, иначе проверять нечего.
Разница видна на примере. Урезанный продукт - это когда из задуманных десяти функций сделали три, и они работают наполовину. MVP - это когда из десяти функций сделали одну, но целиком и хорошо, и на ней видно, пользуются люди или нет.
Чем MVP не является:
- Не черновиком. Если человеку неудобно им пользоваться, вы проверите удобство, а не идею.
- Не бесплатным способом сделать продукт. Это способ не потратить много на непроверенную идею, а не способ сэкономить на всём.
- Не разовым действием. MVP выпускают, смотрят, делают вывод. Без последнего шага это просто маленький продукт.
Зачем он нужен, если идея и так хорошая
Основная ценность MVP - не экономия денег, а скорость получения правды. Вы либо получаете подтверждение и вкладываетесь дальше уверенно, либо узнаёте, что гипотеза не работает, и меняете её, потратив малую часть бюджета.
Три вопроса, на которые он отвечает:
- Есть ли проблема. Люди действительно страдают от того, что вы придумали решать, или вам так кажется.
- Подходит ли решение. Проблема есть, но ваш способ её решать людям может не подойти.
- Готовы ли платить. Пользоваться бесплатно и платить - разные вещи, и второе проверяется только деньгами.
Заметьте, что все три вопроса про людей, а не про технологию. Технически можно сделать почти всё - вопрос, нужно ли это кому-то.
Как выбрать, что войдёт в первую версию
Работающий приём: опишите одним предложением, что человек делает с вашим продуктом. «Клиент оставляет заявку и получает расчёт за час». Всё, что не участвует в этом предложении, в первую версию не входит.
Что почти всегда откладывается: личные кабинеты с настройками, красивая аналитика, несколько ролей, интеграции со всем подряд, мобильное приложение параллельно с сайтом.
Что почти никогда не откладывается: то, без чего сценарий не проходит целиком, и то, что определяет впечатление. Если человек не может дойти до результата - проверять нечего.
Отдельно про ручную работу. На этапе проверки нормально делать руками то, что потом будет автоматическим. Заявки обрабатывает не система, а человек в переписке - и это правильный MVP, если сценарий проходится. Автоматизировать имеет смысл после того, как поток подтвердился; тогда же становится понятно, что именно отдавать нейросетям.
Этапы: от гипотезы до вывода
Гипотеза одним предложением
Сформулируйте проверяемую гипотезу одним предложением.Критерий успеха до старта
Заранее задайте критерий, по которому гипотеза считается подтверждённой.Сборка одного сценария
Соберите один основной сценарий без лишних функций.Живые люди
Привлеките людей, у которых действительно есть эта проблема.Вывод
Сравните результат с критерием и зафиксируйте, подтвердилась гипотеза или нет.
Шаг 1. Гипотеза одним предложением. «Владельцы небольших магазинов готовы платить за разбор остатков, потому что сейчас считают руками». Проверяемое утверждение, а не пожелание.
Шаг 2. Критерий успеха до старта. Сколько человек должны дойти до конца, чтобы вы посчитали гипотезу подтверждённой. Названный заранее, иначе после запуска любая цифра покажется обнадёживающей.
Шаг 3. Сборка одного сценария. Мы собираем такие первые версии как запуск цифрового продукта под ключ - и почти всегда самое сложное здесь не разработка, а отказ от лишнего.
Шаг 4. Живые люди. Не друзья и не коллеги - те, у кого действительно есть проблема. Друзья вежливые, они вас похвалят и ничего не проверят.
Шаг 5. Вывод. Сравнить с критерием из второго шага и честно сказать: подтвердилось, не подтвердилось, или данных не хватило.
Как понять, что гипотеза не сработала
Самое трудное в MVP - признать отрицательный результат. Обычная реакция: «просто интерфейс неудобный, сейчас переделаем». Иногда так и есть, но чаще это способ не услышать ответ.
Признаки, что дело не в интерфейсе:
- Люди не доходят до середины сценария. Значит ценность не считывается на входе.
- Хвалят, но не платят. Классика. Словами поддержат все, деньгами - те, у кого проблема настоящая.
- Не возвращаются. Разовое использование говорит, что задача либо решилась иначе, либо не была регулярной.
- Приходится долго объяснять, зачем это. Если ценность требует объяснения, в реальном мире её никто объяснять не будет.
Отрицательный результат - это тоже результат, и он стоил вам малой части бюджета. Именно ради этого MVP и делается.
Пять ошибок, из-за которых первая версия ничего не проверяет
- Сделали слишком много. Полгода разработки - это уже не проверка гипотезы, а ставка на неё.
- Не назначили критерий заранее. Без цифры до старта любой результат объясняется задним числом.
- Показали своим. Коллеги и знакомые не проверяют идею, они поддерживают вас.
- Не выпустили, потому что «ещё не готово». Идеальная первая версия не выходит никогда, а конкурент выходит.
- Вместо вывода начали доработку. Самая дорогая ошибка: продукт растёт, гипотеза так и не проверена, деньги кончаются.
Что делать после MVP
Если гипотеза подтвердилась, следующий шаг - не «сделать всё остальное», а взять второй по важности сценарий и повторить цикл. Продукт растёт кусками, каждый из которых проверен.
Если не подтвердилась - меняется гипотеза, а не количество функций. Часто оказывается, что проблема есть, но у другой аудитории или в другой форме. Это нормальный ход, а не провал.
Хотите пройти путь от идеи до проверенной первой версии не в одиночку? ClaudeLab ставит шаги вместе и доводит до результата.
Отдельно стоит подумать, каким будет продукт технически: иногда это веб-приложение с личным входом, а иногда достаточно связки готовых сервисов и разбора данных без программиста.
Что запомнить
MVP - это не маленький продукт, а способ узнать правду дёшево. Он работает ровно настолько, насколько вы готовы услышать ответ.
Назовите цифру успеха до запуска, соберите один путь целиком, приведите людей с настоящей проблемой - и через несколько недель у вас будет знание, за которое иначе пришлось бы платить годом разработки.