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

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

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

Почему MVP, а не полноценный продукт?

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

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

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

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

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

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

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

2. MVP — фундамент будущего продукта

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

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


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

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

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

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

В интернете гуляет популярная иллюстрация о «правильном» и «неправильном» MVP:

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

Как правило, большинство команд и владельцев продукта спотыкаются при создании 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 мы писали в этой статье.

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

Метод 2. Ключевые вопросы
Просто спрашиваем себя:

1. Критичны ли сложные функции для ценностного предложения?
2. Приведут ли инвестиции в эти функции к революционному предложению или к ценной и уникальной возможности?

Если нет — к чёрту такие функции на этапе MVP.


Метод 3. Простая ревизия
Вам нужно расписать продукт как набор функций или пользовательских историй, затем оценить каждую по стоимости и затратам на реализацию и расставить приоритеты — так вы сможете выделить главный функционал, который создаёт ценность для пользователя. Ба, да это же старый-добрый бэклог!

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

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

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

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

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

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

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

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

Функционал должен быть такой, чтобы удовлетворить потребности потенциальной аудитории и создать простой понятный опыт внутри продукта. И такой, чтобы в чём-то отличать вас от конкурентов. На этом этапе достаточно описать все-все-все фичи, которые вы планируете реализовать.

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

Вспоминайте диаграмму — чем больше сегмент, тем больше нужно функционала. Поэтому если критического функционала здесь вдруг окажется слишком много, вернитесь к 1 шагу и пересмотрите объём потенциальной аудитории для MVP.

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

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

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

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

Успехов!