Как получить mvp

MVP: как создать минимально жизнеспособный продукт

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

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

Что такое MVP и для чего он бизнесу

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

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

MVP и PoC: в чем разница. MVP часто путают с PoC — Proof of Concept. PoC — проект, который создают для проверки важных гипотез перед началом разработки. Эти понятия взаимосвязаны, но не равнозначны.

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

MVP — больше, чем исследовательский проект, это — работоспособный продукт.

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

Как запуск MVP ускорил развитие WhatsApp

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

Что сделали. Разработчики быстро заметили, что пользователи стали использовать статусы для общения, и выпустили новую версию WhatsApp, в которой было больше функций, связанных с отправкой сообщений. В результате небольшая пользовательская база выросла всего за несколько дней до 250 000 человек.

Результат. К 2015 году сервис стал самым популярным приложением для обмена сообщениями в мире. Сейчас WhatsApp используют более двух миллиардов человек по всему миру, а начался проект с MVP.

Виды MVP

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

• MVP Флинтстоуна;
• консьерж MVP;
• разрозненный MVP;
• продукт с одним параметром.

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

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

Такой MVP сэкономит средства компании на старте и позволит оценить потребности рынка.

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

Предприниматель планирует запуск онлайн-сервиса для бронирования отелей. Вначале он знакомится с целевой аудиторией, самостоятельно бронирует номера, уточняет детали и отвечает на запросы клиентов. Только после этого этапа предприниматель приступает к разработке цифрового продукта.

Такой MVP позволяет понять потребности клиента и задачи продукта для целевой аудитории.

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

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

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

Продукт с одним параметром. Это приложение или программа, которые выполняют одну-две функции, необходимые для проверки востребованности идеи.

Популярный пример такого MVP — стриминговый сервис Spotify. Разработчики сконцентрировались на функции потоковой передачи музыки, протестировали целевую группу, проанализировали обратную связь и только после этого запустили полноценный сервис.

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

Создание MVP: пошаговое руководство

Процесс запуска минимально жизнеспособного продукта включает восемь этапов.

Разберемся, какая задача на каждом этапе и что нужно делать.

Этап 1. Определить проблему пользователя

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

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

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

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

Этап 2. Определить ядро целевой аудитории

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

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

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

Этап 3. Изучить конкурентов

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

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

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

Увеличили продажи для госучреждений на 40% в месяц

Этап 4. Провести SWOT-анализ

Задача. Определить сильные и слабые стороны продукта, потенциальные возможности и угрозы.

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

На основе SWOT-анализа банк разрабатывает стратегию запуска нового продукта, фокусируется на клиентах с высоким доходом и создает собственные программы лояльности

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

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

Этап 5. Определить путь пользователя

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

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

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

Этап 6. Определить основные функции будущего продукта

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

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

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

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

Этап 7. Выбрать методологию разработки

Задача. Выбрать один из итеративных способов разработки. Lean, Scrum, Kanban, экстремальное программирование — все эти методологии позволяют дорабатывать продукт на протяжении всего процесса разработки.

Строительная компания оптимизирует процесс закупок. Сотрудники привыкли обрабатывать классические типовые запросы, но они не могут справиться с нетипичными заказами. Методология Kanban позволила разделить все закупки на разные типы и классы. Разработчики добавили дополнительную функцию для нетипичных запросов.

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

Этап 8. Протестировать продукт

Задача. Провести альфа- и бета-тестирование для совершенствования продукта. Устранить все технические проблемы и оценить реакцию рынка.

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

Как действовать. После завершения разработки пользуйтесь продуктом внутри команды на протяжении 3—4 дней. Потом дайте доступ к продукту реальным пользователям на 2 недели. Проанализируйте все полученные данные, доработайте продукт и снова протестируйте

Запуск продукта

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

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

Оценка MVP и доработка продукта

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

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

Распространенные ошибки при создании MVP

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

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

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

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

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

Отсутствие процессов развертывания и обновления продукта. Процесс разработки и доработки продукта идет непрерывно. Каждая новая версия выходит с постоянной периодичностью. Сложно организовать этот процесс грамотно без профессионального DevOps-инженера, который может настроить CI/CD — непрерывную интеграцию и развертывание. Такой специалист следит за ветками кода и тестированием основных фич, отслеживает цепочки сбора всех модулей и содержит все стенды. Именно он отвечает за функциональное качество продукта и управляет процессом разработки. Работа без DevOps-инженера затягивает реализацию проекта.

