Приведите пример, когда вы помогли определить MVP и отложить лишний scope.

Шаг 3: Аргументация отсечения

Для каждой отложенной фичи я зафиксировал аргумент отсечения — не «это сложно», а «без этого MVP всё равно валидирует гипотезу». Пример:

Feature: Certificates
Decision: Defer to v1.1
Rationale: The core hypothesis is "users will pay and complete lessons".
Certificates add value after completion, but don't affect whether
users start or pay. We can validate demand before building.
Review trigger: If >30% of users complete a course, add certificates.

Это важно: бизнес легче принимает «отложить», если понимает условие возврата к фиче.

Ситуация

Команда планировала запуск «полноценной» платформы для онлайн-курсов: видео-плеер, прогресс-трекинг, сертификаты, форум, система оценок, мобильное приложение. Оценка разработки — 6 месяцев. Бизнес нервничал: за 6 месяцев рынок мог измениться, и никто не знал, нужно ли пользователям вообще то, что мы строим.

Шаг 1: Определить реальную ценностную гипотезу

Я организовал сессию по методу Opportunity Solution Tree (Teresa Torres). Ключевой вопрос: «Что минимально должно работать, чтобы пользователь получил базовую ценность и мы могли проверить спрос?»

После часового обсуждения сформулировали: «Пользователь оплачивает курс и проходит урок». Всё остальное — расширение этой базовой ценности.

Шаг 2: Feature Mapping — карта «обязательное vs. желаемое»

Я провёл сессию Feature Mapping с PO, тимлидом и представителем бизнеса. Взяли все запланированные фичи и рассортировали по трём категориям:

• Must Have (MVP): Регистрация, оплата, список уроков, просмотр видео, базовый прогресс (отметить урок пройденным)
• Should Have (v1.1): Сертификаты, детальный прогресс-трекинг
• Nice to Have (backlog): Форум, мобильное приложение, система оценок

Шаг 4: MVP как эксперимент, а не урезанный продукт

Я переформулировал MVP не как «продукт без части функций», а как «эксперимент для проверки конкретной гипотезы»:

• Гипотеза: пользователи готовы платить за доступ к видеокурсам
• Метрика: 50 платных подписок за 8 недель
• Если гипотеза не подтверждается — пересматриваем продукт, а не добавляем фичи

Результат

MVP вышел через 6 недель вместо 6 месяцев. Через 8 недель — 73 платные подписки. Сертификаты добавили в v1.1, форум — перенесли в backlog навсегда (никто не просил). Мобильное приложение — запустили через год.

Подводные камни

• MVP — не «всё то же самое, но быстро сделано»: если сократить качество, а не scope, получится низкокачественный продукт, а не MVP.
• Откладывать фичи без условия возврата: «отложить» без критерия возврата = «забыть навсегда», что создаёт обиды в команде.
• Включать в MVP фичи «потому что обещали клиенту»: это не MVP, это контрактное обязательство — их нужно обсуждать отдельно.
• Не формулировать гипотезу: без неё непонятно, что именно MVP должен доказать.
• Игнорировать «nice to have» голоса в команде: разработчики иногда хотят сделать «правильно» сразу, что раздувает scope.
• Считать, что пользователи скажут вам, чего хотят: они скажут о проблемах, а не о правильных решениях — MVP нужен именно для проверки вашего решения.

• Назвать MVP любую урезанную версию.
• Убрать критичный сценарий ради сроков.
• Не зафиксировать, что ушло в backlog и при каких условиях вернётся.

• Отделяет must-have от nice-to-have.
• Сохраняет ценность при сокращении scope.
• Фиксирует roadmap после MVP.