Все о создании MVP: от идеи до первой версии продукта

Что такое Minimum Viable Product? Как его быстро реализовать? На чём можно и нельзя экономить при разработке? Ответы — в статье.

В NLABTEAM мы более 20 лет создаём программное обеспечение для среднего и крупного бизнеса. Помогаем телекому, ретейлу, промышленности, медицине, финтеху и другим ведущим отраслям трансформировать процессы с помощью технологий. На основе своего опыта расскажем всё, что нужно знать об MVP перед началом проекта.

MVP, он же minimum viable product

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

Создание MVP – один из важнейших компонентов «бережливого стартапа». Разработка MVP экономит время и средства за счет скорейшего перехода к стадии получения обратной связи от рынка и оперативной отбраковке или модификации неработающих гипотез. Собранная информация дает базу для дальнейшего развития и создания нужного продукта для потребителей, или же позволяет своевременно отказаться от реализации продукта.

Такой продукт уже может не только существовать в конкурентной среде, но и обрести первых поклонников, и даже приносить прибыль. Поэтому его и называют минимально жизнеспособным продуктом.

MVP и как его построить

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

Иногда MVP даже не требует реализовывать в коде проверяемую идею. Например, если сервис предполагает автоматическое выполнение неких действий, на начальном этапе их могут выполнять вручную сами разработчики. Главное, чтобы пользователь оставался доволен.

Не стоит путать MVP и PoC, Proof of Concept, доказательство, что некая концепция в принципе может быть реализована. В первом случае тестируется гипотеза в форме продукта, её соответствие запросам аудитории, готовность клиента платить за такое решение своей проблемы. Во втором – проверяются технические моменты для воплощения отдельных частей идеи. При написании MVP может проходить через стадию PoC или использовать её для оценки объема работ, учета технических сложностей или выбора подходящих технологий на раннем этапе, но не ограничивается ей.

Если тестирование показывает нежизнеспособность основных предположений, можно на ранней стадии отказаться от мертворожденной идеи. Если же MVP подтверждает выбор гипотезы, можно продолжать развитие.

Зачем нужен MVP продукта

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

Собирать постоянную команду разработчиков на этапе MVP — рискованно. Можно существенно выиграть в скорости и денежных затратах, если первичные проверки гипотез заказывать через аутсорсинг.

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

Разработчикам MVP дает четкие ориентиры, что именно требуется реализовать и в какой последовательности. Команда не распыляется на побочные функции, а сосредотачивается на ценности проверяемой идеи и донесении неё до потребителя.

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

Таким образом, создание MVP продукта позволяет достичь следующих целей:

• существенно сэкономить на проверке гипотез
• получить обратную связь от целевой аудитории еще до выхода на широкий рынок
• открыть продукт для ранних клиентов опередив конкурентов
• сбор данных для анализа рынка и уточнения стратегии развития
• получение инвестиций или выход на краундфандинг
• уменьшение затрат времени разработчиков до выпуска «готового» продукта
• подготовка базы для других проектов

Типичные варианты MVP

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

Волшебник страны Оз: иллюзия продукта или его полноценной работы

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

Так, чтобы протестировать идею о продаже обуви через интернет, не требуется арендовать склад и закупать сапоги, писать ПО для управления логистикой и складскими запасами, не нужно мобильное приложение. Достаточно сайта и фотографий обуви из ближайшего магазина, а отправить пару можно и после заказа. Именно так начиналась империя Zappos.

Консьерж: замена человека программой

Этот способ похож на предыдущий, но потребитель услуги изначально знает, что на начальном этапе его задачу будет решать реальный человек. Подход фокусируется на прямом контакте с пользователем, чтобы грамотно ему помочь и в то же время собрать данные для дальнейшего развития. Таким путем шла платформа Wealthfront, которая сейчас использует автоматизированные системы, чтобы помочь клиентам с финансовым планированием.

Разрозненный MVP: не изобретать, а собрать из готовых продуктов

Можно не тратить время на разработку продукта, а использовать уже существующие компоненты для промежуточных этапов получения результата. В дальнейшем выполняемые ими действия можно автоматизировать и включить в единую программу. Этот способ успешно применил Groupon: на первых порах автоматической рассылки предложений не было, как и социальных функций, а PDF для клиентов генерировал с AppleScript и рассылал через Apple Mail сам основатель.

Один параметр: 1 продукт – 1 проверка

Иногда достаточно реализовать всего 1 функцию. Так, Spotify на заре существования обеспечивал только лишь потоковое воспроизведение, без плейлистов и всего остального. Однако даже в таком виде он позволил проверить идею. Сегодня сервис доступен практически во всех странах мира.

MVP без MVP

Также можно обойтись и вовсе без разработки продукта, достаточно донести идею до пользователей через контент и собрать отклики. Например, Dropbox начинался с поясняющего видеоролика, который принес десятки тысяч подписчиков. Или же можно анонсировать продукт и собрать на него заявки при помощи лэндинга или социальных сетей. В таком случае одновременно собирается и пользовательская база, с которой в дальнейшем намного проще работать, чем с холодными клиентами.

Тимоти Феррис для своей книги о сокращении рабочей недели до 4 часов запустил онлайн-рекламу с различными вариантами названия. Затем он проанализировал CTR объявлений и дальновидно выбрал то, которое показало лучший результат. Книга стала бестселлером.

