225. MVP не всегда проще самого продукта

MVP — это версия продукта, обладающая минимально ощутимой ценностью для потребителя. Создание MVP является целью этапа Customer Discovery и перехода на этап Customer Validation.

Крайне важно создать MVP таким, чтобы можно было протестировать гипотезу, которая чаще всего является сложносоставной. Для этого мы создали CDDC-канвас.

Считается, что MVP должен быть дешевым, простым и не всегда удобным. На самом деле существует еще одно очень важное требование к MVP: он должен давать возможность собирать метрики, необходимые как для HADI-циклов, так и для CDDC.

Но главное — возможность проверять гипотезы!

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

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

Это все гипотезы. И для их тестирования (проверки) нужно... MVP.

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

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

В сухом остатке: MVP может быть сложнее самого продукта; главное — скорость, данные и гибкость.

#mvp@custdevlab #гипотезы@custdevlab

P.S. Если есть прототип продукта, но он не позволяет собирать нужные для дальнейшего развития данные, то это не MVP.