Как не вложиться в синхрофазотрон. Не бояться запускать MVP

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

Или в процессе бизнес-анализа решение обрастает функционалом, который кажется критически необходимым. И вроде как маленький и простой продукт на старте превращается в сложносочиненный комбайн, к которому непонятно как подступиться.

В итоге из-за сложности проекта мотивация двигаться вперёд теряется и чаще всего это приводит либо к долгострою, либо к заморозке.

Выход один — брать волю в кулак, отсекать важные, но не нужные сейчас функции и идти на рынок проверять решение.

Как подойти к запуску MVP:

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

▫️ Принять, что ошибки — это ОК. Ошибки обязательно будут и помогут улучшить решение. Важно только учиться на них :)

▫️ Быстро адаптироваться. Запуск MVP позволяет быстро реагировать на отзывы и гибко вносить изменения.

▫️ Разумно экономить ресурсы. Не влетаем на всю котлету, двигаемся короткими шагами. Риски потерять капитал меньше.

▫️ Двигаться циклами проверки гипотез. Выдвигаем гипотезу и критерии проверки, запускаем, проверяем, делаем выводы, модернизируем продукт и двигаемся дальше.

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

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

@mvmst_it