Комментарии
Что на самом деле представляет из себя минимально жизнеспособная версия продукта, с чем её не стоит путать и как её создавать
Ещё раз об MVP
Сибирикс
Ещё раз об MVP
Что на самом деле представляет из себя минимально жизнеспособная версия продукта, с чем её не стоит путать и как её создавать
В продуктовой разработке, в разработке сайтов, при создании стартапов все уже привыкли, что нужно начинать с MVP: сделать версию с ограниченной функциональностью, чтобы проверить свою гипотезу «зайдёт / не зайдёт», а уж потом создавать полноценный продукт. И, вроде бы, всем всё понятно, только что такое эта «ограниченная функциональность» и почему вокруг неё «сколько людей — столько и мнений»? Всё проще (и одновременно сложнее), чем кажется.

Что такое MVP и что им не является

Минимальный жизнеспособный продукт MVP — ключевая философия движения Lean (бережливого производства). Термин придумал Фрэнк Робинс в 2001 году, а Эрик Райс его популяризировал в своей книге «Lean Startup», дав ему такое определение:

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

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

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

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

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

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

Заблуждения о MVP

1. MVP — это продукт

Частая проблема с MVP — о нём думают как о продукте, хотя на самом деле это процесс, или даже «тренажёр», с которым можно отрабатывать свои бизнес-идеи. Это значит, что MVP — лишь один из способов проверить гипотезу (а способов много — например, CustDev).
MVP — не просто необходимый и достаточный процесс разработки продукта. Это экспериментальный бизнес-процесс — а значит, он никогда не заканчивается: проверили гипотезу необходимости продукта на рынке — продолжаем выдвигать и проверять гипотезы о его постоянном улучшении.
2. MVP — фундамент будущего продукта

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

Фредерик Брукс-младший в своей культовой книге «Мифический человеко-месяц» писал, что на большинстве проектов любая впервые созданная система всегда идёт в корзину: она или слишком медленная, или слишком большая, или неудобная в использовании — или всё это вместе. И нет никакого другого способа это исправить, кроме как начать сначала, учитывая первый опыт — так вы создадите версию, в которой решите эти проблемы. Так что создать на старте что-то неудовлетворительное — это норма, потому что никакое планирование не поможет сделать все правильно с первого раза.


3. MVP — это более дешёвая версия продукта или версия продукта с минимальным набором функций

В детстве, пока ваша мама жарила блины, вы таскали по одному готовому, но вам почему-то не приходило в голову есть блинное тесто ложками. Скорее всего, потому, что не жареный блин — это ещё не блин, а стопку готовых блинов ждать слишком долго :)

Поэтому не стоит думать об MVP как о каком-то «неполноценном» продукте — это, скорее, серия мини-экспериментов с целью проверить жизнеспособность вашего будущего продукта. Вспоминая блины, каждый готовый блинчик — это MVP, который проверяет тесто на пригодность: достаточно ли в нём соли, сахара и не слишком ли оно жидкое.
Когда Apple впервые выпустила iPhone, ему не хватало многих функций, которые предлагали телефоны конкурентов (в основном — телефоны Nokia). Но абсолютно другой интерфейс и новый пользовательский опыт отличали iPhone от конкурентов — и вряд ли этот продукт на тот момент можно было назвать «полу-готовым».
Сейчас могло показаться, что в настоящий MVP нужно запихнуть как можно больше опций и функционала — чтобы уж точно продукт был востребован аудиторией. И снова мимо.

Стив Бланк (отец Customer Development) в своём блоге рассказывает о стартапе, который хотел предложить фермерам использовать снимки полей, полученных с дрона, для более эффективной работы: снимки показывали бы, насколько здоровы растения, есть ли болезни или насекомые, достаточно ли удобрений и воды.

Ребята были уверены, что для тестирования гипотезы на реальном фермере им нужно:

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

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

И, конечно, это было ошибкой. Для проверки их гипотезы о том, что фермеры будут платить за собранные дроном данные, было бы достаточно арендовать дрон и вручную обработать полученные фото, а затем предоставить полученную информацию реальному фермеру.
В интернете гуляет популярная иллюстрация о «правильном» и «неправильном» MVP:
правильный и неправильный MVP
Как выглядит «неправильный» и «правильный» MVP. Автор — Хенрик Книберг (источник)
Но некоторым она кажется довольно бредовой, потому что форма, в которой будет представлен MVP, зависит от контекста и от того, что команда разработки пытается выяснить. MVP может быть даже не продуктом — иногда достаточно прототипа или проведённого эксперимента. MVP даже может быть не очень-то минимальным: потому что вряд ли потенциальный владелец спортивного авто будет готов сначала погонять на скейте и оценить свой пользовательский опыт :)

