MVP — это вопрос, а не уменьшенный продукт

Аббревиатуру MVP знают все, и почти все понимают её одинаково неправильно: «первая версия продукта, где меньше функций». Из этого понимания вырастают проекты, которые делаются девять месяцев, стоят как полноценная разработка и всё равно не отвечают на главный вопрос.

Полезнее держать в голове другое определение:

MVP — это самый дешёвый эксперимент, который даёт достоверный ответ на один конкретный вопрос о вашем бизнесе.

Не «маленький продукт». Эксперимент. Значит, у него должен быть вопрос, метод и критерий результата — как у любого нормального эксперимента.

Сначала вопрос, потом продукт

Прежде чем обсуждать функции, сформулируйте, что именно вы хотите узнать. У ранних проектов это почти всегда один из четырёх вопросов:

1. Спрос. Захотят ли этим пользоваться вообще?
2. Готовность платить. Заплатят ли, и сколько?
3. Выполнимость. Сможем ли мы технически сделать ключевую вещь?
4. Канал. Есть ли повторяемый способ приводить пользователей?

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

Выберите один вопрос. Тот, ошибка в котором убьёт проект быстрее всего.

Тест на лишнее: «что будет, если этого не будет»

Возьмите список запланированных функций и по каждой ответьте: что произойдёт с экспериментом, если этой функции не будет?

Если честный ответ — «нам придётся делать это руками», «будет неудобно», «добавим потом» — функция не входит в MVP. Если ответ — «эксперимент не даст ответа» — входит.

Что почти никогда не нужно в первой версии:

• Регистрация через соцсети (достаточно почты или вообще ссылки-доступа)
• Личный кабинет с настройками
• Админка (первое время админ — это вы с доступом к базе)
• Роли и права, если пользователей пока меньше десяти
• Автоматические письма, аналитические дашборды, экспорт в пяти форматах
• Мобильное приложение, если задача решается в браузере
• Оплата онлайн, если первые сделки можно провести по счёту

Что нужно почти всегда: одно действие, ради которого человек пришёл, и способ понять, сделал он его или нет.

«Немасштабируемое» — это фича, а не стыд

Самая полезная привычка ранней стадии: делать руками то, что потом будет автоматикой.

Подбор — вручную. Модерация — вручную. Онбординг — лично, по звонку. Отчёт — собранный ночью в таблице и отправленный письмом.

Это не костыль. Это способ узнать реальную последовательность шагов до того, как вы зашьёте неправильную последовательность в код. Автоматизировать процесс, который вы ни разу не прожили, — верный путь построить не то.

Есть и практический признак: если ручная работа стала невыносимой, значит, спрос настоящий. Автоматизируйте именно тот участок, который болит, — не весь процесс сразу.

Сколько времени должен занимать MVP

Ориентир, который работает для большинства ранних продуктов: 4–8 недель.

Не потому что это красивое число, а потому что за пределами этого срока начинают ломаться три вещи:

• Обратная связь устаревает. Вы строите под то понимание рынка, которое было два месяца назад.
• Растёт цена разворота. Чем больше построено, тем тяжелее психологически признать, что гипотеза не сработала.
• Падает энергия команды. Запуск, который «вот-вот» уже третий месяц, выжигает сильнее провала.

Если ваш MVP не помещается в восемь недель — почти наверняка вы проверяете больше одного вопроса. Вернитесь к разделу про вопрос.

Как понять, что MVP готов

Не по списку функций. По одному признаку:

Реальный пользователь может пройти путь до ценности целиком — пусть с вашей помощью, пусть некрасиво — и вы можете зафиксировать, получил он ценность или нет.

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

Критерий успеха задаётся до запуска

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

Например: «за 4 недели 10 из 15 приглашённых заведут хотя бы один реальный заказ, и минимум 5 вернутся на второй неделе». Число не обязано быть точным — оно обязано быть записанным заранее.

Без этого происходит стандартная история: запуск дал слабый результат, а фаундер объясняет, почему на самом деле это успех. Заранее записанный критерий защищает от собственного оптимизма лучше любого консультанта.

Что дальше

После MVP есть ровно три честных исхода — и все три полезны:

• Работает. Люди возвращаются и зовут других. Дальше — вопрос повторяемости: какие метрики считать в первые 90 дней.
• Работает не там. Ценность нашлась, но в другом сегменте или в другой части продукта. Это самый частый и самый продуктивный исход — из него рождаются пивоты.
• Не работает. Гипотеза не подтвердилась за 6–8 недель вместо года. Это дёшево. Дорого — когда об этом узнают на второй год.

MVP не должен доказать, что вы правы. Он должен как можно быстрее показать, правы вы или нет.