В MVP входит один главный пользовательский сценарий, доведённый до конца: путь от входа до целевого действия, базовая авторизация, админ-панель и аналитика. Всё остальное — дополнительные роли, вторая платформа, интеграции «на вырост» и тонкие настройки — откладывается на следующие версии. Проверочный критерий: если функцию можно убрать, а гипотеза всё ещё проверяется, — этой функции в MVP не место.
Содержание
MVP — это не «урезанный продукт», а инструмент проверки
Главное непонимание вокруг MVP: его воспринимают как «продукт, на который не хватило денег». На самом деле MVP отвечает на один вопрос — будут ли люди пользоваться этим и платить. Всё, что не помогает получить ответ, из первой версии убирается: не потому что «дорого», а потому что удлиняет путь до ответа.
MVP отвечает на один вопрос — будут ли люди пользоваться этим и платить.
Отсюда практическое следствие: состав MVP определяется не бюджетом, а гипотезой. Сначала формулируется, что именно проверяем — «рестораны готовы принимать брони через приложение», «отделы продаж будут вести сделки в нашей системе», — и только потом решается, какой минимальный продукт эту гипотезу проверяет.
Что обязательно входит в MVP
- 01Главный сценарийодин путь пользователя до целевого действия
- 02Вход в продуктавторизация ровно настолько сложная, насколько требует сценарий
- 03Админ-панельконтент, заявки и пользователи — с первого дня
- 04Аналитика и событияметрики и есть результат MVP
Стандартный состав первой версии выглядит так:
- Главный сценарий от начала до конца: один путь пользователя до целевого действия — заказа, брони, заявки, подписки.
- Вход в продукт: регистрация и авторизация — ровно настолько сложные, насколько требует сценарий (часто достаточно входа по коду из SMS или через соцсети).
- Админ-панель: управлять контентом, заявками и пользователями нужно с первого дня, иначе каждая правка превращается в задачу разработчику.
- Аналитика и события: без них через месяц нечего будет обсуждать — метрики и есть результат MVP.
- Приём оплаты — если гипотеза про деньги: готовность платить проверяется только реальной оплатой, а не кнопкой «Оставить заявку».
- Одна платформа: веб, PWA или одно нативное приложение — та, где живёт ранняя аудитория.
Что почти всегда можно отложить на V2
Список ниже — не «ненужные» функции. Это функции, которые не помогают проверить гипотезу, а значит, их место — в roadmap после запуска:
Развитая система ролей и прав
- Почему подождёт
- В первой версии обычно достаточно «пользователь» и «администратор».
Вторая и третья платформы
- Почему подождёт
- Если запустились на вебе, iOS и Android подождут подтверждения спроса.
Интеграции «на вырост»
- Почему подождёт
- Обмен с 1С, складом и бухгалтерией подключается, когда есть что обменивать.
Персонализация, рекомендации, геймификация
- Почему подождёт
- Работают на удержание, а удержание имеет смысл после того, как появился поток пользователей.
Тонкие настройки профиля, темы оформления, мультиязычность
- Почему подождёт
- Почти никогда не влияют на проверку гипотезы.
Чат поддержки внутри продукта
- Почему подождёт
- На этапе MVP его прекрасно заменяет WhatsApp.
Как это устроено в цифрах: MVP-спринт InterLAB
6–126–12
недель от брифа до релиза
2–52–5
млн ₸ — ориентир бюджета
50%50%
оплаты на старте, 50% — на релизе
В InterLAB первая версия продукта делается в формате MVP-спринта: 6–12 недель от брифа до релиза, фиксированные объём и цена, оплата в два шага — 50% на старте и 50% на релизе. Ориентир бюджета — 2–5 млн ₸ в зависимости от сценария и платформ; при меньшем бюджете scope первой версии сужается до самого ценного, а не раздувается ценник.
Бриф: границы scope
Важная деталь формата: на брифе отдельным списком фиксируется, что в MVP НЕ входит.
Кликабельный прототип
Прототип ключевых экранов появляется до начала разработки — правки на макетах в разы дешевле правок в коде.
Спринты с живым демо
Дальше разработка идёт спринтами по две недели, в конце каждого — живое демо: видно, как продукт собирается, и можно корректировать курс.
Типичные ошибки при составлении scope
Одни и те же ошибки встречаются в большинстве ТЗ на первую версию:
- 35 экранов в первой версии: продукт проектируется «как у лидера рынка», хотя у лидера эти экраны появились за годы итераций по данным.
- «Сразу iOS, Android и веб»: каждая платформа добавляет объём разработки, тестирования и поддержки — насколько именно, зависит от стека и доли общего кода, — а для проверки гипотезы обычно достаточно одной.
- Нет аналитики: продукт запущен, а что с ним происходит — неизвестно; решения о развитии принимаются вслепую.
- Сложная система ролей до первого пользователя: недели работы на функциональность, которой некому пользоваться.
- Выбор экзотического стека: модная технология без рынка специалистов делает продукт заложником одной команды.
Чеклист: как решить, что входит в вашу первую версию
Быстрая самопроверка перед стартом. Пройдитесь по каждой функции из вашего списка и задайте четыре вопроса:
- Без этой функции гипотеза проверяется?
- Пользователь сможет пройти главный сценарий?
- Можно ли заменить функцию ручным процессом на первый месяц?
- Появится ли из-за неё вторая платформа или сложная интеграция?
Если функция не проходит проверку — она едет в V2. Такой разбор занимает час, а экономит недели разработки.
