Вы узнаете, чем отличаются концепции MVP, MLP и RAT, по каким принципам собирать MVP, какие фичи и функциональность включать в MVP, а что оставить за бортом.

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

Этот термин появился еще в 2001 году благодаря Фрэнку Робинсону из SyncDev, а затем получил огромную популярность в сообществе стартаперов стараниями Стива Бланка, создателя методологии Customer Development, и Эрика Райса, автора «Lean Startup».

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

Определимся с критериями MVP:

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

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

Какие цели помогает достичь MVP:

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

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

Другая известная метафора MVP легла в основу стратегии под названием Cupcake Model.

Feedback loop

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

Сбор фидбэка должен стать регулярным и системным процессом: интервьюируйте пользователей на всех этапах воронки, проводите опросы, настройте формы обратной связи и онлайн-чаты. Необходимо агрегировать все отзывы о продукте, конвертировать их в новые гипотезы и как можно скорее вносить изменения в MVP. А после этого релизим новую версию — и снова собираем обратную связь из всех каналов, брейнштормим и быстро меняем продукт. Повторяем алгоритм сотни раз, пока не убедимся, что нашли product/market fit. Этот цикл называется feedback loop. Чем быстрее вы сможете совершать итерации, тем больше шансов выяснить, какие на самом деле потребности существуют у клиентов и как их можно закрыть.

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

Главная проблема MVP — это лично ты и твой гребаный перфекционизм. 

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

Если вам не стыдно за первую версию вашего продукта, вы запустились слишком поздно.

Примеры MVP

• Skyeng. Сегодня Skyeng — самая большая школа английского языка в Европе. Но на старте у нас не было своей платформы для обучения, CRM-системы, мобильного приложения и многого другого. Базы учителей и учеников хранились в табличках и карточках, уроки вели через Skype, а расписание составлялось полностью вручную.
• Airbnb. В первой версии одного из самых популярных сервисов для путешественников нельзя было выбрать жилье, глядя на карту, и даже не было оплаты на сайте. Был только список объявлений о сдаче домов, авторы которых принимали оплату наличными.
• Groupon. Самый большой сервис-купонатор начался с простого блога на WordPress, куда основатели ежедневно вручную добавляли лучшие предложения. С помощью простого виджета эти офферы потом рассылались по почте.

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 в Минске.

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

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

Пример MVP-RAT

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

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

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

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

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

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

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

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

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

Вместо заключения

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

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

Опишем основные шаги на пути создания MVP:

Шаг 0. Сформулировать основную ценность продукта в одном предложении.

Шаг 1. Провалидировать потребность с помощью интервью с потенциальными клиентами.

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

Шаг 3. Убедиться, что вам действительно нужно разрабатывать MVP и вы не можете проверить гипотезу методом Sales First.

Шаг 4. Составить CJM клиента по будущему продукту. Сохранить в нем только критичные для пользователя сценарии.

Шаг 5. Приоритизировать список фич в продукте по важности, а затем последовать совету Эрика Райса: сократить его в два раза. Повторить эту операцию дважды.

Шаг 6. Продумать, как получить от пользователей максимум обратной связи.

Шаг 7. Настроить feedback loop.

Шаг 8. Вы великолепны!