MVP (minimum viable product) - это первая версия вашего продукта, с помощью которой вы, как создатель продукта:
-
подтверждаете гипотезу о необходимости конкретного решения, опираясь на поведение пользователей;
-
собираете обратную связь от ваших будущих пользователей;
-
пытаетесь продать (или уже продаёте) ваше решение пользователям.
Пройдёмся по этим пунктам.
Возьмём в качестве примера не сложный IT-продукт, а самый обычный, бытовой предмет: швейцарский нож.
Однажды люди нащупали гипотезу, которая могла явиться проблемой: что если я оказываюсь в диком лесу, и мне нужно срезать гриб и отметить это, выпив бутылку шампанского? Носить с собой штопор и нож - попросту неудобно (да и кто в здравом уме берёт с собой в лес штопор?). Что, если объединить эти инструменты в одно?
Эти люди (назовём их фаундерами) попробовали совместить штопор и нож в одном инструменте, создали первый прототип (получилось криво и неудобно, но годно), и попытались продать будущим клиентам.
Представим, что у них это получилось. Что им делать в таком случае?
-
продолжать продавать текущее решение, параллельно добавляя туда новые инструменты (функции), опираясь на обратную связь и пожелания покупателей;
-
совершенствовать текущее решение, делать его более удобным (работать над UX);
-
собирать обратную связь от пользователей и корректировать продукт.
Но всё получается с первого раза только у создателей швейцарских ножей. В реальной жизни 42% стартапов умирают от отсутствия спроса. Каждый раз фаундеры могут заходить на рынок с новым набором инструментов (пробовать разные гипотезы), либо, если всё идет наперекосяк - менять бизнес модель (сделать Pivot).
С каждой версией швейцарского ножа, нашим фаундерам нужно как можно быстрее выпустить образец на рынок, чтобы услышать обратную связь от покупателей.
Как это можно сделать?
-
Производить и пытаться продать совсем маленькие партии;
-
Экономить на качестве (но не так, чтобы получилось совсем плохо).
Именно такой подход: быстро создать решение, протестировать на пользователях, услышать обратную связь, и выйти на второй цикл улучшения продукта (или на смену бизнес-модели) и можно назвать MVP-подходом.
Как отбирать гипотезы и функции
Гипотеза - это предположение о проблеме клиента.
В одной версии продукта стоит тестировать только одну гипотезу за раз. При этом гипотеза должна быть смелая. Хотят ли люди есть грибы? Определенно да! Готовы ли пить шампанское? О да! Но может ли кому-то внезапно понадобится и нож, и штопор одновременно? Это уже гипотеза, которую стоит протестировать!
Теперь перейдём к тому, что можно включить в первую версию продукта. Ответ прост: нужно включать те функции, которые:
1) работают на проверку ключевой гипотезы. Не добавлять в швейцарский нож сам нож - кощунство;
2) дают наибольшую ценность для пользователя. Да, в швейцарский нож можно напихать ещё и трекер шагов, и bluetooth колонку, но основную ценность в нашем примере имеет нож и штопор.
Все функции, которые не удовлетворяют этим требованиям, можно смело оставлять на будущее.
Валидация без продукта
Можно ли подтвердить гипотезу относительно продукта, совсем не создавая никакого решения?
В IT-сфере - можно, если быть чуть хитрее и умнее, чем наши фаундеры из примера.
К примеру, они могли создать лендинг Чудо Швейцарские Ножи, повести на него трафик из социальных сетей, и посмотреть, оформляют ли люди предзаказ на этот товар. Если да - то его можно производить.
Примеров таких предзапусков в истории множество, но вот мой любимый:
Около 2-х лет создатели таск-менеджера Sunsama запустили на главной странице анкету, в которой опрашивали рабочие привычки будущих пользователей (сколько человек в команде, каким таск-менеджером пользуются сейчас, где хранят задачи и т.д.). Когда вышла первая версия продукта, доступ получили только те, кто подошёл в качестве целевой аудитории этого продукта. Таким образом создатели Sunsama убили трёх зайцев одним махом: исследовали аудиторию, получили первых последователей и подогрели интересы прочих, кто доступ не получил.
К слову, я даже пытался подобрать правильные ответы к анкете, чтобы получить доступ. И у меня это получилось! Но то, что оказалось внутри, мне уже было не интересно (не зря же я подбирал ответы).
Продавать или нет?
Автор книги Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели Эрик Рис говорит, что MVP с первого дня должен продавать. И я с ним абсолютно согласен.
Мы создаем продукты не только для того, чтобы решать проблемы и делать мир лучше, но и чтобы зарабатывать деньги. Если у вас есть инвестиции и собственные запасы, чтобы оплатить работу дизайнеров и разработчиков на долгие годы вперёд (чтобы впоследствии монетизировать платформу), это прекрасно. Если нет продукт должен начать приносить вам деньги уже сегодня (за счёт подписки на сервис, рекламы или взимания платы за интеграцию).
Ошибки при разработке MVP
MVP - это непаханное поле для больших ошибок и слитых бюджетов!
Вот какие ошибки вы можете совершить по ходу пьесы:
-
Включать слишком много необязательных функций. Представьте, что вы Роден (со швейцарским ножом в руке), и без сожаления выбрасывайте то, что не даёт ценности вашему продукту и не поддерживает его жизнеспособность;
-
Не слушать обратную связь от пользователей. Если вы не проводите тестирования и не слушаете обратную связь от пользователей, то вообще непонятно, зачем вы затеяли MVP. Возможно, вам стоит сразу пилить полноценный продукт и оказаться без миллиона в кармане?
-
Слишком стараться. Есть выражение, что если вы показываете первую версию продукта, и вам не стыдно - то вы уже перестарались. Поверьте, у вас будет бесконечно много шансов улучшить ваш продукт, и делать сразу идеально вовсе не обязательно!
-
Недостаточно стараться. Можно придумать отличную идею совместить нож со штопором, но если сделать это в стиле и таааак сойдёт!, то вы рискуете, что ваш пользователь окажется без руки, пользуясь вашим чудом техники. Перефразирую: в 21 веке уже недостаточно сделать косое и кривое приложение. Аппетиты и желания клиентов растут, поэтому постарайтесь, чтобы ваша первая версия выглядела хотя бы симпатично.
-
Влюбиться в продукт. Возможно, посреди разработки вам придется сменить концепцию. Возможно, вам придётся пожертвовать функциями, которые вам были так близки! А возможно, и весь продукт придётся прикрыть. Не влюбляйтесь в ваш продукт, иначе любые изменения будут даваться с трудом. Держите голову холодной, будьте гибкими, слушайте ваших пользователей. Помните, что подкидывать вам проблемы и задачи - это их основная работа.
