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

Что нужно делать, чтобы получилось MVP – тема не новая. Я же хочу порассуждать о том, КАК делать MVP, чтобы получилось одновременно результативно и недорого.
Приглашаю об этом почитать.

Привет! Меня зовут Илья Прахт, я преподаватель курсов для продуктовых менеджеров в OTUS, а также руководитель нескольких управленческих курсов. И очень частый запрос от студентов выглядит так: “Я понимаю, что нужно делать, как выглядит модель/концепция. Но я не понимаю, как это сделать? Как приземлить абстрактные схемы на реальную жизнь? Какие для этого есть инструменты?”

Поэтому я решил взять довольно популярную тему о создании MVP, и попробовать разобрать ее не с позиции ЧТО, а с точки зрения КАК. Давайте попробуем разобраться, как круто и дешево сделать хороший MVP.

Что такое MVP

MVP (Minimum Viable Product) – некоторая версия продукта, которая позволяет проверить отклик клиентов и определить потенциал продукта, при этом с минимальными на то затратами. Иными словами, это очень урезанная версия продукта, который вы придумали и хотите выводить на рынок, содержащая в себе несколько самых сочных киллер-фичей, ради которых пользователи будут готовы покупать ваш продукт.

Важно обсудить путаницу в части “Minimum Viable”. Часто слышал мнение, что MVP должно содержать минимальный набор самого базового функционала, полностью завершенная версия, но без “рюшечек”, что называется. И есть противоположное мнение, что MVP должно включать только то, за что пользователь заплатит, иначе нам не понять, будет ли продукт экономически эффективным.

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

MVP – это не POC. POC – слепленная из костылей и какого-то клея (как повезет) версия для проверки гипотезы. MVP – как мы уже обсудили, нечто завершенное, готовое к работе AS IS.

Преимущества и недостатки

Итак, с преимуществами MVP, вроде бы, разобрались: дешево, относительно быстро, позволяет проверить продукт, бизнес-модель, объемы и предпочтения целевой аудитории. Польза для бизнес понятная и конкретная.

Что с недостатками? Они тоже есть. Точнее сказать, он один. Зато какой! Основной недостаток – легко ошибиться с построением MVP, что станет базой для большого количества неверных решений.

В самом безобидном случае, можно сделать MVP с основными фичами, а полная версия продукта уже будет не очень-то и нужна. Такое часто бывает у сервисов с Freemium моделью. В качестве MVP выводится бесплатная версия, и вроде отклик есть, аудитория набирается, а платить за это никто уже не хочет. Ну а зачем, если основные фичи уже есть в MVP.

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

Виды MVP

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

#1 – Однофункциональный MVP

Данный вид MVP проверяет исключительно одну конкретную функцию продукта. Если хочется проверить несколько, можно запустить А/Б-тест с несколькими разными фичами в MVP, посмотреть, где будет больше интереса у пользователей.

Основной показатель здесь – есть интерес к фиче или нет. И метрики вовлеченности пользователей ваш главный союзник в этом деле.

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

#2 – “Волшебник страны Оз”

В такой версии создается полноценная версия продукта (для пользователя), но работает она исключительно на педальном приводе. Классика жанра – масштабируемые SaaS-ки и т п сервисы. Создаются версии и инстансы для каждого клиента, все это выглядит для пользователя серьезным и надежным. На деле – каждый клиент обрабатывается вручную админами.

Хороший вариант, если у вас есть готовый продукт, но нужно проверить, а есть ли у него своя аудитория. Рано накручивать дорогущую инфраструктуру, сперва можно и ручками пару десятков продаж сопроводить. Либо, если проверяете продукт, для которого точно есть ниша, но не ясен ее объем.

Какие метрики будут основными здесь? Метрики привлечения. Чем больше вам приходится проделывать руками этих самых неавтоматизированных действий, тем успешнее MVP. Значит можно вкладываться в инфраструктуру и автоматизировать.

#3 – Консьерж (или фасад)

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

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

Для таких вариантов важны метрики продаж. Конкретные сделки, конкретные суммы, конкретные заинтересованности клиентов. Цифры можно экстраполировать на всю аудиторию и прикинуть потенциальные возможности продукта.

#4 – Контент

В такой версии продукта вообще нет. Но есть хорошее видео/сайт/презентация о том, каким этот продукт может быть. Контент распространяется, и по реакциям и обратной связи от аудитории можно сделать выводы, а будет ли иметь успех сам продукт.

Плохо в этом способе только то, что зрители для видео – не есть покупатели. Они ничего не заплатили. Поэтому такой вариант хорошо подойдет для тестирования объемов потенциальной целевой аудитории. Но дальше лучше делать шаг 2 и запускать полноценное MVP.

#5 Краудфандинг

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

