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

Главная ошибка возникает, когда MVP путают с дешевой или небрежной разработкой. Минимальность относится к объему решения, а не к качеству его замысла и исполнения. Если продукт не решает заявленную задачу, результаты проверки будут мало полезны. Иногда команда месяцами полирует продукт, который рынок еще не попросил. Получается почти идеальный ответ на вопрос, которого никто не задавал.

Собственнику стоит заранее определить, какую гипотезу проверяет запуск, какой пользователь должен воспользоваться продуктом и по каким признакам команда примет решение о продолжении. Без этого MVP превращается в набор функций без понятного вывода. Сам факт запуска еще не подтверждает PMF, поскольку интерес пользователей может оказаться случайным или не перейти в устойчивое использование.

Андрей Волков рассматривает MVP как управленческий инструмент проверки, а не как повод перенести недоработки на пользователя. Поэтому до запуска нужно отделить обязательную функцию от удобного дополнения и понять, какую проблему продукт обязан решить уже в первой версии.

Команда планирует новый сервис для работы с заявками клиентов. Вместо разработки всех интеграций и сложного личного кабинета она запускает базовый сценарий обработки заявок для ограниченной группы пользователей. Если пользователи не доходят до этого сценария или не видят в нем ценности, команда получает основание пересмотреть гипотезу до расширения продукта.