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

MVP vs MDP vs MLP

Концепцию MVP в последнее время часто критикуют — и с главным аргументом сложно не согласиться: у твоего продукта будет только одна возможность произвести на пользователя крутое первое впечатление. Многие менеджеры продуктов уверены, что так называемых early adoptеrs, самых первых клиентов сервиса, нужно удивить и подарить максимально впечатляющий пользовательский опыт, чтобы они плотно подсели на продукт и начали его активно рекомендовать. Это не означает, что в такой версии должно быть больше функциональности, чем в классическом MVP, но все-таки она должна производить wow-эффект. Этот концепт называют Minimum Loveable или Minimum Delightful Product.

Разработка MLP/MDP, очевидно, займет у команды больше времени. Дать универсальный ответ, стоит ли инвестировать ресурсы в MLP/MDP, невозможно: в некоторых высококонкурентных нишах это может оказаться единственно верным решением и по-другому получить первых пользователей не получится. Но на мой взгляд, обычно никакого конфликта между MVP и MLP нет. Это не взаимоисключающие вещи, а разные этапы эволюции продукта: сначала мы подтверждаем product/market fit, а затем совершенствуем пользовательский опыт. Важно помнить, что крутой UX не ограничивается модными интерфейсами и няшными анимациями, он складывается из огромного количества факторов, в том числе вежливости оператора колл-центра и tone of voice маркетинга.

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

Как-то раз уже известному вам Эрику Райсу задали вопрос, каким же должен быть минимально жизнеспособный продукт. Он ответил:

Возможно, гораздо более минимальным, чем вы думаете.

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

Можно снова вернуться к истории Airbnb. Все началось с того, что два дизайнера, недавно переехавших в Сан-Франциско, подметили: в городе проходит много конференций, но почти нет доступного жилья. Еще до создания каталога объявлений они проверили свою идею, купив несколько надувных матрасов в свою гостиную. Места в их доме разлетелись, как пирожки или билеты на Product Sense в Минске.

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

Riskiest Assumption Test

В том или ином виде эти идеи лежат в основе методологий RAT (Riskiest Assumption Test) или Sales First. Рекомендую погуглить эти базворды и потренировать свою насмотренность большим количеством примеров. Лично мне нравится называть этот инструмент «созданием максимально нежизнеспособного продукта».

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

Пример MVP-RAT

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

Цена ошибки у этого проекта была довольна высока. Во-первых, для большинства учеников Skyeng — это в первую очередь преподаватель. От точности подбора очень сильно зависит удовлетворенность нашей школой. Во-вторых, технически это довольно сложная фича, требующая больших затрат на разработку. Реализовать интерфейс подбора учителя можно тысячей способов — и было критично определить тот, который расширит «бутылочное горлышко» в достаточной степени, чтобы вывести проект в плюс.

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

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

Применимость MVP

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

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

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