Фрэнк Робинсон ввел термин MVP в 2001 году в одной из своих книг под названием Lean Startup. Минимальный жизнеспособный продукт или MVP — это приложение, которое поддерживает интерес клиентов с минимальной функциональностью, реализованной для сбора отзывов об использовании и расширения продукта в полнофункциональную систему. MVP стремится охватить основы того, что считается истинным в отношении предпочтений клиентов. Еще одна цель MVP — собрать как можно больше релевантных данных для проверки гипотез и понимания траектории роста продукта.

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

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

Перспектива бизнеса

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

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

Планирование и исполнение

Доказательство концепции (POC)

POC — это начальный этап разработки MVP, который используется для проверки идеи или функции в MVP. Прежде чем проводить какое-либо тестирование, любой бизнес должен исследовать и анализировать интересующий рынок. Этот процесс будет включать анализ сегментов и подсегментов, конкурентов и определение вашей целевой аудитории. Затем компания подходит к выбору ассортимента интересующих ее продуктов или услуг. Часто компании выбирают между этим:

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

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

Допустим, мы строим систему управления задачами для разработчиков программного обеспечения. Алекс — наша персона; ему около 20 лет, и он только что закончил бакалавриат по информатике. Алексей ищет решение для организации своего рабочего процесса. Поэтому мы определяем, какие действия Алекс будет выполнять с нашим приложением. Например, Алекс должен иметь возможность вводить код в заметки, используя синтаксис различных языков программирования (Python, C ++, JavaScript и другие).

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

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

Например, если бизнес решает выпустить клон Uber, должен ли он использовать собственную разработку с Swift и Kotin как для iOS, так и для Android, или они должны выбрать гибридный подход с использованием React Native или Flutter? Если вы выберете гибридную разработку, вы сможете создать приложение быстрее, используя меньше ресурсов; однако, как только ваша клиентская база увеличится, больше людей будут требовать более высокой производительности и функций, которые являются родными для платформы, которую они используют. Если вы выберете нативную разработку, у вас будет больше гибкости в будущем, но вы также вложите больше времени и денег в начале. Всегда есть компромиссы при выборе одного инструмента над другим, и поэтому бизнес должен учитывать все переменные, прежде чем делать выбор.

Дорожная карта

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

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

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

• Водопадная методология;
• Методология Канбана;
• Методология Scrumban;
• Методология Agile;
• Методология Lean;
• Адаптивный фреймворк проекта (APF);
• PRINCE2;
• PMBOK PMI;
• Методология шести сигм;
• Экстремальное программирование (XP).

Testing and Refining your MVP

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

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

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

Минимальный товарный продукт (ММП)

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

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

Обратная связь и аналитика после релиза

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

Помимо возможности генерировать доход, вы получаете возможность собирать ценную информацию, которую можно использовать для улучшения вашего продукта. Существует несколько методов сбора этой информации. Количество загрузок, процент активных пользователей, средний доход на пользователя (ARPU), количество людей, которые перестали использовать ваш продукт, рейтинги, статистика использования и многие другие показатели могут быть использованы для оценки успеха вашего MVP. Прежде чем вы сможете разработать стратегию расширения своего продукта, вам сначала нужно убедиться, что первоначальный MVP хорошо принят пользователями. По данным Enkonixхорошее эмпирическое правило заключается в достижении скорости 1,5% всех пользователей, которые совершают хотя бы одну покупку (если таковые имеются) из приложения, 1 из 3 пользователей открывает приложение один раз в месяц, 1 из 10 должен использовать его ежедневно. Как правило, цена, которую вы платите за приобретение нового клиента, не должна превышать 33% от пожизненной стоимости этого клиента.

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

Заключение

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