Mvp На Примере Швейцарского Армейского Ножа

MVP (минимально жизнеспособный продукт) — это первая версия вашего продукта, с помощью которой вы, как создатель продукта:

  • подтвердить гипотезу о необходимости конкретного решения, исходя из поведения пользователей;
  • собирать отзывы от ваших будущих пользователей;
  • пытаетесь продать (или уже продаете) свое решение пользователям.

Давайте пройдемся по этим пунктам.

Возьмем в качестве примера не сложный IT-продукт, а самый обычный, повседневный предмет: швейцарский нож.



MVP на примере швейцарского армейского ножа

Однажды люди выдвинули гипотезу, которая может создать проблему: что, если я окажусь в диком лесу и мне нужно будет срезать гриб и отпраздновать это, выпив бутылку вина? Носить с собой штопор и нож просто неудобно (да и кто в здравом уме возьмет с собой в лес штопор?).

Что, если мы объединим эти инструменты в один? Эти люди (назовем их основателями) попытались совместить в одном инструменте штопор и нож, создали первый прототип (он оказался кривым и неудобным, но полезным) и попытались продать его будущим клиентам.

Давайте представим, что им это удалось.

Что им делать в этом случае?

  1. продолжать продавать текущее решение, одновременно добавляя новые инструменты (функции), исходя из отзывов и пожеланий клиентов;
  2. улучшить текущее решение, сделать его удобнее (работать над UX);
  3. собирать отзывы пользователей и корректировать продукт.
Но с первого раза это удается только создателям швейцарских ножей.

В реальной жизни 42% стартапов умирают из-за отсутствия спроса.

Каждый раз фаундеры могут выйти на рынок с новым набором инструментов (попробовать разные гипотезы) или, если что-то пойдет не так, изменить бизнес-модель (сделать Pivot).

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

Как мне это сделать?

  1. Производить и стараться продавать очень небольшие партии;
  2. Сэкономить на качестве (но не настолько, чтобы получилось совсем плохо).

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

Как выбирать гипотезы и функции

Гипотеза – это предположение о проблеме клиента.

В одной версии продукта стоит тестировать только одну гипотезу за раз.

В этом случае гипотеза должна быть смелой.

Хотят ли люди есть грибы? Определенно да! Вы готовы пить вино? Ах, да! Но может ли кому-то вдруг понадобиться и нож, и штопор одновременно? Это уже гипотеза, которую стоит проверить! Теперь перейдем к тому, что можно включить в первую версию продукта.

Ответ прост: нужно включить те функции, которые: 1) работать над проверкой ключевой гипотезы.

Не присоединить сам нож к швейцарскому армейскому ножу — кощунство; 2) обеспечить наибольшую ценность для пользователя.

Да, в швейцарский нож также можно впихнуть шагомер и Bluetooth-динамик, но главная ценность в нашем примере — это нож и штопор.

Все функции, не соответствующие этим требованиям, можно смело оставить на будущее.



Проверка без продукта

Можно ли проверить гипотезу о продукте, вообще не создавая никакого решения? В IT-сфере это возможно, если вы немного хитрее и умнее наших основателей из примера.

Например, они могли бы создать целевую страницу «Чудо-швейцарские ножи», привлечь на нее трафик из социальных сетей и посмотреть, делают ли люди предзаказ на этот продукт. Если да, то его можно изготовить.

В истории есть много примеров таких «предзапусков», но вот мой любимый: Около 2 лет создателям диспетчера задач Сунсама запустили на главной странице анкету, в которой опросили рабочие привычки будущих пользователей (сколько человек в команде, каким диспетчером задач они пользуются сейчас, где хранят задачи и т. д.).

Когда была выпущена первая версия продукта, доступ получили только те, кто подходил в качестве целевой аудитории для этого продукта.

Таким образом, создатели Sunsama убили трёх зайцев: исследовали аудиторию, получили первых подписчиков и подогрели интересы остальных, не получивших доступа.

Кстати, я даже пытался найти правильные ответы на анкету, чтобы получить доступ.

И я сделал это! А вот то, что было внутри, мне уже было не интересно (я не зря отбирала ответы).



Продавать или нет?

Автор книги «Бизнес с нуля.

Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели» Рик Рис говорит, что MVP должен продавать с первого дня.

И я с ним абсолютно согласен.

Мы создаем продукты не только для решения проблем и улучшения мира, но и для зарабатывания денег.

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

Если нет, продукт должен начать приносить вам деньги уже сегодня (через подписку на сервис, рекламу или плату за интеграцию).



Ошибки при разработке MVP

MVP — непаханное поле для больших ошибок и потерянных бюджетов! Вот ошибки, которые можно допустить «во время игры»:
  • Включите слишком много дополнительных функций.

    Представьте себе, что вы Роден (со швейцарским ножом в руке) и без сожаления выбрасываете все, что не добавляет ценности вашему продукту и не поддерживает его жизнеспособность;

  • Не слушайте отзывы пользователей.

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

  • Слишком стараюсь.

    Есть поговорка: если ты показываешь первую версию продукта и тебе не стыдно, значит, ты уже переборщил.

    Поверьте, у вас будут бесконечные возможности улучшить свой продукт, и не обязательно делать это сразу идеально!

  • Недостаточно попробовать.

    Можно придумать отличную идею совместить нож со штопором, но если вы сделаете это в стиле «и оооочень подойдёт!», то вы рискуете, что ваш пользователь при использовании вашего чуда окажется без руки.

    технологии.

    Перефразирую: в 21 веке уже недостаточно сделать наклонное и кривое приложение.

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

  • Влюбитесь в продукт. Возможно, вам придется изменить свою концепцию на полпути разработки.

    Возможно, вам придется пожертвовать функциями, которые вам дороги! И возможно, придется покрыть весь продукт. Не влюбляйтесь в свой продукт, иначе любые изменения будут затруднены.

    Сохраняйте хладнокровие, будьте гибкими, слушайте своих пользователей.

    Помните, что давать вам проблемы и задания – это их основная работа.

Теги: #Разработка стартапа #Управление разработкой #стартап #дизайн #Управление продуктом #mvp #функции #монетизация
Вместе с данным постом часто просматривают: