Фокус-группы, исследования целевой аудитории, оценка конкурентов — всё это не дает гарантии того, что ваш продукт действительно нужен пользователям. Это прогнозы, которые могут не сбыться. Чтобы узнать наверняка, нужно создать и выпустить на рынок минимально жизнеспособный продукт. Привет, я Артём Трубин, CPO компании ActiveCloud. В этой статье расскажу, в чем разница между PoC, MVP и MLP и как, при запуске нового продукта, снизить риски с их помощью.
Что такое PoC, MVP и MLP
Для начала разберемся с понятиями.
Proof of Concept (PoC) — это методика, которую используют для проверки реализуемости идеи или концепции до выпуска MVP.
Minimum Viable Product (MVP) — это версия реализации идеи с минимально необходимым набором функций, которая позволяет собрать решение проблемы, дать ценность клиенту, получить обратную связь от рынка и протестировать бизнес-процессы с минимальными затратами.
Minimum Lovable Product (MLP) — это версия продукта, созданная не только для решения проблем клиентов и формирования базовой ценности для них, но и для обеспечения приятного и запоминающегося клиентского опыта. Основное отличие MLP от MVP заключается в том, что MLP фокусируется на создании эмоциональной связи с клиентом, что приводит к повышению удержания и лояльности клиентов.
|
|
Пример из ИТ-сферы Разработка мобильного приложения для управления расходами |
Пример не из ИТ-сферы Открытие спортивного клуба |
|
PoC |
Черно-белый прототип экранов приложения, видео презентация с демонстрацией работы приложения и его функций. Еще не написана ни одна строчка кода. |
Текстовое описание методологии тренировок, дизайн-концепция и план-схема зала, видеоролик-презентация. Сам клуб еще не открыт, помещение не арендовано. |
|
MVP |
Приложение с базовыми функциями учета расходов, включая добавление, редактирование и удаление транзакций, а также простые графики для визуализации месячных расходов |
Открытый клуб в локации с ремонтом, инвентарем, тренерами, сайтом и группами в соц. сетях. |
|
MLP |
Все функции из MVP + функции автоматического распознавания текста с чеков, интеграция с банковскими счетами для автоматического обновления транзакций, персонализированные советы по снижению расходов и пр. |
Все функции из MVP + персональное мобильное приложение, видеонаблюдение со стримингом детских секций, программа лояльности и пр. |
Зачем нужны PoC, MVP и MLP
В современном мире разработки продуктов, где скорость и адаптивность ценятся выше всего, снижение рисков становится ключевым фактором успеха. Менеджеры продуктов используют различные методы для этого, в том числе базовые исследования (опросы, глубинные интервью и пр.), которые помогают им понять потребности и боли пользователей.
Однако важно осознавать ограничения этих методов: люди, участвующие в исследованиях, могут не всегда быть искренними или точно описывать свое поведение. Существует риск получения искаженных данных, что может привести к неверным решениям о продукте.
Помимо этого, в процессе проектирования решения невозможно предусмотреть все нюансы для реализации операционной модели продукта. Тестирование MVP и MLP позволяет «набить шишки» и увидеть по факту, что работает, а что нет, а также что и как реализовывать.
Поэтому PoC, MVP и MLP выступают не просто этапами разработки, а философией снижения бизнес-рисков при запуске инициатив в форме продуктов или проектов.
Также, MVP можно использовать для получения более быстрого бизнес-эффекта. Например, если вы хотите запустить инфраструктурный проект в компании, который будет длиться 3 года, то можно сначала запустить MVP, чтобы получить бизнес-эффект за 6 месяцев и потом продолжать развивать его.
Когда нужно снижать бизнес-риск: продуктовый vs проектный подход
В условиях неопределенности, когда цели, требования или технологии неясны, снижение бизнес-рисков становится критически важным.
Продуктовый подход, с его короткими итерациями и адаптивным планированием ресурсов не больше чем на итерацию, идеально подходит для таких ситуаций. Он позволяет быстро реагировать на изменения и фиксировать потери на ранних стадиях разработки. Например, стартапы в сфере технологий, такие как Spotify и Netflix, использовали этот подход для тестирования новых функций на небольших группах пользователей перед широким запуском, что позволило им минимизировать риски и оптимизировать продукт под запросы рынка.
В противовес этому, проектный подход, с его фиксированными ресурсами, стоимостью и требованиями до конца проекта, сколько бы он не длился, подходит для задач с четко определенными целями. Примером может служить строительство объектов инфраструктуры, таких как мосты или железные дороги, где требования и условия проекта утверждаются заранее, а изменения могут влечь за собой значительные дополнительные расходы и задержки.
Подробнее про управление в разных контекстах и уровнях неопределенности можно почитать здесь.
PoC, MVP и MLP – формат снижения бизнес-риска через тестирование в продуктовом подходе – это виды исследований, которые относятся к качественным или количественным методам, в зависимости от дизайна исследования. Например, если вы проводите тестирование PoC в фокус-группе, то это качественный метод исследования, а если проводите A/B-тест MVP, то это уже количественный метод.
Как определить что разрабатывать: MVP или MLP
Концепция продуктовой совокупности (Total Product Concept) — это подход, который предлагает рассматривать продукт как комбинацию нескольких уровней:
-
Базовый продукт определяет основную функциональность, которую должен выполнять продукт. Например автомобиль должен ездить;
-
Ожидаемый продукт включает атрибуты и условия, которые потребители обычно ожидают при покупке. Например автомобиль должен не только ездить, но и иметь кондиционер;
-
Расширенный продукт предлагает дополнительные особенности и преимущества, которые выделяют продукт на рынке. Например автомобиль должен не только ездить и иметь кондиционер, но и уметь самостоятельно парковаться;
-
Потенциальный продукт включает возможные будущие улучшения и инновации, которые могут быть внедрены для удержания конкурентного преимущества. Например функция автопилота в автомобилях.
В рамках концепции продуктовой совокупности, MVP (Minimum Viable Product) является базовым продуктом, а MLP – ожидаемым продуктом.
Выбор между MVP и MLP зависит от зрелости рынка, на котором вы собираетесь работать. Есть два варианта:
-
Рынок на котором нет аналогов вашему решению. Например, генеративные нейросети в 2023 году или рынок продуктов питания в 1990-е годы в России. Клиенты на этом рынке не имеют никаких ожиданий, так как аналогичных продуктов они еще не видели. Когда нет никакой колбасы – привезите любую, когда нет ни одного приложения по учету расходов – сделайте хоть какое нибудь;
-
Рынок, на котором уже есть решения аналогичному вашему. У клиентов уже есть ожидания от продуктов вашего типа, которые сформировали конкуренты. Если колбасы уже на рынке много и приложений по учету расходов тоже, то у потребителей есть выбор, а значит есть ожидания, с которыми нужно считаться.
Так вот в первом варианте вы можете обойтись MVP, а вот во втором – уже нужно выпускать MLP. Например, сегодня вы хотите выпустить новую марку автомобиля: очевидно что вы не сможете обойтись базовым продуктом, вам нужно чтобы в автомобиле было большинство функций которые уже предлагаю конкуренты, то есть разработывать ожидаемый продукт.
Этапы создания MVP и MLP
Тестирование MVP/MLP — это исследовательский проект. Поэтому важно сделать дизайн этого исследования.
Шаг 1. Определение бизнес-задачи
Это ответ на вопрос «Что мы должны получить от инициативы, выраженное в измеримой форме?». Он всегда должен лежать в плоскости бизнеса, например:
-
Занять долю рынка в 10%;
-
Повысить выручку на 20%;
-
Снизить затраты на привлечение персонала на 15%;
-
Снизить риски потери клиентов до зеленого уровня.
Шаг 2. Определение списка исследовательских вопросов
Если тестирование MVP/MLP — это исследовательский проект, то должен быть список исследовательских вопросов, на которые нужно ответить в рамках тестирования в плоскости функций или бизнес-процессов, например:
-
Какая будет конверсия в покупку;
-
Что мы не предусмотрели при реализации бизнес-процессов;
-
Какие функции более важные и менее важные для клиентов;
-
Какие баги мы не учли;
-
Есть ли тот эффект, что мы предполагали.
Основные задачи MVP – подтверждение данных от клиентов, которые были получены на этапе качественных исследований, или получение более быстрого бизнес-эффекта от инициативы. Из этих задач и будут сформулированы основные вопросы.
Шаг 3. Определение списка функций
Для определения функций или свойств, которые будут включены в MVP/MLP, необходимо тщательно понимать потребности пользователей и приоритизировать функции на основе их важности. Для этой цели эффективно применяются методы Кано и карточной сортировки. Предпочтительнее использовать метод Кано, но если нет времени и ресурсов, то можно использовать более простой метод карточной сортировки.
Обратите внимание, что эти методы можно использовать не только для ИТ-продуктов, например определять функции автомобиля, свойства йогурта или услуги в кафе.
Метод Кано
Суть метода заключается в классификации функций продукта на основе того, как они воспринимаются пользователями, и выявлении тех, которые могут значительно повысить удовлетворенность клиентов:
-
Создаются вопросы, каждый из которых касается одной конкретной функции продукта. Для каждой функции формулируются два вопроса: один оценивает реакцию пользователя, если функция присутствует (функциональный вопрос), а другой – если функция отсутствует (дисфункциональный вопрос).
-
Опрос проводится среди потенциальных клиентов продукта. Ответы анализируются для классификации каждой функции в одну из категорий:
-
Основные (Must-be): Функции, которые должны присутствовать в продукте. Их отсутствие вызывает недовольство пользователей, но их наличие не приносит значительного удовлетворения, так как пользователи считают их очевидными.
-
Ожидаемые (Performance): Эти функции прямо коррелируют с уровнем удовлетворенности клиента; чем их больше или они лучше, тем выше удовлетворенность. Они представляют собой основные аспекты продукта, которые напрямую увеличивают или уменьшают удовлетворенность пользователя.
-
Восхитительные (Attractive): Функции, которые не ожидаются, но если они присутствуют, то значительно повышают удовлетворенность пользователя. Они могут существенно отличать продукт на рынке и создавать «вау»-эффект.
-
Безразличные (Indifferent): Функции, которые не влияют на удовлетворенность пользователя, независимо от их наличия или отсутствия.
-
Обратные (Reverse): Функции, наличие которых может вызывать недовольство у пользователей. Их отсутствие, напротив, может увеличивать удовлетворенность.
Метод карточной сортировки
Это техника используется для понимания того, как клиенты воспринимают и группируют различные информационные элементы.
-
Создаются карточки для каждой функции или свойства, которые предполагается включить в продукт. Каждая карточка должна содержать краткое описание.
-
Опрос проводится среди потенциальных клиентов продукта. Они должны группировать карточки в категории основных (Must-be), ожидаемых (Performance), восхитительных (Attractive), безразличных (Indifferent) и обратных (Reverse) функций.
Шаг 4. Выбор формы и создание MVP/MLP
|
Формы PoC |
Формы MVP |
Формы MLP |
|
Онлайн прототип Физический прототип Текстовое описание Презентация Видео Дегустация Тестовый стенд Landing page Excel-документы |
Приложение или программа с базовыми функциями Алгоритмы в Excel-документах Приложения на ноукод-платформах Ручной труд вместо кода за интерфейсом приложения Оффлайн точка с ограниченными ассортиментов товаров или услуг Проекты с ограниченными объемом услуг Услуги ограниченные во времени предоставления Выезд на дом вместо открытия оффлайн точки |
Все формы MVP с расширенными свойствами, которые ожидает рынок |
Шаг 5. Запуск тестирования, сбор данных и принятие бизнес-решений
Суть работы MPV/MLP – запустить его в опытную эксплуатацию, то есть в рабочий контекст и наблюдать за тем, как он работает, чтобы собрать информацию и принять бизнес-решения. Есть четыре способа сбора информации:
A/B-тестирование
Этот метод включает одновременный запуск двух версий продукта или процесса для оценки их эффективности. Например, можно организовать две производственные линии, где на одной брак определяет человек, а на другой — робот. Сравнив результаты обеих линий, вы можете оценить, как много дефектов пропустил робот и сколько — человек.
Анализ «Было – Стало»
В этом методе не требуется создавать две версии чего-либо. Вы анализируете прошлый и нынешний опыт. Например, если раньше на производственной линии брак искал человек, а теперь его место занимает робот, вы анализируете, как справляется новая система.
Метод наблюдения
Этот способ предполагает сбор данных без программного обеспечения. Наблюдатель сам следит за работой MVP и фиксирует необходимые данные.
Дневниковые исследования
Участники, работающие с продуктом, ведут дневник своих наблюдений. Они записывают свой опыт взаимодействия с продуктом, что позволяет получить представление о его использовании и эффективности в реальных условиях.
После того как вы собрали данные с помощью тестирования, вы можете ответить на исследовательские вопросы, которые определили ранее.
Шаг 6. Масштабирование инициативы
После успешного прохождения стадии MVP/MLP, следующим шагом является масштабирование инициативы или перевод ее в промышленную эксплуатацию. Тут есть две стороны:
-
С точки зрения менеджмента нужно переводить MVP/MLP тогда, когда он доказал бизнес-эффект;
-
С технической точки зрения необходимость в техническом рефакторинге или развитии возникает, когда существующая реализация MVP/MLP не может поддерживать требуемый уровень масштабирования.
В этом вопросе все сильно зависит от контекста, но, в любом случае, переход в промышленную эксплуатацию должен быть публично оформлен в команде.
Ошибки создания MVP/MLP
Ошибки в оценке необходимости MVP/MLP
Не каждый проект требует разработки MVP/MLP. Важно заранее определить, какие бизнес-риски он должен минимизировать и будет ли его создание оправдано.
Отсутствие четких критериев успеха
Перед началом тестирования MVP необходимо четко определить бизнес- и исследовательские задачи, а также методы сбора данных. Это позволит объективно оценить результаты тестирования и сделать обоснованные выводы о жизнеспособности инициативы.
Недостаточные исследования рынка
Игнорирование целевой аудитории и обратной связи на ранних этапах может привести к разработке продукта, который не соответствует реальным требованиям рынка. Особенно важно разделять базовый и ожидаемый функционал, а также понимание того, что необходимо разрабатывать: MVP или MLP.
Перегрузка функционалом
Важно ограничиться теми функциями и свойствами, которые действительно необходимы для тестирования основной гипотезы. Проведение предварительных исследований аудитории и рынка поможет точнее определить, какие функции стоит включить в MVP/MLP.
Неверная интерпретация данных
При анализе результатов важно избегать субъективной интерпретации данных. Также нужно учитывать статистическую значимость, если вы принимаете решение на основе количественных данных.
Краткая инструкция по применению
-
Выбор подхода. Оцените уровень неопределенности в вашем проекте. Если вы точно знаете, что нужно реализовать, и требования стабильны, то выбирайте проектный подход. В условиях неопределенности, когда требования могут меняться, лучше использовать продуктовый подход и использовать PoC, MVP и MLP;
-
Анализ рынка. Определите, насколько ваш рынок зрелый. На насыщенных рынках, где пользователи имеют высокие ожидания, целесообразнее разрабатывать MLP для создания уникального пользовательского опыта и выделения среди конкурентов. На новых или мало насыщенных рынках достаточно MVP;
-
Определение бизнес-задачи. Ясно сформулируйте, какие бизнес-цели должен достигнуть инициатива в рамках тестирования. Это поможет сфокусироваться на ключевых функциях и определить, какие риски должны быть минимизированы с помощью MVP/MLP;
-
Исследования клиентов: Проведите исследования, чтобы определить, какие функции наиболее важны для вашей целевой аудитории. Используйте метод карточной сортировки или анализ по методу Кано;
-
Выбор формы и создание. Выберите наиболее дешевую форму и реализуйте MVP/MLP;
-
Тестирование и сбор данных. Выберите метод тестирования и проведите опытную эксплуатацию продукта для сбора данных и анализа бизнес-эффекта;
-
Анализ результатов и масштабирование. Оцените собранные данные и принимайте обоснованные решения о дальнейшем масштабировании инициативы или ее изменении. Если результаты положительные, переводите инициативу в промышленную эксплуатацию для масштабирования бизнес-эффекта.
В результате этот подход поможет вам получить ответы на свои бизнес-вопросы, а также снизит риск потерь ресурсов на продукты и проекты, которые потенциально не принесут положительного бизнес-эффекта.
Если вам была полезна эта статья, то проголосуйте за нее и поделитесь ею с друзьями.
ссылка на оригинал статьи https://habr.com/ru/articles/813935/
Добавить комментарий