MVP – как сделать его круто

Создание 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. Отвечаю на ваши вопросы и разбираю ваши кейсы.

Сертификация MVP — MICROSOFT MOST VALUABLE PROFESSIONAL

Статус MVP присваивается самым выдающимся, независимым, ярким экспертам, которые готовы безвозмездно делиться своими знаниями о продуктах Microsoft с другими. Участники этого тщательно отобранного круга специалистов проживают более чем в 100 странах мира и разговаривают на 40 разных языках. Однако их объединяет стремление делиться своими знаниями с другими и помогать сообществу! Кроме того, MVP-эксперты предлагают свой независимый взгляд на продукты корпорации Microsoft, который отражает мнение тысяч людей из технических сообществ по всему миру.

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

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

Как MVP помогают сообществу?

• MVP активно участвуют в онлайн и оффлан мероприятиях: пишут в блогах, выступают на конференциях, создают веб-касты, а так же участвуют в других мероприятиях технических сообществ.
• MVP делятся своими глубокими знаниями о продуктах Microsoft в более чем 90 разных экспертизах.
• MVP помогают людям более эффективно использовать технологии Microsoft.
• MVP помогают пользователям примерно в 100 странах мира и обеспечивают поддержку на 40 разных языках.

MVP делятся своими глубокими знаниями о продуктах Microsoft в более 90 разных экспертизах.

Как стать MVP?

В программе участвуют люди, проживающие в 100 странах мира и разговаривающие на 40 разных языках.

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

Как выбирают MVP?

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

Что такое MVP и как его создать, виды

MVP уходит корнями в методологию Customer Development, известную как кастдев. Ее используют, когда надо быть уверенным в том, что обновление существующего продукта или новое решение будет нужно клиентам.

Что такое MVP и зачем он нужен

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

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

Зачем нужен MVP:

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

Читайте также:
Что такое стартап: простыми словами — полное руководство

Кому нужен MVP

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

Виды MVP

Выделим 7 видов.

Выдуманный продукт

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

Так поступил создатель интернет-магазина Zappos — Ник Свинмерн. Сначала и магазина-то не было — просто виртуальная витрина с фото обуви, который стартапер делал в городских магазинах. Но и на такой товар находился купец: когда люди хотели сделать заказ, Ник шел в те самые магазины, покупал обувь и отправлял заказчику. Когда он понял, что схема работает — открыл настоящий интернет-магазин.

Консьерж MVP

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

Посадочная страница

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

Однофункциональный продукт

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

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

Поэтапный MVP

Этот продукт собран из нескольких решений, как конструктор. Например, сайт работает на админке WordPress, отзывы собирает бот, команда общается в Trello и т. д.

Прототип

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

Предзаказ

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

Читайте также:
Маркетинговые исследования: что это, зачем нужны и как проводить

Примеры MVP

Разберем известные компании и их детища, которые начинали с минимально жизнеспособных продуктов.

1. Авиакомпания знаменитого Ричарда Бренсона Virgin Air начиналась всего с одного транспортного судна и одного маршрута. Когда все гипотезы подтвердились — компания расширилась.
2. Приложение Uber было совсем не тем, что сейчас. Изначально оно выполняло одну функцию — соединить пассажиров и водителей. Когда люди оценили, продукт начал развиваться.
3. Поисковая система Yahoo начиналась с перечня ссылок на трастовые сайты. Это и был MVP, который пошел в народ и превратился в полноценный продукт — поисковик.
4. Сервис Spotify создавался для легального прослушивания музыки, а потом попался на глаза нужным людям, которые решили использовать его для защиты от пиратства.
5. Наш маркетплейс Ozon когда-то был интернет-магазином только книг, и ничего более. А сейчас — да вы сами знаете!

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

Этапы создания MVP

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

