Минимально жизнеспособный продукт: типы, методы, этапы построения
Адаптированный перевод публикации The Startup

Если бы существовала книга о самых сокрушительных провалах стартапов, то в ней было бы не менее тысячи страниц. Каждый совершает стратегические ошибки, даже такие гиганты, как Amazon. В 2014 году компания объявила об убытке в 170 млн долларов после неудачи с Fire Phone. Причина провала проста: никому не нужен был этот телефон, кроме самой Amazon. Гаджет предназначался для подключения пользователей непосредственно к торговой платформе. Пользователи уже использовали смартфоны iPhone и Android для подключения к Amazon. Отсутствие исследований по анализу потребностей пользователей сыграло злую шутку с Amazon.

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

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

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

Eric Ries, предприниматель и автор книги The Lean Startup, дает полное определение минимально жизнеспособного продукта, обращая особое внимание на обучающие перспективы, которые открывает MVP. По его словам, MVP является «той версией нового продукта, которая позволяет команде собрать максимальное количество проверенных знаний о клиентах с наименьшими усилиями».

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

MVP не следует путать с доказательством правильности концепции (PoC — proof of concept). Последнее можно интерпретировать по-разному в зависимости от отрасли.

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

Drew Houston, основатель Dropbox, сделал объяснительное видео и рассказал в нем, как должен работать Dropbox. Около 75 000 человек подписались на него в первую же ночь. Подобный метод может быть реализован с помощью блога, в котором вы делитесь с аудиторией идеями о продукте, который планируете разработать. Хоть и некоторые относят доказательство правильности концепции к MVP, мы склонны классифицировать эту трактовку отдельно как PoC.

Термины MVP и PoC взаимосвязаны, но не взаимозаменяемы. Доказательство правильности концепции, реализуемое оптимальным образом, становится минимально жизнеспособным продуктом.

Существует множество подходов к созданию MVP. Давайте рассмотрим основные типы.

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

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

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

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

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

Groupon — отличный пример разрозненного MVP. Его основатель Andrew Mason запустил сайт на WordPress, где вручную размещал изображения еды каждый день. Он генерировал предложения в виде PDF-документов, используя AppleScript, и отправлял их по электронной почте через Apple Mail. Так он подтвердил гипотезу Groupon.

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

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

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

Мы предлагаем пошаговое руководство по проверке вашей идеи и превращению ее в продукт. Вы сможете создать MVP за семь шагов. Шаг 0 — введение в основные принципы и методы. Восьмой и девятый шаги — о подходах к управлению проектами.

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

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

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

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

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

1. Определите своих конкурентов. Проанализируйте трех главных игроков рынка, узнайте, как долго они существуют на нем, какие продукты и услуги предоставляют. Определите, есть ли у них конкурентные преимущества и оцените свою способность предложить что-то лучшее.
2. Охарактеризуйте их долю на рынке. Исследуйте их прошлые и текущие стратегии, объем продаж, доходы, финансовые и маркетинговые цели. Эти данные помогут вам понять, насколько они успешны и рентабельны.
3. Используйте первичные и вторичные источники информации. Информация, которой компании делятся сами, — первичный источник, наиболее надежный для проведения анализа. Посетите веб-сайты компаний, изучите презентации, «белые книги», годовые отчеты, блоги, рекламные материалы и другие публикации. Вторичные источники информации — статьи в журналах и газетах, видеоролики, отчеты и книги — формируют общественное мнение об игроках рынка. Хотя эти источники могут быть менее надежными, чем первичные, они дают наиболее полное представление об отрасли.
4. Копайте глубже. Не стесняйтесь посещать деловые мероприятия, в которых участвуют конкуренты, устанавливайте контакты, пользуйтесь продуктом конкурентов и и анализируйте отзывы.
5. Пользуйтесь программами аналитики. Различные онлайн-инструменты для конкурентного анализа сделают вашу жизнь проще. Такие сервисы, как Similar Web, Ahrefs, Quantcast, App Annie или AppFollow собирают данные о сайтах и приложениях. С их помощью вы сможете узнать о популярности приложения / сайта конкурентов, об их ежемесячном трафике, интересах аудитории, географическом местоположении клиентов, а также похожих продуктах. Некоторые из существующих инструментов предоставляют базовую информацию бесплатно. Другие, как Moz и SensorTower, на условиях подписки.

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

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

Наилучшая практика проведения SWOT-анализа — использование кратких описаний, понятных всем членам команды

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

SWOT-анализ помогает компаниям анализировать конкурентов и выбирать стратегию позиционирования на рынке.

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

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

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

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

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

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

Мы перечислили 4 шага, которые пользователи совершают с помощью нашего продукта: формирование заказа, управление заказом, оплата еды, доставка заказа.

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

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

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

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

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

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

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

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

Определив объем работы, вы можете наконец-то приступать к разработке минимально жизнеспособного продукта. Давайте выясним, какие методы управления проектами применимы к построению MVP.

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

Другой итеративный подход к разработке программного обеспечения. Он подразумевает эффективное распределение объема работ, которое помогает командам быстрее выполнять задачи. Вы можете управлять разработкой функций MVP в спринте (короткие циклы — примерно по две или четыре недели). Определите scrum-мастера, который будет отслеживать стабильность работы всех scrum-процессов. MVP реализуется сразу после первого спринта. Команда разработки может обновлять продукт во всех последующих спринтах, реагируя на отзывы пользователей. Несмотря на то, что Scrum более трудоемкий, чем Learn, он может быть менее напряженным для специалистов — подходит для постепенного и длительного развития.

Фокусируется на модели незавершенного производства и, в отличие от Learn и Scrum, не имеет цикличной прогрессии. Вместо этого Канбан предлагает сосредоточиться на задачах по мере их появления. Это позволяет балансировать объем работы с возможностями команды. Специалисты добавляют задачи в конвейер, как только получают обратную связь от пользователей. Канбан может применяться после выпуска первой версии MVP и стать мощным методом, если обратная связь будет продолжать поступать.

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

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

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

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

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