Так в чем отличие? Здесь потенциальные клиенты уже платят. А значит, продажи начинаются уже на этапе дешевого MVP, и можно оценить, какой финансовый успех может ожидать основной продукт. А если не пойдет, всегда можно вернуть деньги.

Алгоритм создания и инструменты

Шаг 1 – Аудитория и ее потребности

Первым делом, конечно же, надо разобраться, для кого мы делаем продукт. И его MVP, соответственно. Как выглядит типичный клиент, каков его портрет, какие JTBD у него могут быть, какие основные боли может решать наш продукт. Что поможет в этом? Конечно, классические custdev-интервью. Про них написано много, подробно расписывать здесь не буду.

Но мало понять свою аудиторию, надо еще и оценить ее объем. Как это можно сделать? Есть простой инструмент TAM-SAM-SOM. Нужно определить 3 основных показателя:

• TAM – Total Addressable Market – общий объем потенциального рынка, данные можно найти в статистических исследованиях отрасли, исследованиях крупных агрегаторов и т.п.

• SAM – Serviceable Available Market – доступный объем рынка, все, что уже покупают у вас и ваших клиентов, и как раз конкурентный анализ поможет здесь разобраться.

• SOM – Serviceable & Obtainable Market – реально достижимый объем рынка, в соответствии с вашими планами и возможностями (результаты продаж, конверсия и т. д.).

Поняв свою аудиторию, можно двигаться дальше и смотреть, чем эта аудитория уже пользуется.

Шаг 2 – Конкуренты и уникальность

На шаге 2 изучаем конкурентов. С точки зрения маркетинга (особенно digital) есть огромное количество разных продуктов, которые позволяют собрать информацию. Например: Brand24, SEMrush, Serpstat и т д. Для всего остального – контрольные закупки, анализ информации из публичных источников. Чем больше данных соберем, тем лучше.

Далее все это собираем в общую систему координат. Хорошо в этом помогает SWOT-анализ. Определяем свои сильные и слабые стороны, определяем возможности и вызовы внешней среды, смотрим пересечения. Именно пересечения – самое интересное.

И исходя из результатов SWOT-анализа уже можно выделить свое ключевое преимущество, главное УТП – почему должны купить именно у вас. Из этого УТП формируем несколько (лучше 3-4) киллер-фичи, которые можно будет поместить в свой MVP. Почему несколько – разберемся на следующем шаге.

Шаг 3 – Функционал MVP

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

Какие фичи включать? Ответить на этот вопрос нам помогает принцип Парето: 20% усилий дают 80% результата. Нужно выбрать тот минимум, который покроет максимум потребностей. Это лучше визуализировать. Можно нарисовать простой граф и построить взаимосвязи между потребностями пользователей и вашими фичами. Где больше линий сходится – там и главные киллер-фичи. Или построить матрицу потребности/функционал, проставить крестики на пересечениях, посчитать, на каких фичах больше всего крестиков.

Но это только первая половина шага. Вторая половина – проверить все на достижимость. Нужно привлечь специалистов из производства (архитекторы, разработчики), и добавить в матрицу 3 шкалу – сложность реализации. И далее отфильтровать бэклог еще раз по этому критерию. Какие-то киллер-фичи очень классные, но делать их очень дорого. Поэтому и выбирали мы их несколько на прошлом шаге, чтобы было пространство для маневра.

Шаг 4 – Тип MVP и реализация

По результатам шагов 1-3 выбираем наиболее подходящий тип MVP (из тех, что мы рассматривали выше), и формируем задачу на разработку. Главные критерии: скорость и стоимость.

Удешевлять разработку MVP могут, и притом значительно, LowCode и NoCode решения. Например, та же Tilda. Или аналоги, их сейчас много. Да, возможности таких решений могут быть ограничены, но зато и вероятность ошибки снижается, ведь мы делаем не с нуля. 

Шаг 5 – Запуск и тестирование

Когда MVP готово, запускаем его на рынок и начинаем тестирование. Для каждого типа MVP свои основные метрики (мы это обсуждали выше). Поэтому выбираем правильные метрики, налаживаем систему их сбора и контроля, и наблюдаем.

Распараллелить процесс проверки гипотез вашего MVP может помочь А/Б тестирование. Выбираем один основной сценарий, как эталонный, дополнительные – как тестовые. Делим трафик, смотрим различия.

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

Шаг 6 – Анализ результата

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

Вот и все. 6 шагов, и ваш MVP готов!

P.S.

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

Разработка MVP является частью go-to-market стратегии и ее дальнейшего запуска. 6 июля проведем открытый урок в OTUS по курсу Product Marketing Manager в IT, расскажем из чего состоит Go-to-market стратегия, с чего стоит начать. Как определить рынок для запуска продукта и что нужно, чтобы протестировать гипотезы. А также о том, как IT-компании выходят на рынки в современных реалиях: плюсы, минусы и подводные камни на реальных кейсах. Регистрируйтесь и приходите!

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