MVP часто ломается не из-за объёма, а из-за неверной проверки гипотезы

MVP часто ломается не из-за объёма, а из-за неверной проверки гипотезы

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

Типовые ошибки:
— проверять удобство, когда не доказана ценность;
— делать «как в будущем продукте», хотя нужен прототип сценария;
— мерить регистрации вместо действия, которое подтверждает намерение;
— добавлять функции для стейкхолдеров, а не для проверки гипотезы.

Хороший MVP режется не по экранам, а по рискам. Сначала формулируем гипотезу: «если дадим X аудитории Y в ситуации Z, они сделают N». Потом выбираем самый дешёвый способ увидеть N: лендинг, ручной сервис, мок, консьерж, закрытый пилот.

Критерий готовности: команда заранее знает, какое решение примет при каждом результате. Если данные не меняют roadmap, это не MVP, а демо.

Собирайте MVP вокруг одного решения: продолжать, менять гипотезу или закрывать идею. Всё остальное — лишний scope.