Как правило, большинство команд и владельцев продукта спотыкаются при создании MVP из-за одного из трёх популярных убеждений:
1
MVP должен быть минимальным (не всегда).
2
Это должен быть рабочий продукт или услуга (не всегда).
3
«Минимальный набор функционала» означает, что MVP может работать наполовину (вообще нет).
Чтобы избежать такой вот путаницы, достаточно просто сменить терминологию. Вышеупомянутый Хенрик Книберг предлагает такую:
1
Earlier Testable Product
Самая ранняя версия продукта, доступная для тестирования.
2
Earlier Usable Product
Самая ранняя версия продукта, пригодная для использования.
3
Earlier Lovable Product
Самая ранняя версия продукта, которая нравится.
Такой подход лучше передает цели на каждом этапе создания продукта и помогает не потерять смыслы.

Другие альтернативы MVP

MMP (Minimal Marketable Product, или иногда — Minimal Sellable Product). Не просто продукт, которые решает какую-то боль потребителя — он решает её так круто, что пользователь готов за продукт заплатить, даже если есть бесплатные аналоги у конкурентов.

В нашем хаос-планировщике SingularityApp можно сначала распланировать день, затем распечатать список задач на бумаге, внести в него пометки (галочки и крестики), а потом отсканировать распечатку, чтобы эти пометки сами собой появились в приложении. Такой функционал есть только в платной версии, и пользователи готовы за него платить, поскольку больше ни одно приложение для планирования такого не предлагает.

MLP (Minimum Lovable Product) — продукт с каким-то классным преимуществом, за которое потребитель готов выбрать именно его, даже если он не закрывает абсолютно все его потребности.

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

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

RAT (Riskiest Assumption Test) — проверка наиболее рискованной гипотезы. Метод похож на MVP, но у них различается последовательность действий. При MVP типичный цикл выглядит как: идея → MVP → обратная связь от пользователей. При RAT шаги меняются местами: идея → обратная связь от пользователей → MVP. Такой подход даёт понятную картину отклика со стороны пользователей ещё до того, как какая-либо версия продукта будет сделана. Подробнее о RAT мы писали в этой статье.

С чем не стоит путать MVP

Proof of Concept

Proof of Concept (PoC) — доказательство правильности концепции, его цель — доказать идею и/или подтвердить выбор технологии, показав реалистичную реализацию части функционала будущего продукта. PoC сконцентрировано на определенном аспекте, и его функциональность сильно ограничена по сравнению с полноценным продуктом.

У PoC обычно короткий жизненный цикл: его создают, чтобы понимать, стоит ли проект дальнейших инвестиций и новых итераций. Доказательства правильности концепции редко показывают реальным пользователям (только если не нужна их обратная связь). PoC нельзя использовать повторно — если в итоге владельцы стартапа решат развивать продукт дальше, может потребоваться рефакторинг и реинжиниринг.

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

Визуальный прототип

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

Прототипы отлично подходят для объяснения концепции и получения отзывов от пользователей и заинтересованных сторон.

Функциональный прототип

Обычно представляет собой быструю реализацию (с допущениями и ограничениями) наиболее репрезентативной или важной функциональности. Это не готовый, сырой, продукт, но для тестирования на небольшой группе пользователей или презентации нужного функционала вполне годится. Из-за этого порой кажется, что усилия по его созданию куда больше, чем его эффект :)

Пилотный проект

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

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

Каким бывает MVP

Wizard of OZ MVP или MVP Флинстоуна

Суть — имитация рабочего функционала для потребителя: он видит полноценный автоматизированный проект, но на деле это лишь красивый фасад, и вся автоматизация работы продукта достигается вручную. Это одна из самых экономичных моделей для проверки бизнес-гипотезы: если она «выстреливает», можно приниматься за создание полноценного продукта.
Канонический пример — интернет-магазин Zappos. Его основатель собрал простенькую страничку с возможностью покупки понравившейся пары, договорился с продавцом ближайшего обувного магазина, сделал фото нескольких пар и выставил их на продажу онлайн. При заказе от клиента он просто шёл, покупал нужную пару в физическом магазине и отправлял её клиенту — и никаких запасов, склада и вот этого всего :)

Concierge MVP

Подход Concierge MVP намного проще, менее затратен и более эффективен для изучения потребностей клиентов. С ним вам даже не нужен какой-то реализованный функционал — вы можете предоставить его самостоятельно, поработав руками. В случае с Zappos можно было даже не делать сайт, а обойтись, например, рассылкой по электронной почте.

MVP с одной функцией

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

Разрозненный MVP

