Как часто стоит выпускать MVP, как оценивать их успешность и что именно должно измениться, чтобы это действительно была новая версия продукта, а не простая доработка.
MVP0 может значительно отличаться от MVP1 и дальнейших версий. Более того, именно на этапах разработки MVP может случиться пивот в бизнесе, о котором я говорила в прошлой статье. Вы можете прийти к выводу, что нужно сломать всё, чтобы построить заново — изменить технологии или принять другие ключевые решения.
Как относиться к MVP
MVP — это проверка гипотез и всего лишь текущее видение продукта. Это то, к чему вы идёте. Поэтому не нужно ракетой бежать и рваться его запустить. Возможно, для начала достаточно будет ограниченного тестирования, в рамках которого вы поймёте, что были приняты неправильные решения.
Но! Прежде чем от них отказываться, чётко распишите за и против: какие решения были удачными, какие нет. Получите экспертную оценку на стороне, чтобы понять, что какие-то шаги действительно были неверными.
MVP и правильный выбор целевой аудитории
Простой пример из моей практики. Был проект, который показали соучредителям. И он никому не понравился. Только дело было в том, что целевая группа, которая оценивала проект, была в возрасте от 45 лет, так что идея им была просто непонятна.
Поэтому я всё же взяла на себя ответственность и инициировала пилот. Даже не смотря на то, что все говорили: «Не годится, надо полностью всё переделывать». В итоге мы приступили к пилотированию приложения для разных участников из разных возрастных групп.
Всего было 3 группы: до 30 лет, от 30 до 50 и третья — старше 50 лет. В каждой из них находилось около 50 человек. Так вот первые две группы оценили приложение на 80% успешным. Для них оно было понятным и удобным. А последняя группа, где респондентам было более 50 лет, приложение не оценили. Этим и объяснялся провал у соучредителей.
Само приложение работало как агрегатор. Оно собирало из различных источников информацию по событиям, связанным с блогерами и знаменитостями, — где публикуются, где засвечены, какие есть сплетни. Кстати говоря, потом приложение было куплено за бешенные деньги за границей.
Поэтому запомните: запуск MVP нужно планировать на ту аудиторию, на которую он рассчитан.
Промежуточные версии
Также важная вещь: ваши MVP — не панацея. Между ними у вас могут выходить и промежуточные версии, где будет проводиться техническое тестирование. И это тоже ок.
Временные промежутки между MVP должны быть не супер большими. Нельзя MVP0 запустить в начале года, а MVP1 — в конце. Это большой разрыв, который не даст понять, а правильно ли вы вообще всё делаете.
Самый долгий по подготовке запуск — это MVP0. Следующие должны идти через 2-3 месяца. Лучше включить меньше в MVP, но выполнить его за более короткий срок, чем оснастить его всем возможным и отложить запуск на неопределённый срок.
Что такое MVP и чем оно не является
MVP — не просто добавление функций в каждую итерацию. На самом деле это либо новая концепция, либо расширение функциональных возможностей в рамках продукта. Многие путают и называют MVP функционал, который они просто доделали: «Теперь наша система работает быстрее, и это MVP1».
Нет! MVP — это набор новых функций и возможностей, которые касаются всего продукта. Если вы от MVP0 решили переделать только интерфейсы, то это не будет MVP1. Это будет MVP0 с измененным функционалом.
Каждый MVP — это набор функций, которые пойдут в продукт и которые вы хотите попробовать. Но это не догма, а возможность быть в курсе продукта и понимать, верно ли вы двигаетесь. Поэтому после MVP0 у вас может и не получиться продукт. Он может получиться после третьей, пятой или даже пятнадцатой версии.
Когда мы с командой делали большие проекты с серьёзным финансированием, то MVP0 и MVP1 собирались из разных версий с разным функционалом. На каждом этапе реализации проходило тестирование дизайна, разработки и т.д. После этого принималось решение: продолжаем или нет. В MVP мы включали именно финишное видение продукта. То есть была некая промежуточная разработка, которая не считалась за MVP.
Как оценить успешность запуска MVP?
Запуск MVP не означает, что вы сделали успешный продукт. Это только проверка гипотезы и выполнение тех задач, которые были поставлены. Вот вы планировали в MVP3 запустить 6 функциональных решений — вы их запустили. Даже если на выходе будет получен негативный отклик, это всё равно успех. Только связан он не с самим продуктом, а с конкретным MVP.
И напоследок…
Если вы делаете MVP0, затем MVP1, потом 2-3-4 и всё не нравится, то это проблема не MVP. Это вопрос принятых решений. Не смотря на то, что часть функционала с каждым MVP будет отпадать, что-то позитивное обязательно должно переходить в разработку дальнейших версий, чтобы потом стать частью продукта, который вы задумали.
★★★★★
Есть вопросы? У меня есть ответы :) Спрашивайте в комментариях — я на связи.
Кстати, эта статья написана по мотивам четвёртого выпуска второго сезона нашего подкаста «Как там бизнес?» Послушать его можно по ссылке.
Подписывайтесь, читайте нас на Дзене и в соцсетях, смотрите на YouTube и слушайте в наушниках. Мы рады делиться полезным и интересным. Пока-пока!