MVP: как определить границы первой версии продукта и что в неё не включать

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

MVP — минимально жизнеспособный продукт — самое затёртое понятие в продуктовой разработке. Под ним понимают и кликабельный прототип, и урезанную версию будущей платформы, и продукт, который «сделаем быстро, а потом переделаем». Из-за этой размытости компании регулярно платят за MVP как за полноценный продукт или, наоборот, запускают настолько сырую версию, что она не проверяет ничего, кроме терпения первых пользователей. Эта статья не про стоимость — о бюджетах мы подробно писали в материале о стоимости разработки веб-платформы . Здесь речь о другом: как определить, что входит в первую версию продукта, а что нет, и как не превратить MVP ни в прототип без смысла, ни в платформу на год разработки. Что такое MVP на самом деле Определение, которое работает на практике: MVP — это наименьшая версия продукта, которая позволяет проверить главную гипотезу о ценности на реальных пользователях в реальных условиях. В этом определении три важных слова. Главную. MVP проверяет одну гипотезу, от которой зависит судьба продукта, а не все сразу. Если гипотез несколько, нужно понять, какая из них, будучи ложной, делает бессмысленными остальные. Реальных пользователях. Не фокус-группа, не опрос «стали бы вы пользоваться», а люди, которые решают свою задачу с помощью продукта. Опрос измеряет вежливость, использование измеряет ценность. Реальных условиях. Пользователь тратит время, деньги или репутацию. Если он ничем не рискует, его поведение мало говорит о том, как он поведёт себя с настоящим продуктом. Отсюда следует неочевидный вывод: MVP определяется не набором функций, а гипотезой. Два продукта с одинаковым функционалом могут быть MVP для разных гипотез, и один и тот же список функций может оказаться избыточным для одной гипотезы и недостаточным для другой. Чем MVP не является Прототип Прототип проверяет, понятен ли интерфейс и правильно ли выстроены сценарии. Он не проверяет, готовы ли люди пользоваться продуктом регулярно, платить за него или менять ради него привычный процесс. Прототип — отличный инструмент до MVP, но не его замена. Первая версия большой платформы Если в плане разработки первая версия — это «всё то же самое, что в финальной, только без отчётов и с одним способом оплаты», это не MVP, а первый релиз. В нём уже заложена архитектура, рассчитанная на функции, ценность которых никто не проверил. Плохо сделанный продукт Минимальный — не значит некачественный. Пользователь не отличает «мы проверяем гипотезу» от «продукт не работает». Если регистрация ломается у каждого пятого, MVP проверит не ценность продукта, а устойчивость людей к ошибкам. Урезать нужно объём, а не качество того, что вошло в объём. Продукт, который потом выбросят Иногда MVP действительно выбрасывают — например, если он был собран на конструкторе для проверки спроса. Но это должно быть осознанным решением, а не последствием спешки. Если планируется развивать продукт дальше, первая версия должна строиться так, чтобы её можно было расширять без полной переделки. Шаг 1. Сформулировать гипотезу ценности Начинать нужно не со списка функций, а с утверждения, которое продукт должен подтвердить или опровергнуть. Хорошая гипотеза имеет форму: «Сегмент пользователей X, решая задачу Y, выберет наш способ Z вместо текущего, потому что получит выгоду W». И к ней — измеримый критерий успеха. Пример для B2B-сервиса: «Менеджеры по закупкам в производственных компаниях на 50–500 сотрудников будут размещать заявки поставщикам через сервис вместо почты и таблиц, потому что сервис сокращает время сравнения предложений. Критерий: не менее 30% компаний, получивших доступ, размещают через сервис три и более заявки в течение первого месяца». Пример для потребительского приложения: «Родители детей до трёх лет будут пользоваться приложением для учёта развития ребёнка чаще раза в неделю, если приложение подсказывает, что делать дальше, а не только хранит данные. Критерий: удержание на четвёртой неделе не ниже 25%». Числа в критериях условные и зависят от рынка. Важно другое: критерий определяется до запуска. Если его формулируют после, почти любой результат удаётся интерпретировать как успех. Как выбрать главную гипотезу из нескольких Обычно у нового продукта есть гипотезы о проблеме (у людей действительно есть эта боль), о решении (наш способ её снимает), о канале (мы можем привлекать пользователей по разумной цене) и о монетизации (за это будут платить). Порядок проверки определяется вопросом: какая гипотеза, если окажется ложной, делает остальные неважными? Чаще всего это гипотеза о проблеме и решении. Проверять готовность платить за продукт, которым никто не пользуется, преждевременно. Шаг 2. Описать один сквозной сценарий Гипотеза определяет сценарий, который должен пройти пользователь, чтобы ценность проявилась. Этот сценарий должен быть сквозным — от момента, когда человек впервые узнаёт о продукте, до момента, когда он получил результат. Для сервиса закупок это может выглядеть так: менеджер получает приглашение, регистрирует компанию, создаёт заявку, отправляет её поставщикам, получает предложения, сравнивает их и выбирает победителя. Каждый шаг этой цепочки должен работать. Если отсутствует хотя бы один — например, поставщики не могут ответить на заявку внутри сервиса, — гипотеза не проверяется, какими бы качественными ни были остальные шаги. Отсюда правило: в MVP лучше один сценарий, работающий от начала до конца, чем пять сценариев, каждый из которых обрывается на середине. Широкий, но неглубокий продукт не даёт пользователю дойти до ценности ни в одном месте. Шаг 3. Разделить функции на три корзины Когда сценарий описан, каждая предлагаемая функция проходит проверку одним вопросом: без неё пользователь может пройти сценарий и получить ценность? Корзина 1. Без этого сценарий не работает Функции, без которых цепочка обрывается. Они входят в MVP обязательно и делаются качественно. Для сервиса закупок: создание заявки, рассылка поставщикам, форма ответа, сравнение предложений. Корзина 2. Можно сделать вручную Функции, которые нужны, но в первой версии их может выполнять человек. Это самая недооценённая корзина. Регистрация компании может проходить через заявку, которую вручную проверяет сотрудник. Счета на оплату можно выставлять из учётной системы, а не генерировать в продукте. Уведомления поставщикам можно отправлять вручную, пока компаний десятки, а не тысячи. Ручная работа не масштабируется, но MVP и не должен масштабироваться. Он должен проверить гипотезу. Если гипотеза подтвердится, автоматизировать ручные операции будет проще, потому что станет понятно, как именно они выполняются на практике. Корзина 3. Не влияет на проверку гипотезы Всё остальное: расширенные отчёты, настройка интерфейса, интеграции со второстепенными системами, мобильное приложение при работающей веб-версии, роли и права сложнее двух уровней, программа лояльности, темы оформления. Эти функции могут быть важны для зрелого продукта, но их отсутствие не мешает понять, работает ли основная идея. Типичная пропорция на практике: первоначальный список желаемых функций сокращается в несколько раз. Если после разбора по корзинам объём сократился незначительно, стоит проверить, не записаны ли в первую корзину функции, которые на самом деле «очень хочется». Шаг 4. Решить, что обязательно должно быть качественным Сокращение объёма не означает, что всё, что вошло, можно делать как попало. Есть вещи, экономия на которых делает результаты проверки недостоверными или создаёт риски, несоразмерные выигрышу во времени. Основной сценарий. Должен работать стабильно и быть понятным без инструкции. Иначе вы измерите качество реализации, а не ценность идеи. Безопасность и персональные данные. Утечка данных первых клиентов — не тот урок, который стоит получать на этапе проверки гипотезы. Требования 152-ФЗ действуют независимо от стадии продукта. Платежи. Если продукт принимает деньги, платёжный контур должен работать корректно с первого дня: чеки, возвраты, обработка неуспешных оплат. Аналитика. Без измерения поведения пользователей MVP не выполняет свою функцию. События, нужные для проверки критерия успеха, должны быть настроены до запуска. Модель данных. Интерфейс легко переделать, данные — сложно. Если продукт планируется развивать, базовые сущности и связи между ними стоит продумать с запасом. Шаг 5. Выбрать способ реализации Одна и та же гипотеза может проверяться продуктами очень разной сложности. Выбор зависит от того, что именно проверяется и насколько важна скорость. Без разработки Лендинг с описанием продукта и формой заявки проверяет интерес, но не ценность. Ручное оказание услуги с имитацией продукта — так называемый «консьерж» — проверяет ценность на небольшом числе клиентов: команда вручную делает то, что потом будет делать продукт. Подходит, когда главный вопрос — нужна ли людям сама услуга. Конструкторы и no-code Готовые платформы позволяют собрать работающий продукт с базовой логикой за дни или недели. Ограничения появляются при нестандартной логике, высокой нагрузке и требованиях к хранению данных. Разумный выбор, если продукт укладывается в возможности платформы и есть готовность при успехе переписать его заново. Быстрая разработка с помощью AI Современные AI-инструменты заметно ускоряют создание первых версий: интерфейсы, типовая серверная логика, интеграции с документированными API пишутся существенно быстрее, чем несколько лет назад. У подхода есть границы: сложная предметная логика, безопасность и поддерживаемость кода по-прежнему требуют инженерного контроля. Где проходит эта граница, мы разбирали в статье о вайбкодинге . Для проверки гипотез за дни, а не месяцы у нас есть отдельный формат — вайбкод-разработка . Классическая разработка Необходима, когда продукт с первого дня работает с чувствительными данными, деньгами, сложными интеграциями или должен выдерживать заметную нагрузку. Главная задача в этом случае — не экономить на архитектуре основы, но жёстко ограничивать объём функций. Типичные ошибки при определении MVP MVP для инвесторов, а не для пользователей Продукт строится так, чтобы эффектно выглядеть на демонстрации: много экранов, красивые графики, заглушки вместо логики. Такой продукт помогает рассказать идею, но не проверяет её. Если цель — привлечение финансирования, честнее назвать результат демонстрационной версией и не путать его с проверкой рынка. Страх показать неидеальное Команда откладывает запуск, пока не будет готово «ещё немного». Каждая неделя задержки — это неделя без данных о том, нужен ли продукт вообще. Если первая версия не вызывает у команды лёгкого дискомфорта, скорее всего, запуск был отложен слишком надолго. Нет критерия успеха Продукт запущен, пользователи есть, но непонятно, хорошо это или плохо. Сто регистраций — много или мало? Если заранее не договориться о пороге, результат будет интерпретироваться в пользу уже принятого решения. Слишком широкая аудитория «Наш продукт для всех малых и средних компаний» — плохая аудитория для MVP. Разные сегменты по-разному используют продукт, и их поведение смешивается в статистике. Узкий сегмент с похожими задачами даёт чистый сигнал. Расширять аудиторию имеет смысл после того, как ценность подтверждена хотя бы для одной группы. Архитектура на миллион пользователей Команда закладывает микросервисы, шардирование базы и отказоустойчивую инфраструктуру для продукта, у которого пока нет ни одного пользователя. Это время и деньги, потраченные на решение проблемы, которой может не возникнуть. Разумнее спроектировать систему так, чтобы её можно было масштабировать, но не масштабировать заранее. Подробно о выборе между монолитом и микросервисами — в отдельном материале . Проверка нескольких гипотез одновременно Новая аудитория, новый канал продаж, новая модель монетизации и новый продукт в одном запуске. Если результат плохой, невозможно понять, какое из допущений оказалось неверным. Если хороший — непонятно, что именно сработало. Что делать после запуска MVP Запуск — середина процесса, а не конец. Дальше начинается работа, ради которой MVP создавался. Собирать данные двух типов Количе