Совет "начни с MVP" звучит почти как правило без исключений, но исключения есть, и игнорировать их так же опасно, как игнорировать сам MVP. Разберём, когда первая упрощённая версия действительно нужна, а когда она только тормозит запуск.
Когда MVP нужен почти наверняка
Главный признак, что без MVP не обойтись: гипотеза не проверена. Если никто ещё не показал, что люди готовы платить за такое решение именно такой аудитории, любые деньги, вложенные в полноценный продукт, это ставка вслепую. MVP здесь не формальность, а способ не потерять полгода и бюджет на то, что рынку не нужно в этом виде.
Второй признак: ограниченный бюджет. Когда денег хватает на одну попытку, разумнее потратить её на минимальную версию, которая отвечает на главный вопрос, чем на продукт с полным набором функций, который может не найти своего пользователя вообще. MVP в этом случае страховка от того, что весь бюджет уйдёт в стол.
Третий признак: рынок, где ещё нет устоявшегося поведения пользователей. Если непонятно, как именно люди будут взаимодействовать с продуктом, никакие исследования и опросы не заменят наблюдения за реальным использованием хотя бы упрощённой версии.
Когда можно и стоит делать сразу полноценный продукт
Здесь совет "сначала MVP" перестаёт работать в двух конкретных ситуациях.
Первая: спрос уже подтверждён. Если у вас уже есть работающий бизнес офлайн с постоянными клиентами и вы просто переносите его в цифровой формат, или если конкуренты в нише годами доказывают, что модель работает, гипотезу можно считать частично проверенной чужими руками. В этом случае MVP рискует превратиться в лишний круг, который просто откладывает выход на рынок, где вы и так знаете, что продукт нужен.
Вторая: есть инвестиции и понятный план их использования. Когда в проект уже вложены деньги под конкретную стратегию, а не под "давайте попробуем и посмотрим", урезанная версия может создать больше проблем, чем решить. Инвесторы и партнёры ожидают продукт определённого уровня, и MVP с явно ограниченным функционалом иногда портит первое впечатление сильнее, чем задержка запуска на пару месяцев ради более полной версии.
Есть и промежуточный случай: иногда MVP нужен только для одной конкретной части продукта, например новой функции внутри уже работающего сервиса. Масштаб такого теста намного меньше, чем проверка всей бизнес-идеи, потому что затрагивает только эту функцию.
Как принять решение в своём случае
Стоит задать себе три вопроса. Проверял ли кто-то раньше похожую гипотезу на похожей аудитории, хотя бы косвенно. Сколько попыток себе можно позволить финансово, одну или несколько. И насколько предсказуемо поведение вашей будущей аудитории, есть ли на рынке аналоги, за которыми можно наблюдать.
Если ответы указывают на неопределённость хотя бы по двум из трёх пунктов, MVP почти наверняка окупит время, потраченное на его сборку. Если спрос и поведение аудитории предсказуемы, а бюджет позволяет один серьёзный заход, можно двигаться сразу к более полной версии, не теряя время на промежуточный этап.
На практике решение редко принимается в одиночку: разговор с человеком, который будет делать продукт, часто расставляет всё по местам. Он видит сложность задачи и реальные сроки и может честно сказать, где риск, а где перестраховка. В SolaLab это обсуждается на первом же созвоне: если гипотеза сырая, предлагается MVP, если спрос уже понятен, сразу считается полноценная версия, без искусственного удлинения пути там, где в нём нет смысла.
Опишите свою ситуацию, включая то, что уже проверено и какой бюджет заложен, и разберём вместе, нужен ли вам MVP или можно сразу переходить к полноценной разработке.