MVP: что это такое и что из продукта придётся вырезать

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

MVP (minimum viable product, минимально жизнеспособный продукт) — версия продукта с минимальным набором функций, которой уже можно пользоваться и на которой можно проверить главную гипотезу. Термин ввёл Фрэнк Робинсон, а широкую известность ему принесла книга Эрика Риса «Бережливый стартап».

Ключевое слово — «гипотеза». MVP существует, чтобы что-то узнать. Если вы не можете сформулировать, что именно хотите проверить, то строите не MVP, а просто первую версию.

Почему большинство «MVP» ими не являются

Самая частая ошибка — назвать MVP полный продукт с урезанным дизайном. Так появляется проект, в котором есть всё: регистрация, профили, настройки, уведомления, админка, тарифы, — но ничего из этого не доведено до ума. Пользователь видит сырой продукт, команда тратит бюджет, а ответа на главный вопрос по-прежнему нет.

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

Как решать, что войдёт в первую версию

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

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

Третий — честный список того, что вы уже знаете и чего не знаете. Проверять нужно только второе.

Что можно делать руками вместо кода

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

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

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

Как это выглядело в наших проектах

Rivopost. Полный цикл ведения Telegram-канала — это мониторинг источников, фильтрация, генерация черновиков, контент-план и публикация по расписанию. Если строить всё сразу, первая версия не выйдет никогда. Проверять здесь нужно одно: готов ли владелец канала доверить публикацию внешнему сервису.

Kursly. Агрегатор курсов обмена мог бы начинаться с десятка площадок, личных кабинетов и истории сделок. Но гипотеза была в другом: будет ли пользователь возвращаться за сравнением с учётом реальной комиссии, а не только курса «на бумаге». Для этого достаточно точных данных по нескольким площадкам и работающего калькулятора.

BelTimberExport. Для B2B-экспорта соблазн — сделать полноценный кабинет покупателя с заказами и документами. На деле сначала нужно было проверить, доходят ли китайские покупатели до структурированной заявки: каталог пород, калькуляторы кубатуры и загрузки контейнера, пошаговая форма.

MVP, прототип и proof of concept — в чём разница

Эти три слова часто используют как синонимы, хотя они отвечают на разные вопросы.

• Прототип отвечает на вопрос «понятно ли это?». Кликабельные макеты, внутри ничего не работает.
• Proof of concept отвечает на «получится ли технически?». Проверяет один рискованный кусок, например точность распознавания или скорость обработки. Пользователям его не показывают.
• MVP отвечает на «будут ли этим пользоваться?». Работающий продукт в руках реальных людей.

Четыре ошибки, которые дорого стоят

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

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

Объём растёт тихо. Договоритесь заранее: новая функция входит в MVP только вместо другой, а не в дополнение.

Технические решения «на выброс». Первая версия всё равно живёт дольше, чем планировали. Скорость важнее идеальности, но база данных и авторизация, сделанные наспех, аукнутся.