MVP за 2 месяца: что можно урезать без вреда для гипотезы, а что нельзя

Самая частая ошибка на этапе MVP — не нехватка времени или бюджета, а неправильный вопрос. Команда спрашивает "что мы успеем сделать за 2 месяца?", вместо того чтобы спросить "какой минимальный набор функций докажет или опровергнет нашу гипотезу?".

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

Что мы оставили в скоупе. Регистрация и профиль (ментор/подопечный), календарь с доступными слотами ментора, бронирование сессии, встроенный видеозвонок через готовый SDK, оплата сессии картой.

Что мы сознательно вынесли за скобки. Чат внутри платформы — можно вести общение по email. Рейтинги и отзывы — важны на масштабе, но не критичны на первых 50 пользователях. Рекомендательный алгоритм — на такой выборке ручной подбор куратором работает не хуже.

Как понять, что можно резать. Если функция решает проблему масштаба — она может подождать. Если функция — часть основного пользовательского пути, без которого гипотеза не проверяется вообще, резать нельзя.

Результат урезанного скоупа. MVP был запущен за 9 недель вместо изначально предполагаемых 4–5 месяцев. Первые 50 менторов и 300 подопечных подключились за первый месяц закрытого теста.

Вывод. Хороший MVP — это не "маленький продукт", это минимальный эксперимент, упакованный в форму продукта.