Главная ошибка MVP
Команда пытается запихнуть в первый релиз «полуплатформу». В итоге дедлайн срывается, а ценность не проверяется.
Рабочая модель приоритета
- P0: без этого продукт не работает.
- P1: влияет на выручку/активацию.
- P2: улучшения после первых пользователей.
Правило спора
Если по фиче нет численного влияния на активацию/retention/revenue в горизонте 30 дней — это не MVP.
Scope freeze
За 2 недели до релиза — только баги и риски запуска. Новые фичи идут в следующий спринт.
Чеклист
- Есть P0/P1/P2
- Есть метрика успеха MVP
- Есть список того, что НЕ делаем
- Есть дата scope freeze
Как считать "must-have" без субъективщины
Если у команды 5 разных мнений по приоритетам, используйте короткую scoring-модель:
Score = (Impact on activation + Revenue proximity + Risk reduction) / Effort
Оценки по шкале 1-5 достаточно, главное — одинаковые критерии для всех фич.
Типовая матрица решения
| Фича | Impact | Effort | Revenue | Итог |
|---|---|---|---|---|
| Регистрация + onboarding | 5 | 2 | 4 | P0 |
| Интеграция с CRM | 4 | 4 | 5 | P1 |
| Темная тема | 1 | 1 | 1 | P2 |
Матрица не идеальна, но она убирает спор "мне кажется это важно".
Что включать в MVP почти всегда
- стабильный login/signup;
- один core user flow;
- базовая аналитика;
- support-канал (формы/чат/email);
- механизм обновления контента/настроек без релиза.
Без этого запуск есть, а управляемого продукта нет.
Что чаще всего можно отложить
- сложные роли и permissions;
- дашборды "для всех отделов";
- реферальные программы;
- deep personalization;
- продвинутый billing, если нет устойчивого спроса.
Scope freeze: как внедрить мягко
Чтобы бизнес не воспринимал freeze как блокировку, задайте правило:
- любые новые идеи фиксируются в backlog;
- в текущий релиз попадают только через swap: добавили 1 фичу — убрали 1 фичу такого же веса.
Это сохраняет предсказуемость сроков и снимает конфликт "вы тормозите продукт".
Метрики успеха MVP
MVP считается успешным не когда "запустили", а когда есть сигнал рынка:
- % пользователей, завершивших core flow;
- retention 7/14 дней;
- конверсия в целевое действие (заявка/оплата/повторный визит);
- qualitative feedback без критичных блокеров.
Anti-patterns, которые губят срок
- нет owner решения по приоритетам;
- "сделаем ещё одну маленькую фичу" каждую неделю;
- не фиксируют, что не входит в релиз;
- backend и frontend живут разными roadmap.
Вывод
Сильный MVP — это дисциплина scope и ясные критерии успеха. Лучше выпустить маленький, но измеряемый продукт за 8-10 недель, чем полную "идеальную" версию без валидации спроса.