Похоже на предыдущие типы тем, что вы работаете руками — например, вместо создания сервиса пока вручную объединяете в один интерфейс набор других, которые дают нужный функционал. Сервис совместных покупок Groupon начинал именно так.
Иногда и сбор средств на краудфандинговой площадке или посадочная страница пока несуществующего продукта могут работать как MVP: если пользователям нравится идея — значит, её стоит реализовать.

Как определить, что должно входить в MVP

1. Разделить функционал на основной и тот, что относится к функциям улучшения

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

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


Метод 1. Удаление
Если удаление функции никак не влияет на взаимодействие с пользователем, то это функция улучшения. Если же стратегически без неё не обойтись — это фундаментальная функция. Например, пользователь немного потеряет, если на сайте не будет хитрой сортировки, но если не будет кнопки «купить», ему такое вряд ли понравится.
Александр
Аккаунт-менеджер
На проектах на этапе MVP, как правило, мы реализуем базовый функционал в самой своей базовой постановке. Это всё то, без чего сайт не сможет приносить прибыль. Если речь про e-commerce, это каталог товаров, карточка одного товара, корзина, форма оплаты. Если это какой то сервис, это минимальный набор взаимодействия с пользователем: личный кабинет, формы для обращений, интерфейс для обработки заявок.

В контур базового функционала НЕ попадают плюшки для апсейл-продаж (блоки недавно просмотренных товаров или «вам также может понравиться»). Бывает, что у клиента база товаров на момент старта разработки пока не приведена в образцово-показательный вид, из-за чего мы не можем организовать SKU по товарам — тогда это мы выносим на второй этап (хотя именно это делать во втором спринте — бывает больно).

Если коротко — в MVP не включается всё то, что не влияет на базовый функционал, увеличивает стоимость разработки (и пока непонятно, насколько функционал вообще оправдан) и что не укладывается в дедлайн первой версии проекта.
Метод 2. Ключевые вопросы
Просто спрашиваем себя:
  1. Критичны ли сложные функции для ценностного предложения?
  2. Приведут ли инвестиции в эти функции к революционному предложению или к ценной и уникальной возможности?
Если нет — к чёрту такие функции на этапе MVP.


Метод 3. Простая ревизия
Вам нужно расписать продукт как набор функций или пользовательских историй, затем оценить каждую по стоимости и затратам на реализацию и расставить приоритеты — так вы сможете выделить главный функционал, который создаёт ценность для пользователя. Ба, да это же старый-добрый бэклог!
Алла
Аккаунт-менеджер
В первую очередь, всё зависит от сути проекта. Обычно MVP требуется для сложных и долгих проектов (торговых площадок, порталов с несколькими личными кабинетами и всего того, что слишком объёмно, чтобы реализовать за один этап). Поэтому сначала важно запустить приоритетные функции, а затем уже добавлять улучшения, расширять функционал, пока не кончится фантазия или деньги :)

2. Не думать только о функциональности

Иногда команды воспринимают деление на основные и дополнительные функции слишком буквально и пытаются сосредоточиться лишь на функциональности. Но продукт — это нечто больше, чем сумма его характеристик. Любой MVP должен иметь набор функций, которые для пользователей достаточно ценны, хороши в юзабилити, вызывают доверие и надёжны. Но хороший MVP ещё и добавляет что-то «сверху», что дарит радость и эмоции от использования продукта и выделяет его среди других.
более грамотный подход к MVP
Более адекватная схема разработки MVP, предложенная Юсси Панассеном (источник): вместо того, чтобы добавлять продукту слой за слоем, стоит реализовать продукт по чуть-чуть в каждом из слоёв (функциональность, надежность, юзабилити и эмоциональность)
Продуктовые характеристики (функциональность, надежность, юзабилити и эмоциональный дизайн) наслаиваются друг на друга, и если увеличить область действия одного слоя, то автоматически увеличится и область действия всех слоев над ним. Добавим новых функций — придётся поработать над тем, чтобы продукт оставался надежным и простым в использовании. Если же планируемый объём для MVP слишком велик, логичнее всего урезать фундамент этой пирамиды — функциональность.

Диаграмма выше говорит только о составляющих продукта, хотя в его основе по факту лежат потребности пользователей и пользовательские сегменты (с этого в целом стоит начинать его создание). Поэтому UX Manager Shopify Андрей Гаргуль предложил дополнить схему двумя слоями ниже:
с чего начинать MVP
Соответственно, чтобы MVP был действительно минимальным, для начала можно сузить аудиторию. Ничто так не сократит время разработки продукта, чем выбор «своей аудитории» (той, которая получит наибольшую пользу от продукта на начальном этапе) и отказ (или откладывание на другие этапы) для всех остальных сегментов. Чем шире аудитория, тем больше у нее потребностей и проблем, тем больше функций придётся создать и тем более сложным и трудным в использовании будет в итоге продукт.

