MVP (minimum viable product) — это минимально жизнеспособный продукт. Такой продукт обладает ограниченным функционалом, но его достаточно, чтобы потребители начали им пользоваться.
Для чего нужен MVP
MVP проверяет рабочие гипотезы и помогает получить отклик потребителей.
Нередко компании тратят годы работы, чтобы убедиться в том, что они выбрали неправильный путь. Тщательно проработанный продукт, на который потрачено много времени и средств, оказывается никому не нужным. Исследование CB Insights показало, что в 42% случаев причиной провала стартапа становится отсутствие рыночного спроса. MVP помогает убедиться в востребованности продукта или своевременно отказаться от убыточной идеи.
Ключевая идея MVP заключается в том, что вы создаёте реальный продукт, который можно предложить клиентам. А дальше вы наблюдаете за реакцией на него и дорабатываете решение с учётом предпочтений потребителей.
Основная задача MVP — сократить время и усилия на тестирование идеи до начала разработки полноценного продукта.
Минимально жизнеспособный продукт позволяет:
- проверить гипотезу на основе реальных данных и доказать жизнеспособность идеи;
- снизить возможность финансовых убытков при запуске неудачного продукта;
- уменьшить стоимость разработки за счёт отказа от ненужных функций;
- выявить неучтённые потребности клиентов;
- оптимизировать тестирование продукта и ускорить поиск ошибок;
- собрать начальную базу клиентов до полномасштабного запуска;
- выйти на рынок и привлечь инвесторов.
Разновидности MVP
«Выдуманный» продукт
В качестве MVP клиентам представляют ещё не существующий проект как реальный продукт.
«Волшебник страны Оз» (Wizard Of Oz MVP), или MVP Флинстоуна (Flintstoning MVP). Потребитель видит полноценный продукт со сложными автоматизированными процессами. На самом деле — это лишь изображение продукта и всё обслуживание осуществляется вручную. Если ручное тестирование показывает хорошие результаты, создают настоящий автоматизированный продукт. Продажа «призрачного софта» позволяет сэкономить средства и не тратиться на реализацию неопределённой идеи.
Пример Wizard Of Oz MVP — крупнейший обувной интернет-магазин Zappos. Его со-основатель Ник Свинмерн для проверки бизнес-идеи размещал в сети фотографии обуви, сделанные в местных магазинах. Если клиент заказывал товар, Свинмерн шёл и покупал нужную обувь, а затем отправлял заказчику. Для клиента процесс выглядел полностью автоматизированным. Так Свинмерн смог убедиться в востребованности идеи и решиться на открытие настоящего интернет-магазина.
Консьерж MVP. Принцип метода похож на Wizard Of Oz MVP с точки зрения фальсификации процесса. Разница в том, что в этом случае технологии отсутствуют. Все действия осуществляются вручную — усилиями команды. Пользователи понимают, что услугу им предоставляет живой человек, а не система.
Сервис проката дизайнерской одежды Rent the Runway протестировал свою идею, предлагая платья на прокат студенткам. Когда основательницы убедились, что их идея востребована, они запустили сайт сервиса по аренде платьев. В день запуска в сервисе зарегистрировалось 100 тысяч человек.
MVP-контент
Идею представляют через контент. Причём сам минимально жизнеспособный продукт может ещё не существовать.
Объясняющие видео. Для презентации проекта используют видео. Главное — объяснить пользователям, как будет работать готовый продукт, и получить обратную связь.
История компании Dropbox началась с короткого видео о функционале сервиса.
Обзор привлёк 75 тысяч подписчиков, которых заинтересовала идея облачного хранилища. А основатели смогли таким образом убедиться, что бизнес-идея жизнеспособна.
Целевая страница. Принцип в том, что для тестирования идеи создают страницу несуществующего продукта. А дальше анализируют реакцию пользователей.
Прежде, чем создать сервис отложенных постов для соцсетей Buffer, его основатель Джоэл Гаскойн рассказал в Twitter о функционале инструмента. Заинтересованные люди могли перейти по ссылке «Планы и цены» и оставить свой email.
Убедившись, что идея интересна людям, Джоэл представил потенциальным пользователям три варианта тарифов.
Только после подтверждения того факта, что люди готовы платить за реальный продукт, Джоэл приступил к разработке Buffer.
Социальные медиа. Суть MVP в том, чтобы получить обратную связь от пользователей в соцсетях.
В 2006 году Тим Феррис искал лучшее название для нынешнего бестселлера «4-часовая рабочая неделя: побег 9-5, живи где угодно и присоединяйся к новым богатым». Тим запустил несколько рекламных объявлений через Google Ads с рекламой книги под разным названиями. Затем он выбрал название, которое привлекло больше всего внимания. При этом поначалу автор отдавал предпочтение совсем иным наименованиям.
Сбор средств
В этом случае гипотезу проверяют, собирая средства на создание продукта. Если идея вызывает отклик аудитории и люди готовы платить за продукт, можно запускать проект.
Краудфандинг. Описание будущего продукта размещают на краудфандинговых платформах и открывают сбор на реализацию идеи. Если предложение интересно аудитории и удаётся собрать достаточную сумму денег, приступают к созданию продукта.
Дизайнер Netta Shalgi открыл сбор на kickstarter.com с целью собрать $35 000 на выпуск игрушки в форме деревянной лошади.
Сбор средств всё ещё продолжается, а проект уже собрал более $120 000.
Предпродажа продукта. Стратегия предпродажи состоит в том, что на сайте или в магазине описывают планируемый, но ещё несуществующий продукт. Пользователи могут оформить предзаказ — внести часть стоимости или полную сумму, чтобы зарезервировать товар сразу после его запуска в продажу.
Компания Sony использовала стратегию предпродажи для Playstation 4. До выпуска продукта компании удалось привлечь 1,5+ млн предзаказов.
Однофункциональный MVP
Одной из самых частых ошибок многих MVP становится перенасыщенность функциями. При тестировании идеи сложно понять, какая именно фича привлекла внимание аудитории. Цель однофункционального MVP — продемонстрировать самую главную функцию, ради которой потребители будут использовать продукт.
Мессенджер WhatsApp был создан на основе однофункционального MVP. В момент запуска в 2009 году мобильное приложение не имело функций для отправки сообщений. Единственное, что могли делать пользователи, — указывать свой текущий статус, который тут же видели другие пользователи из списка контактов.
Вскоре создатели мессенджера заметили, что пользователи используют статусы для обмена мгновенными сообщениями. С этого времени началась активная доработка приложения и привлечение инвесторов. К февралю 2013 года база WhatsApp увеличилась до 200 миллионов активных пользователей.
Как создать MVP
Составить подробную инструкцию по созданию MVP довольно сложно. Порядок действий варьируется от типа продукта, рыночной ситуации, возможностей команды. Но в общих чертах порядок создания minimum viable product можно представить в виде следующей последовательности этапов.
1. Определите основную задачу продукта
Чтобы продукт был востребован, он должен решать конкретную проблему потребителя. Поймите, зачем потенциальному клиенту нужен ваш продукт и почему он должен его приобрести. Подробно сформулированный ответ поможет понять, какие задачи должен решать MVP в первую очередь.
2. Установите «узкую» целевую аудиторию
Огромная ошибка — создавать MVP для широкой аудитории. Большой объём информации и слишком большое количество противоречивых отзывов от пользователей затрудняет поиск рабочей модели продукта. Поэтому важно сузить аудиторию.
На этой стадии опишите портрет идеального покупателя — человека, которого точно удовлетворит ваше решение. Чем точнее вы опишите своего клиента, тем лучше:
- возраст;
- образование;
- уровень дохода;
- интересы;
- привычки.
В процессе тестирования MVP предлагайте продукт аудитории, которая максимально соответствует образу идеального покупателя.
3. Исследуйте конкурентный рынок
Даже если вы придумали действительно новый продукт, возможно, на рынке уже существуют похожие решения. Изучите рынок и выясните, что именно предлагают конкуренты, какую долю рынка занимают, как привлекают клиентов. Сторонний опыт может пригодиться при корректировании собственного решения.
Как выполнить конкурентный анализ
4. Выполните SWOT-анализ
SWOT-анализ — это методика стратегического планирования. Её суть состоит в анализе факторов, влияющих на исследуемый объект.
В частности нужно определить для продукта:
- сильные стороны (Strengths);
- слабые стороны (Weaknesses);
- возможности (Opportunities);
- угрозы (Threats).
Сильные и слабые стороны обусловлены влиянием внутренних факторов. Возможности и угрозы относят к внешним факторам. Задача SWOT-анализа — сосредоточиться на преимуществах, выявить и минимизировать недостатки, предотвратить вероятные угрозы и полноценно использовать имеющиеся возможности для развития.
5. Постройте карту пути клиента
После того как вы проанализировали будущий продукт, самое время оценить его с позиции потребителя. Нужно понять порядок действий пользователей для приобретения вашего MVP.
Путь клиента должен быть коротким, простым и удобным. Подробное описание всех действий клиента поможет понять, какой информации не хватает или какие детали помогут в представлении продукта.
Если ваш MVP — это ИТ-продукт, хорошим ходом будет создать подробный прототип будущего сервиса. Это могут быть интерфейсы приложения в Figma или даже мокапы.
На этапе прототипирования у вас получится увидеть логику работы продукта. Подробный прототип хорошо подходит для донесения задумки команде разработчиков.
6. Выберите основные функции
Возможно, ваш конечный продукт будет решать сразу несколько задач. Но большое количество возможностей на этапе тестирования лишь запутает потребителей. Вы не сможете полноценно протестировать идею и потеряетесь в огромном объёме отзывов.
Для начала выделите основные функции, которые позволяют решить главную задачу продукта. Таких функций не должно быть много — одна, две, три — и именно они составят основу MVP. Все прочие возможности отсортируйте по степени важности — их вы добавите после запуска продукта, сбора обратной связи и анализа результатов тестирования.
7. Найдите оптимальный метод разработки и создайте MVP
Существует несколько методов разработки программного обеспечения, применимых к созданию MVP:
- Lean. Этот метод предполагает итеративную (повторяющуюся) разработку по схеме «создание-измерение-обучение». То есть в процессе создания разработчики постоянно ориентируются на отзывы. Внесли изменение в MVP, собрали отзывы пользователей, проанализировали, внесли коррективы и так до создания полноценной версии продукта. С lean можно ускорить запуск продукта, дорабатывая существующее решение сразу по мере сбора обратной связи.
- Scrum. Метод также основан на итеративном подходе. Но объём работ распределяют на спринты (циклы длительностью в 2-4 недели). MVP создают на этапе первого спринта. В последующих спринтах команда обновляет продукт на основе информации от потребителей. Scrum позволяет снизить нагрузку на команду. Метод подойдёт для постепенного развития продукта.
- Канбан. При данном подходе отсутствует цикличность разработки. Задачи решают по мере их возникновения. То есть получили обратную связь от потребителей — добавили задачу в общий список. Такой метод позволяет соблюсти баланс между возможностями команды и объёмом работы. Канбан целесообразно применять после запуска первой версии MVP для создания итоговой версии продукта на основе обратной связи.
- Экстремальное программирование (XP). В отличие от scrum, kanban или lean, XP применим только при разработке программного обеспечения. Принцип метода основан на упрощении кода и постоянном взаимодействии команды, тестировании и частых релизах. Циклы разработки с XP длятся не более одной недели. Это позволяет быстро запустить первую версию, а потом масштабировать ее.
8. Запустите альфа- и бета-тест MVP
Первую версию продукта запустите для узкой группы потребителей. Это альфа-тестирование. Обычно первыми пользователями становятся друзья, знакомые, родственники. Если недоработок нет, можно перейти к бета-тестированию. Предложите продукт реальным потребителям. Спустя одну-две недели соберите и проанализируйте обратную связь. Доработайте MVP и снова протестируйте.
Длительность и количество циклов тестирования-доработки всецело зависит от продукта и от того, как быстро удастся создать полноценное решение. Возможно, что спустя несколько циклов придётся вернуться на первый этап или продолжить итеративное улучшение MVP. В любом случае решение вы будете принимать не на основе предположений, а исходя из реальных фактов.
Как сократить бюджет при разработке MVP
Часто в начале разработки MVP встает вопрос, нужно ли все делать кодом или можно где-то сэкономить. Приведу несколько примеров, как можно существенно сократить бюджет MVP:
- Вместо мобильного приложения, сделать MVP в виде чат-бота. Разработка чат-бота обходится в 3-5 раз бюджетнее мобильного/веб-приложения. Для старта такой вариант подойдет идеально. Если проект найдет спрос, можно будет перенести функционал уже в мобильное приложение.
- Разработать продукт на no-code решениях. Многие MVP содержат небольшой набор функций, большинство из которых можно реализовать на конструкторах (сайтов, мобильных приложений, чат-ботов). После запуска и сбора первой обратной связи можно будет запускать уже разработку кодом.
Основная ошибка при создании MVP
При разработке MVP очень важно найти оптимальное соотношение затрат и качества. И зачастую акцент делают на минимализме, чтобы сэкономить средства и время. В итоге потребители критикуют сырую тестовую версию, а разработчики ошибочно отвергают саму идею.
MVP нередко путают с PoC (Proof of Concept) — доказательством правильности концепции. Хотя эти понятия похожи, но они не равносильны. PoC — это демонстрация практической осуществимости метода, технологии или идеи. Для этого создают небольшой образец или прототип, который может обладать лишь частичным функционалом итогового продукта. Так подтверждают, что выбранный способ создания или технологию реально применить на практике. MVP — это не доказательство, а вполне работоспособный продукт.
В то же время MVP нельзя назвать классическим прототипом в виде схематичных набросков. Несмотря на то, что это жизнеспособный продукт, который поддерживает минимальную функциональность, он не может быть «сырым». Более того, продукт должен как можно лучше выполнять основные функции, которые решают конкретную проблему потребителя. То есть, если в качестве MVP представлен прототип — это должен быть рабочий прототип. Потребители должны чётко понимать, как будет выглядеть готовый продукт.
Важно учитывать, что основной принцип MVP — быстро и дешёво создать продукт, который люди захотят купить. И здесь целесообразно использовать модель, которую предложил Юсси Пасанен — вместо последовательного создания слоёв, создать хотя бы минимальный кусочек на каждом слое.
Уделяйте внимание не только функционалу. Продукт должен быть надёжным, удобным в применении и привлекательным с точки зрения дизайна.
Допустим, что конечный продукт компании – это торт. Его основная задача — удовлетворить вкус потребителя. Для разработки MVP решено применить метод послойного создания продукта. Разработчик представляет клиентам первую версию — бисквитный корж (основа). Из обратной связи узнаёт, что корж вкусный, но не хватает крема (начинки). При этом часть потребителей уже разочаровались в продукте.
Разработчик добавляет крем – и снова не то. На этом этапе ещё часть аудитории отказывается от продукта. Теперь клиентам не хватает декора (дизайн). Разработчик украшает свой торт и получает положительные отзывы, а также пожелания сделать торт двухъярусным. Осталось немного доработать MVP, чтобы получить отличный готовый продукт. Увы, но в процессе тестирования компания уже потеряла долю потенциальных клиентов.
А теперь представьте другой подход — создание MVP методом среза. Разработчик выпекает небольшое пирожное: в нём есть и основа, и начинка, и дизайн. Представление начальной версии проходит успешно, и разработчик создаёт торт. Из обратной связи узнаёт, что потребителям всё нравится, но хотелось бы получить торт большего размера. Теперь разработчик делает большой торт и всё — продукт готов. При этом удалось сохранить всю аудиторию, которой понравилась первая версия MVP.
Получается, что если вы хотите узнать, будет ли кто-то покупать у вас торт, — продавайте именно торт, а не основу для него, или начинку, или дизайн по отдельности. Изготовление тортов затратно, поэтому для начала можно сделать их мини-версию — пирожные. Характеристики остаются те же, но времени и средств на производство уходит меньше. Точно также и с любым другим минимально жизнеспособным продуктом — предлагайте потребителям то, что позволит составить объективное мнение об итоговой версии.
Какой бы гениальной ни была бизнес-идея, она не является итоговым результатом. Трудно судить об успехе, опираясь на предположения. Минимально жизнеспособный продукт позволяет проверить, заинтересует ли идея потенциальных потребителей. MVP поможет предотвратить финансирование провальных проектов, выбрать наиболее приоритетное направление развития и заранее собрать базу потенциальных клиентов.
Еще несколько типичных ошибок при создании MVP:
- Создали продукт, но не настроили минимальную аналитику для анализа продуктовых метрик (например не проставили UTM-метки).
- Весь бюджет потратили на разработку, на продвижение практически ничего не осталось. Для запуска MVP, как правило, можно использовать соотношение 60% на разработку, минимум 40% на первичное продвижение.
- Не настроили минимальный мониторинг ошибок. MVP сам по себе нестабильный проект, тем не менее стоит задуматься о настройке минимальных проверок его работоспособности.
- Уделили много внимания второстепенным фичам. Например, сделали авторизацию через почту и несколько соцсетей, хотя на первом этапе достаточно одного варианта – через почту.