Также возрастает популярность краудфандинга – сбора средств на создание продукта. В этом случае упор делается на формирование группы заинтересованных пользователей, которые за различные вознаграждения (атрибутика, ранний доступ, встреча с создателями/разработчиками и т.п.) или ради причастности к идее готовы за нее платить. Можно сделать MVP во время кампании, а можно даже после окончания сбора.

Как разработать MVP

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

Проще и быстрее

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

Собираем пользователей

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

Предварительные продажи

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

Обратная связь

обратную связь нужно собирать всегда, начиная с первой встречи с продуктом, через онлайн-опросники, интервью и сбор предложений. Полезно также непосредственно посмотреть, как клиенты пользуются продуктом – это не только покажет огрехи интерфейса, но и может принести ценные идеи для дальнейшего развития. На MVP сбор данных не заканчивается, его нужно продолжать и в последующих версиях, и в полноценных релизах, подключая A/B тесты, отчеты об ошибках, возможность оставить отзыв и связаться с поддержкой

Отзывы и запросы

полученные сведения должны использоваться. Отзывы и запросы пользователей помогут сформировать востребованный продукт, только если переводить их в задачи для разработчиков;

Оптимальная цена

лэндинги или формы предварительного заказа помимо информирования и сбора контактов позволяют проанализировать покупательную способность и установить оптимальную цену, а с помощью рекламы в Google/Яндекс или в соцсетях можно проверить, как воспринимают MVP узкие сегменты аудитории.

Вот как создаются MVP на практике

Этап 1: цель

Сначала следует сформулировать идею, желательно кратко, какую проблему решает и для чего нужен продукт. Например, для Spotify это было бы обеспечение потокового воспроизведения музыки.

Этап 2: поиск аудитории и выбор визионеров

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

Этап 2.5: анализ конкурентов

Промежуточный этап, который может использоваться для оптимизации разработки. Другие компании уже могли проверить ряд гипотез, и внимательное изучение их опыта может как подсказать их силу и слабость, так и дать дополнительные гипотезы для проверки или принять решение об отказе от заведомо непопулярных функций.
Стоит проверить следующие сведения:

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

Этап 3: SWOT-анализ

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

Этап 4: карта путей

Разработка MVP должна учитывать типичный путь взаимодействия пользователя с продуктом. Чем он проще и понятнее, тем лучше будет пользовательский опыт. Хорошая карта путей поможет разработать интерфейс приложений или сервиса, где каждый шаг будет соответствовать текущему желанию пользователя и последовательно решать его проблему (например, выбрать пиццу – указать адрес и контакты – оплатить – получить). Под последовательность шагов формируется список задач.

Этап 5: перечень функций и их приоритет

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

Этап 6: что войдет в MVP

Самые востребованные функции вдоль пути пользователя – это основа, на которой и будет строиться минимальный продукт. К ним может потребоваться добавить и некоторые из менее приоритетных пунктов, если без них использование и проверка гипотезы невозможны. Всё остальное можно будет реализовывать уже после тестов MVP и получения обратной связи.

Этап 7: метод управления/разработки

Здесь начинается непосредственная работа над кодом. Популярны следующие подходы и практики:

• «бережливый» (lean);
• SCRUM;
• экстремальное программирование;
• канбан.

Все они опираются на обратную связь, которая непосредственно влияет на дальнейшие работы по продукту.

Этап 8: тесты

Внутренние альфа-тесты и закрытые/открытые бета-тесты фактическими пользователями дают данные об успешности полученного продукта. После набора достаточного объема сведений проводится анализ отзывов и запускается следующий цикл разработки-теста-обучения. При необходимости изменить направление выполняется возврат к подготовительному этапу.

Признаки того, что MVP удался

Жизнеспособный продукт

Прибыль

дает отдачу в виде прибыли или роста числа пользователей (продукт ценен для клиентов);

Ключевые функции

содержит ключевые функции для проверки гипотезы и удержания пользователей;

Перспективы

показывает перспективы развития;

Позволяет изменить курс

дает возможность скорректировать roadmap, например, если побочная функция оказалась многократно популярнее первоначально планируемой идеи;

Цикличный процесс

подразумевает цикличный процесс разработки-сбора данных-обучения на них для адаптации под рынок;

Клиентоориентированность

не приводит к появлению бесполезного продукта, так как выявляет потребности клиента.

Ограничения и подводные камни MVP

Как и любой метод, MVP имеет свои тонкие моменты:

• MVP – не идеал и не должен им быть. Если идея реализована хорошо, она выживает и без идеального интерфейса. Однако крупным компаниям также нужно учитывать, что недостаточно ценный MVP может оставить пятно на их репутации;
• простой – не значит некачественный или небрежный. Онлайн-сервис с адресом на поддомене конструктора доверия не внушает;
• отсутствие обратной связи и учета метрик (например, загрузок или покупок) лишает MVP смысла. Разработка ради разработки не является MVP;
• анонсы должны выполняться. Пообещать функцию и не сделать её значит значительно обесценить MVP.

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

Заключение

Собирать постоянную команду разработчиков на этапе MVP – рискованно. Можно существенно выиграть в скорости и денежных затратах, если первичные проверки гипотез заказывать через аутсорсинг. Наша компания уже сотрудничала со стартапами на этом этапе развития, и мы с удовольствием поможем вам как можно быстрее создать первую версию продукта.