А чтобы MVP был достаточным с точки зрения пользователя, нужно хорошо знать его ожидания — это второй слой пирамиды на рисунке выше. Потому что одно дело не попасть в них на 100%, а совсем другое — не попасть вообще. Ожидания пользователей обычно основываются на их предыдущем опыте использования аналогичных продуктов. Это верно, только если вы не создаёте что-то принципиально новое, как Генри Форд когда-то создал автомобиль вместо лошадиной упряжки — но ведь и здесь он смотрел на потребность людей добираться из точки, А в точку Б быстрее и комфортнее. Поэтому, похоже, без исследований потребителя на старте вообще не обойтись.
Итого: MVP — это минимально крутой продукт, который не жертвует пользовательскими опытом и ценностью.

Как создавать MVP — шаги

1
Найти реальную потребность пользователей и поделить аудиторию на конкретные сегменты
Не вы придумываете боли и потребности, вы узнаёте их у самих людей, в идеале — из интервью. Здесь вам снова сильно поможет Customer Development, а ещё концепция Jobs To Be Done. Последняя говорит о том, что одну и ту же потребность могут решить совершенно неожиданные продукты и услуги. Например, чтобы скоротать вечерочек, вы можете купить бутылку вина, а можете — пойти в кино или принять ванну. И тогда вино, американский блокбастер и соль для ванн будут вторичными конкурентами друг для друга.

Бывает, что вам самому чего-то отчаянно не хватает на рынке, и вы придумали решение проблемы — тогда не поленитесь узнать у людей с потенциально подобной потребностью, насколько им импонирует ваше решение. Возможно, чистить зубы кварцевым песком для идеальной белоснежности понравится только вам :)
2
Изучить конкурентов

А есть ли они вообще? Если нет, то почему (возможно, не зря)? Если есть, чем их продукт отличается от вашего? Где не дотягивают? Где классно? Не поленитесь и сделайте матрицу SWOT-анализа (да, того самого, который вам не нравился в университете):

  • сильные стороны (Strengths) — чем ваш продукт хорош;
  • слабые стороны (Weaknesses) — в чем уступает;
  • возможности (Opportunities) — ситуация на рынке, настроения потребителей;
  • угрозы (Threats) — законодательство, санкции, курсы валют и прочие внешние факторы.
3
Составить Customer Journey Map
Когда вы знаете свою аудиторию и ваши сильные стороны на фоне конкурентов, можно приступать к конструированию CJM: как потенциальные покупатели или пользователи будут приходить в ваш продукт, что будут делать внутри и через какие шаги им нужно пройти, чтобы сделать целевое действие и принести вам прибыль. Подробнее о том, как строить карту путешествия пользователя, мы описали здесь.
4
Описать функционал продукта
Функционал должен быть такой, чтобы удовлетворить потребности потенциальной аудитории и создать простой понятный опыт внутри продукта. И такой, чтобы в чём-то отличать вас от конкурентов. На этом этапе достаточно описать все-все-все фичи, которые вы планируете реализовать.
5
Определить критический функционал, который войдёт в MVP
Расставьте приоритеты по каждой функции и выделите главные — те, без которых продукт не сможет существовать, радовать потенциальных клиентов и приносить вам деньги уже на этапе MVP.

Вспоминайте диаграмму — чем больше сегмент, тем больше нужно функционала. Поэтому если критического функционала здесь вдруг окажется слишком много, вернитесь к 1 шагу и пересмотрите объём потенциальной аудитории для MVP.
SCRUM идеально подходит для итерационной разработки продукта. В Бэклоге вы собираете все нужные фичи, расставляете их по приоритетам и решаете, какие из них вы будете реализовывать в первом спринте — на первом этапе. Результат первых 1−3 спринтов — и будет вашим MVP.
6
Создать и протестировать MVP
Пилите продукт, постоянно тестируете внутри команды, улучшаете и доделываете то, что не нравится. Подводных камней здесь всегда очень много — знаем сами, потому что писали с нуля хаос-менеджмент планировщик, который сильно отличается от всего, что было до этого на рынке.

MVP готов — что дальше?

Во-первых, продолжать тестировать, но уже на реальных пользователях. Главное — идти к ним и по-настоящему разговаривать. Можно сколько угодно гадать, как они воспринимают ваш продукт, а можно — просто спросить. Но главное, уметь спрашивать правильно (наш большой материал о Customer Development опять в помощь: внутри найдёте примеры грамотных вопросов и где вообще брать людей для подобных бесед о продукте.)

Во-вторых, читать отзывы, чтобы знать, что улучшать (совет от КЭПа, но всё-таки): если у 10 пользователей одинаковая проблема → скорее всего, она есть, и её нужно исправить. Если только у одного → убедитесь, что дело не в его локальном устройстве.

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

Успехов!