1. Определите цель и задачи продукта. Сформулируйте для себя, что несет в мир ваш продукт, какие проблемы потенциальных клиентов решает, каких целей они могут с его помощью достичь.
2. Проанализируйте целевую аудиторию. Кто они — люди, которым может понадобиться ваш продукт? На какие сегменты они делятся, какие проблемы хотят решить и как вы можете с этим помочь? Составьте как можно более точные портреты ЦА или ее сегментов и опирайтесь на них при запуске.
3. Изучите рынок и основных конкурентов. Причем как крупных игроков, так и стартапы. Посмотрите основные цели и функции их продуктов, аудиторию, способы продвижения, расценки и многое другое. Особое внимание обратите на похожие MVP — почерпнете немало идей.

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

ПроведитеSWOT-анализ. Выявите слабые и сильные стороны вашего продукта, оцените риски и возможности роста.

Постройте CJM —карту пути клиента. Вон он сидит, лапочка, и знать не знает, что ему нужен ваш продукт. Как он может о нем узнать — из поисковой системы, контекстной рекламы, из статьи в любимом блоге? Что он потом должен сделать, чтобы пройти по воронке продаж? И что будет, когда продажа совершится? Пропишите все возможные варианты и выберите несколько наиболее вероятных, чтобы потом провести его по ним. Для выполнения этого пункта нужно хорошо проработать п.3.

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

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

Начните тестировать. Тут-то и начинается самое интересное: вы поймете целесообразность продукта вообще и его функций в частности. Сначала советуем протестировать продукт среди близкого круга: друзей, знакомых, коллег. Соберите обратную связь, при необходимости внесите изменения и выпускайте продукт «в люди». Там уже будет более серьезная обратная связь: достойно воспринимайте критику и используйте ее в своих интересах.

Обращайте внимание не только на отзывы, но и на реальные KPI: например, охваты, количество продаж, NPS — индекс потребительской лояльности и т. д. После этого протестируйте финально.

Если все хорошо — спрос есть, замечания учтены, гипотезы подтверждены — можете запускать финальную версию. А можете работать на MVP годами — если он работает и приносит прибыль, почему нет! Захотите масштабироваться — запустите полную версию.

Создание сайтов

• Разработка эффективных сайтов для продаж в интернете.
• Создаем сайты с нуля любой сложности, от сайтов визиток до интернет-магазинов и крупных порталов.

Основные ошибки при создании MVP

1. Впихивать невпихуемое, то есть начинять MVP множеством функций. Да, понимаю, хочется, но в этом и суть минимально жизнеспособного продукта — начать с малого, а потом допилить. Если нет терпения — делайте тогда сразу набело.
2. Размывать целевую аудиторию. «Наш продукт — для каждого» — это не УТП, а большая ошибка. На этапе MVP ЦА надо определить как можно четче — именно они будут тестировать и по сути улучшать ваш продукт просто так, за бесплатно.
3. Размывать цели и задачи продукта. То же самое — это потом вы успеете удивить ЦА и той, и другой фишками, но пока — нет, ограничьтесь одной или несколькими.
4. Слишком долго ждать с запуском, бесконечно доводить продукт до идеала. MVP на то и минимально жизнеспособный, а не максимально. Если на его запуск тратится максимум времени, денег и сил — это уже полноценный продукт, а не версия на минималках.
5. И наоборот — выпускать плохо проработанную версию под лозунгом «И та-а-ак сойдет, это же не полноценный продукт». Большая ошибка так думать: уважайте пользователей, предоставляйте им если не полновесную, то точно не сырую версию. Помните о соотношении цены и качества.

Коротко о главном

1. MVP — это продукт на минималках. Чаще всего используется в стартапах.
2. Он нужен, чтобы подстраховаться перед выпуском полноценной версии, проверить гипотезы, оценить спрос, сэкономить.
3. Есть несколько видов минимально жизнеспособного продукта, которые можно подогнать под многие ниши.
4. В IT и digital это лендинги, прототипы, однофункциональные приложения.
5. Есть 8 основных этапов создания — от определения цели до пользовательского тестирования.
6. Многие предприниматели допускают эти ошибки: стремятся начинить MVP множеством функций, довести до идеала или наоборот, сделать спустя рукава.

Присоединяйтесь к нашему Telegram-каналу!

• Теперь Вы можете читать последние новости из мира интернет-маркетинга в мессенджере Telegram на своём мобильном телефоне.
• Для этого вам необходимо подписаться на наш канал.