AlfricCONTEXT LABby ALFRIC
Подписка

ЖурналПродуктMVP, который проверяет гипотезу, а не собирает фичи

Продукт

MVP, который проверяет гипотезу, а не собирает фичи

Слово «минимальный» команды слышат как «поменьше функций». На деле MVP — это самый дешёвый способ проверить самое рискованное допущение, а не обрезанный релиз.

◷ 6 мин чтения 8 августа 2026 г.
MVP, который проверяет гипотезу, а не собирает фичи

Что на самом деле означает «минимальный»

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

Эрик Рис, который ввёл термин в оборот в «The Lean Startup», определял MVP как версию продукта, позволяющую собрать максимум проверенных знаний о клиентах при минимуме усилий. Ключевое слово здесь не «минимум», а «знания». MVP — это инструмент обучения. Его успех измеряется не тем, что он делает, а тем, что вы после него узнали.

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

Риск-сначала: главный принцип

Правильный MVP строится вокруг одного вопроса: какое допущение, если оно ложно, обрушивает весь проект. Это и есть самый опасный риск. Всё проектирование MVP — это поиск дешёвейшего способа проверить именно его, до того как вложены месяцы разработки.

Обычно самый опасный риск — не технический. Команды инстинктивно тянутся проверять то, что умеют: «а сможем ли мы это построить». Но реализуемость чаще всего не главная ставка. Главная ставка — захочет ли кто-то этим пользоваться и платить. Технически безупречный продукт, решающий несуществующую проблему, — самый дорогой способ ничего не узнать.

Поэтому проектирование MVP начинается с честного ранжирования допущений по опасности, а не по удобству проверки. Выпишите всё, во что вы верите: «у этой аудитории есть эта проблема», «она болит достаточно, чтобы платить», «наше решение заметно лучше текущего способа». Затем спросите про каждое: что будет, если это неправда. Самый смертельный пункт и есть предмет вашего первого эксперимента.

Гипотеза, а не фича-лист

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

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

Здесь работает принцип Карла Поппера в прикладном виде: ценность эксперимента в его способности вас опровергнуть. Если вы не можете назвать результат, который заставит признать идею неверной, вы не ставите эксперимент — вы ищете подтверждение. А подтверждение, как известно, находится всегда.

Ловушка накопления фич

Самая частая деформация MVP — превращение его в свалку компромиссов. Каждый в команде считает свою функцию «абсолютно необходимой для честной проверки». Продажи требуют интеграцию, поддержка — настройки, основатель — вторую половину видения. Каждое требование звучит разумно поодиночке, а вместе они возвращают вас к полугодовой стройке.

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

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

После запуска: читать поведение, а не мнения

MVP запущен — начинается самая недооценённая часть: интерпретация. Здесь легко обмануться. Люди в опросах хвалят, но не возвращаются. Метрика тщеславия вроде числа регистраций растёт, а ключевое поведение — нет. Правда почти всегда в действиях, а не в словах: что человек сделал, вернулся ли, заплатил ли.

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

Частые вопросы

MVP — это первая версия продукта?

Нет. Первая версия продукта нацелена на пользу и удержание. MVP нацелен на обучение: снять максимум неопределённости за минимум усилий. Иногда MVP вообще не содержит рабочего продукта — лендинг, ручная имитация услуги или интервью с предоплатой тоже проверяют гипотезу.

Как выбрать, что войдёт в MVP?

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

Что считать успехом MVP?

Критерий успеха формулируется ДО запуска и в измеримых терминах поведения, а не мнения. Не «людям понравилось», а, например, доля тех, кто прошёл ключевое действие или заплатил. Без заранее записанного порога любой результат можно истолковать как победу.

Context / Weekly

Одна идея, одно исследование, одно наблюдение и один инструмент — раз в неделю. О памяти, внимании и будущем работы. 5 минут чтения.

Эту проблему мы не только исследуем

Alfric сохраняет контекст встреч, задач и договорённостей и возвращает его тогда, когда он нужен. Записи остаются на вашем компьютере.

Узнать об Alfric →