mvp проекта что это такое простыми словами
Начинаем с малого: что такое MVP и как это работает?
MVP (от англ. Minimum Viable Product, «минимально жизнеспособный продукт») — это начальный вариант продукта с минимальным набором функций, который разрабатывается для проверки гипотез. С помощью обратной связи можно понять, как развивать проект дальше и какие еще опции в него добавить.
Именно с MVP следует начинать создание digital-продукта. Это поможет уменьшить время, а также снизить затраты и риски на разработку продукта. Например, если ваша цель — сделать интернет-магазин, нужно выбрать для него самые необходимые функции. Именно они войдут в первую версию проекта.
Порядок разработки MVP зависит от различных переменных: вида продукта, ресурсов команды, ситуации на рынке и многих других. Но, даже не зная всех вводных, можно разделить процесс на этапы, которые необходимо пройти.
Когда вы определитесь, какую задачу должен решать конечный продукт, вам будет легче выбрать его необходимые функции. Именно они станут основой MVP.
На этом этапе вам необходимо максимально сузить целевую аудиторию. Именно она сможет дать ту обратную связь о MVP, которая поможет усовершенствовать его впоследствии. Ориентируйтесь на базовые критерии: возраст, пол, семейное положение и интересы клиента. Чем подробнее будет описание клиента, тем проще будет на этапе создания продукта.
Опыт других поможет понять, какие опции действительно нужны пользователям. Допустим, вы собираетесь создать мобильное приложение: изучите варианты, которые есть на рынке, какие функции в них встречаются чаще всего. Нужно ли добавлять в него авторизацию через СМС? Если это реализовано у многих других конкурентов, то стоит подумать над этой опцией.
Постройте customer journey map — историю взаимодействия пользователя с вашим продуктом. Путь не должен быть длинным и содержать множество шагов: добавляйте только необходимое. Например, если конечная цель вашего сайта — это продажа товаров, не превращайте процесс покупки в долгий квест с препятствиями.
Настало время выбрать необходимые опции для своего проекта. Делайте это на основе проведенного анализа и не добавляйте слишком много фич в начальный продукт. Их можно будет реализовать на следующих этапах, когда протестируете начальную версию продукта.
Есть разные подходы к созданию минимально жизнеспособного продукта. Выберите тот, который подходит вашей команде больше остальных.
Когда первая версия продукта готова, перейдите к ее тестированию. Его процесс зависит от подхода к MVP, который вы выбрали. Но даже при различиях в этапах главная цель тестирования — сбор мнений о проекте от реальной аудитории. Именно она поможет вам исправить недочеты и усовершенствовать продукт.
Создание MVP требует времени и ресурсов, но именно оно поможет избежать рисков и обезопасить себя при создании нового продукта. Поэтому мы в ITFactory помогаем клиентам определиться, какой функционал необходим сервисам и на какой стадии его внедрять.
Минимально жизнеспособный: как MVP помогает продукту выйти на рынок
Содержание
MVP (или Minimum Viable Product, «минимально жизнеспособный продукт») — это самая ранняя версия продукта, у которой есть минимальный набор функций, достаточный для презентации публике и проверке на первых потребителях. Однако такой продукт обязан демонстрировать достаточную ценность для пользователей.
Понятие ввел в оборот в 2001 году соучредитель и президент консалтинговой фирмы SyncDev Фрэнк Робинсон. Он определил MVP как итог «синхронной разработки» или одновременного развития продукта и исследования целевой аудитории.
MVP отличается от прототипа тем, что представляет собой рабочий продукт, который должен выполнять обозначенную функцию наилучшим образом. К примеру, это может быть бета-версия сайта компании, функциональность которой затем дополнят, изучив поведение первых посетителей.
Чем MVP полезен для бизнеса
Создание MVP дает прямые и косвенные финансовые преимущества. Оно позволяет бизнесу:
Примеры MVP
Гаррет Кэмп и Трэвис Каланик в 2010 году запустили приложение для iPhone UberCab, которое позволяло пассажирам арендовать для поездки автомобили премиум-класса всего в полтора раза дороже стоимости обычного такси. Идея у создателей родилась после того, как они заметили, что тарифы на городское такси стали несоразмерно высокими. Изначально приложение работало на ограниченной территории и с узкой целевой аудиторией, но спустя год бета-тестирования создатели смогли привлечь первые крупные инвестиции.
В 2008 году Брайан Чески и Джо Геббиа не смогли платить за квартиру-лофт в Сан-Франциско и решили проверить, существует ли спрос на аренду комнат напрямую от хозяина. Они создали простой одностраничный сайт с фотографиями своей квартиры и начали сдавать собственный чердак. Молодым дизайнерам удалось рассчитаться со всеми долгами. Уже в 2009 году их стартап привлек внимание Пола Грэма и получил первые инвестиции от его бизнес-инкубатора Y Combinator. После этого Чески и Геббиа поехали в Нью-Йорк, где ходили по домам клиентов и расспрашивали их об опыте аренды. Вскоре они поняли, что многих квартиросъемщиков отталкивают изображения плохого качества, которые фигурировали в объявлениях. Тогда молодые дизайнеры взяли напрокат зеркальный фотоаппарат и отправились по адресам в Манхэттене и Бруклине, чтобы самим фотографировать квартиры арендодателей.
Разработчики MVP стримингового сервиса сконцентрировались на функции потоковой передачи музыки. По итогам закрытого бета-тестирования приложения для Windows они заключили контракты с крупными лейблами и смогли получить значительное финансирование для своего проекта.
Авторы идеи создали MVP с чеки́нами и наградами за них в виде бейджей. После тестирования они начали расширять возможности сервиса, добавили рекомендации и путеводители по городам.
Изначально создатели сервиса купонов запустили сайт The Point, объединяющий людей, которые не могли в одиночку выполнить какую-либо задачу. Тестирование показало, что идею нужно сузить. Тогда был запущен кастомизированный блог на платформе WordPress, куда вручную добавляли информацию о возможностях коллективных скидок. При подписке на сайт его пользователи получали по почте рассылку с PDF-файлами о скидках.
Основательница маркетплейса Татьяна Бакальчук сначала закупила женскую одежду из Германии, затем создала сайт и запустила рекламу своего магазина на платформе Passions.ru. Бакальчук использовала каталоги Otto и Quelle, которые работали в России только через агентов, но не были представлены в сети. В отличие от агентов, которые брали около 15% комиссии, она выставила агентское вознаграждение в размере 10% и не брала предоплату.
История файлового хостинга началась с трехминутного демо-видео, которое объясняло идею и ценность будущего продукта. Оно получило множество положительных отзывов и набрало миллионы просмотров, что помогло привлечь инвесторов.
В 2009 году Ян Кум и Брайан Эктон решили создать мобильную телефонную книгу, которая бы показывала статус контакта: доступен, занят, на совещании и так далее. Контакты пользователей этой книги получали соответствующие всплывающие уведомления. Однако вскоре они стали использовать статусы для общения. Тогда создатели выпустили новую версию WhatsApp с функцией отправки сообщений.
Типы MVP
Существует несколько основных подходов к созданию MVP. В зависимости от этого выделяют несколько типов такого продукта.
Волшебник страны Оз использовал трюки, чтобы притворяться тем, кем он на самом деле не был. То же можно сказать о данном типе MVP. Продукт только кажется функциональным, но на самом деле его разработчик делает всю работу вручную. Это нужно для того, чтобы проверить саму концепцию продукта и понять, востребован ли он. Так развивался сайт заказа обуви Zappos. Изначально у авторов идеи не было ни склада, ни закупленных партий товара, а существовал лишь сайт с фотографиями обуви. Когда ее начали заказывать, разработчики обновили функциональность сайта.
Продукт работает по тому же принципу, что и в случае с Волшебником страны Оз: изначально все работы выполняются вручную. Однако клиенты при этом осознают, что за товаром или услугой стоит человек. Сотрудники службы финансового планирования и инвестиций Wealthfront изначально общались напрямую с клиентами, которым нужна была помощь в управлении капиталом, а автоматизированная система появилась позднее. Такой тип MVP помогает сформировать план развития продукта и собрать фидбэк от целевой аудитории.
Цель такого типа продукта состоит в том, чтобы донести до клиентов ценность использования существующих инструментов вместо создания уникального решения. Его используют, чтобы проверить и реализовать идею без разработки уникального программного обеспечения. Так начал работать Groupon. Создатели начали с сайта на WordPress, где все взаимодействие с пользователями осуществлялось по электронной почте. Лишь позднее сервис дополнили социальными функциями, полноценной email-рассылкой и мобильным приложением.
Это рабочий продукт с минимальным набором функций, которые нужно проверить. Такой тип MVP позволяет сформировать целевую группу, получить обратную связь и проанализировать ее, а также провести тестирование функциональности.
Этапы создания MVP
Чтобы создать успешный продукт, потребуется детальный план его развития. Предварительно нужно подтвердить базовые принципы и методы MVP. Команда должна следовать им на протяжении всего процесса. При этом нужно стремиться потратить как можно меньше денег и усилий.
Выделяют несколько этапов проверки идеи и превращения ее в продукт.
Идея MVP отвечает концепции «бережливого стартапа». Главная цель создания заключается в тестировании концепции или продукта на рынке. Именно по его итогам бизнес может принимать решения о выпуске. Автор методики развития клиентов Стив Бланк говорит, что главная причина провала успешных по многим показателям проектов — это недостаточное знание своих клиентов. Это подтверждает и исследование CB Insights, согласно которому в 42% случаев причиной провала стартапа становится отсутствие рыночного спроса. Создание MVP позволяет понять потребности аудитории на ранних стадиях развития продукта и не выпускать на рынок товар или услугу, которая не будет пользоваться популярностью.
MVP подходит не только для стартапов, но и при разработке решений на предприятиях. Зачастую разработка нового продукты достаточно сложна, а изменения сопряжены с серьезными рисками. Концепция Minimum Viable предполагает небольшие и постепенные изменения, которые достаточно безопасны и позволяют внедрять функции или обновления, не доставляя неудобств клиентам.
Секрет успешных стартапов. Minimum Viable Product: что это, и как его создают
MVP — это не только лучший игрок в команде (most valuable player). В сфере стартапов это ещё и минимально жизнеспособный продукт (minimum viable product). Сервис, обладающий достаточными качествами для того, чтобы привлечь первых пользователей.
Это очень важно в условиях, например, стартапа — для получения обратной связи и понимания того, в какую сторону стоит двигаться (и стоит ли двигаться вообще, или лучше похоронить идею).
Сбор информации через MVP — обходится намного дешевле, чем разработка полноценного продукта с большим набором функций. MVP позволяет во много раз снизить затраты и риски, и, при грамотном подходе, в итоге выйти на бизнес-идею, которая работает.
Для примера, возьмем онлайн-планировщик. Сразу мечтать о создании конкурента ToDoist или Trello — нет смысла. На такое не хватит никакого бюджета, и даже с неограниченными финансами (см. Google) победа не обеспечена. Поэтому в соответствии с теорией MVP-тестирования нужно создать основу, «костяк» продукта. Например, простой сервис, способный записывать новые задачи и отмечать их как сделанные, с тегами, возможностью фильтрации и выставления приоритетов.
Когда хорошие стартапы задумываются о выпуске планировщика, они обычно начинают с этого короткого списка. А дальше всё зависит от дизайна, маркетинга и пары-тройки выделяющихся функций. Если пользователям понравится — можно развивать идею, добавлять возможности и постепенно становиться одним из главных игроков. Если MVP себя оправдал.
Термин «минимально жизнеспособный продукт» был придуман Фрэнком Робинсом в 2001 году. И популяризован Эриком Рисом, который в 2009-м в деталях описал его в своём бестселлере Lean Startup (на русский его перевели как «Бизнес с нуля»).
Как видим, концепт родился сравнительно недавно. В России о том, что такое МВП, и о его принципах почти не знают. К большому сожалению, у нас больше укрепились модели «выйдем и сразу всё захватим!», где компании прожигают сотни миллионов, стараясь сразу стать монополистом. А также модели «Яндекса», Mail.ru и «Сколково», когда новые идеи подводят под технологические цепочки существующих крупных компаний. Мы в Rubrain занимаемся разработкой MVP для стартапов из США и Британии уже около пяти лет, и знаем, что если у вас мало денег (и они свои) — это единственный путь к созданию успешного проекта.
Почти все успешные стартапы на Западе начинают свой путь к успеху с минимально жизнеспособного продукта. Это наименее опасный и затратный подход, об этом хорошо знают жители Кремниевой долины. Другой вариант — «откол» проекта от более крупной компании, или разработка большого продукта после привлечения солидных инвестиций (зачастую — от сооснователей).
Но всё же большая часть известных в США и Европе стартапов начинали с простой версии MVP, которая позволила им протестировать рынок, набрать базу клиентов, освоиться, доказать инвесторам свою идею, а потом — начать добавлять в продукт новые функции и продолжить развивать успех.
Вот пять характерных примеров:
MVP отличается от раннего релиза проекта с открытым исходным кодом, поскольку релиз учитывает потребности и предпочтения пользователей, но не рассчитан на то, чтобы они напрямую определяли направление развития продукта. Видение проекта зачастую уже существует, и оно будет поддерживаться на протяжении всего жизненного цикла, несмотря на наличие прямой и косвенной обратной связи. MVP призван проверить потребность рынка, а если её нет — попробовать её создать. До вложения большого количества денег и времени.
Dropbox стал одним из характерных примеров MVP
Стив Бланк считает, что стратегия создания минимально жизнеспособного продукта может быть использована как часть методологии custdev (развития клиента). Это один из принципов движения «Бережливый стартап». Ученик Бланка Эрик Рис и сделал MVP частью дискуссии в кругах Кремниевой долины. Это самая успешная стратегия быстрого тестирования идей, получения обратной связи с клиентами и выбора жизнеспособной бизнес-модели.
Кстати, стратегию можно сделать ещё успешнее, если представлять аудитории несуществующие продукты и функции, и проверять свои гипотезы путём A/B-тестирования среди веб-пользователей. В основном стартапы, с которыми сотрудничает Rubrain, до обращения к нам именно так и поступали. А потом приходили к нам с уже оформленным планом: какие возможности должен содержать их MVP, и какие функции (скорее всего) нужно будет добавлять в их сервис или программу по мере получения одобрения от рынка.
Конечно, минимальный жизнеспособный продукт имеет свои недостатки. Первый, очевидный — срезание углов не в тех местах. Конечно, целью является создание сервиса с минимумом затрат, и только самыми ключевыми функциями. Но некоторых затрат всё равно не избежать. А некоторые вещи урезать нельзя.
В первую очередь это касается пользовательского опыта. Хороший UX — вещь обязательная. Без него весь MVP может показывать, что проект «не взлетает» и не оправдывает ожиданий аудитории. В то время как проблема состоит только в UX, а весь остальной продукт работает вполне достойно.
Другая проблема MVP — состоит даже не в таком продукте, а в подходе, который иногда с ним ассоциируют. Рид Хоффман, основатель LinkedIn, как-то сказал: «Запуститесь так рано, чтобы вы были опозорены своим 1.0 релизом». Конечно, он имел в виду, что это потом заставит вас работать сильнее. Но такая стратегия приносит больше вреда и компании, и её пользователям. MVP — это, наоборот, продукт, за который не стыдно. Пусть по нему видно, что он бюджетный, но он показывает потенциал. И не отталкивает, а привлекает аудиторию.
Мы в Rubrain не раз замечали, что для многих команд главная проблема с разработкой MVP заключается даже не в самом проекте, а в отношении к нему. Они используют не тот подход. Идея MVP в том, чтобы это был процесс создания крутого продукта. Первый жёлтый кирпичик по дороге в Изумрудный город. Вместо этого разработчики рассматривают MVP как отдельную цельную вещь, и не уделяют должного внимания сбору данных или анализу аудитории. Которые потом позволили бы скорректировать продукт и сделать его успешным. Они выпускают такие MVP, которые скорее похожи на прототипы или концепты. И слишком сосредоточены на своей изначальной идее, даже если рынок намекает на её несостоятельность.
Из-за ловушек сознания, к которым иногда может привести MVP, в последние годы появилась другая идея. Некоторые стартапы теперь ставят своей целью не Minimum Viable Product, а Minimum Valuable Product (MVaP). Минимальный ценный продукт. Так становится проще напоминать себе и команде, что задача — не выпуск какой угодно вещи при низких затратах. А создание продукта, который несёт в себе какую-то ценность для пользователей. И позволит вам набрать изначальную аудиторию, поведение которой потом можно будет анализировать.
MVaP ставит в приоритет своих пользователей, их потребности и ожидания. Проводит исследования, анализирует юзабилити, оценивает демографию, создает use cases. Всё с целью определения наилучших способов для удовлетворения запросов потенциальных клиентов.
Обычно есть несколько разных идей о том, как лучше достигнуть этой задачи. Здесь на помощь приходит тестирование прототипов. Функциональные прототипы представляются реальным пользователям, чтобы увидеть, какой вариант устроит их лучше всего. Это важный шаг в создании MVaP.
Но минимально ценный продукт должен приносить пользу не только клиентам. Он создаёт ценность и для самого проекта. Как и MVP, он обязан уметь извлекать полезную информацию о том, как продукт воспринимается рынком.
Ценность с MVaP также создаётся для бизнеса в целом. Один из рисков выпуска MVP, минимально жизнеспособных продуктов, — в том, что они могут плохо отразиться на бренде (если сделать это неаккуратно и представить «сырой» вариант). Крупная компания, от которой пользователи ждут определенного уровня, позволить себе такого не может. Поэтому для её лучше выбирать более безопасный путь — MVaP. Такой продукт часто стоит дороже в разработке, зато он гарантированно несёт в себе ценность, и позитивно влияет на имидж бренда, который он представляет. По этой стратегии с нашими программистами сейчас сотрудничают «Яндекс» и Mail.ru.
Если вы не крупная компания, и создаете буквально один из своих первых сервисов, концепт простого MVP для вас вполне подходит.
Для начала нужно определить проблему, которую продукт будет решать. И создать проект с минимальным набором функций, решающих эту проблему. А дальше — начинать учиться понимать пользователей, и улучшать свой продукт в соответствии с реальными требованиями рынка.
Идея в том, чтобы сервис проверил ваши основные предположения. Может ли это быть чем-то, чем люди интересуются? Если да, то дальше стартап может развивать свою деятельность: набирать команду, искать финансирование.
Итак, по шагам, нужно:
Раньше, на «Диком Западе» интернета, всё было попроще. Но сейчас успех стратегии MVP во многом зависит от продуманного бизнес-плана. В США для этого сейчас любят использовать канву бизнес-модели. Этот полезный инструмент был предложен в 2005 году Александром Остервальдером, швейцарским предпринимателем и бизнес-теоретиком. Почитать о нём подробнее можно в интернете, для этого есть десятки специализированных сайтов. Но если вкратце, такая канва позволяет на одной странице описать все основные бизнес-процессы компании. В том числе:
Канва бизнес-модели — простой способ прийти к тому, как должен выглядеть ваш минимально жизнеспособный продукт. В ней есть все модули, необходимые для формирования общей стратегии.
Главное — это позволяет лучше понять, на каких функциях сосредоточиться, в чём основная цель продукта, и что будет отличать его от конкурентов.
Взять, к примеру, первый iPhone. Все телефоны в то время имели ряд функций, которые Apple специально не включила в свой девайс. В нём не было функции копирования и вставки (!), не было SDK, не было 3G-связи. Даже нельзя было отправлять текстовые сообщения сразу нескольким контактам.
Но Стив Джобс знал, на чём сосредоточиться. Он представил MVP, минимально жизнеспособный продукт. С мультитачем и большим экраном. В нём были ровно те основные возможности, которые выделяли его на фоне остального рынка. На отсутствии привычных фич специально не заостряли внимание — ни публики, ни разработчиков. Аудитория этот MVP, как показывает история, приняла, и теперь, на двенадцатой итерации, в смартфоне есть все недостающие функции, и даже более того.
Если вы пока что не Стив Джобс, есть некоторые полезные сервисы для начала работы над своим первым минимально жизнеспособным продуктом:
Можно обратиться к опытной компании, предлагающей свои услуги по разработки MVP для стартапов. У неё должно хватать дизайнеров и программистов с опытом в этой сфере. Заказчики с идеей и определенным количеством денег сейчас обычно так и делают. Не обязательно искать разработчиков, решать легальные вопросы, с нуля создавать команду. Если есть хорошая идея и вариант её продвижения — найдется достаточно опытных фирм, которые возьмутся за работу за вас. Это будет намного дешевле, чем начинать с нуля, а временные затраты несопоставимы.
В следующем материале расскажем о примерах крутых идей для MVP, которые позволили основателям компаний почти из ничего создать бизнесы на несколько миллиардов.
MVP: что это такое и как работает?
Читая новости про проекты и сервисы, вы могли часто сталкиваться с понятием MVP. Но что скрывается под этой аббревиатурой и почему MVP так часто используют на начальных этапах развития продукта? Давайте прямо сейчас вместе разберемся в этом.
Что собой представляет MVP
Minimal Viable Product (минимально жизнеспособный продукт) — тестовая версия товара, услуги или сервиса с минимальным набором функций (иногда даже одной), которая несет ценность для конечного потребителя.
MVP создают для тестирования гипотез и проверки жизнеспособности задуманного продукта, насколько он будет ценным и востребованным на рынке.
Результаты тестирования минимально жизнеспособного продукта и обратная связь от целевой аудитории помогают понять, стоит ли развивать проект дальше, какие изменения следует внести в стратегию, а что оставить в первоначальном виде.
В 2008 году, когда аренда отеля или жилья во время путешествия была большой проблемой, два энтузиаста решили подойти к вопросу нестандартно и сдали свою квартиру по простому факсу. По сути, это тоже MVP, в котором тестировалась основная функция. Эксперимент показал, что продукт получит спрос, а сегодня Airbnb — одна из крупнейших площадок по поиску краткосрочной аренды жилья.
MVP и PoC — одно и то же?
Proof of Concept (PoC) — доказательство правильности концепции и некоторые новички часто путают его с минимально жизнеспособным продуктом. PoC описывает процессы выяснения технической жизнеспособности концепции программного обеспечения (или любого другого продукта).
Да, эти определения взаимосвязаны, но не взаимозаменяемые. Proof of Concept — описание процессов на начальной стадии развития продуктов, которые потом реализуются фактически, из чего получается MVP.
Виды MVP
Есть много разных подходов к созданию минимально жизнеспособного продукта, но на практике чаще всего используют некоторые из них. Далее поговорим о наиболее популярных.
MVP Флинстоуна
Помните, как в популярном мультике «Флинстоуны» глава семейства создавал иллюзию передвижения на автомобиле? Так вот, этот подход предусматривает имитирование наличия функционала, хотя на самом деле технически он никак не реализован. MVP нацелен на проверку гипотезы, доказательство жизнеспособности выбранной модели развития бизнеса.
Он сделал сайт и опубликовал фото разных моделей обуви. Получил заказ, пошел в магазин, приобрел нужную пару и отправил покупателю. Так он проверил жизнеспособность идеи продаж обуви через интернет, при этом изначально он не тратил деньги на аренду склада и закупку продукции, а лишь имитировал их наличие.
Консьерж MVP
Эта методология больше подходит для онлайн-сервисов, конечная цель которых — автоматизировать решение проблем целевой аудитории. На начальных этапах реализации продукта услуга оказывается вручную.
Например, мы хотим сделать сервис по финансовому учету и планированию для физических лиц. Но чтобы проверить, будет ли пользоваться спросом эта идея, сначала сделаем несколько финансовых планов для клиентов вручную через Excel. Так мы сможем понять, кто и сколько готов платить, какие функции нужно реализовать в первую очередь и т.п. Часто консьерж MVP помогает в генерации новых идей, которые впоследствии делают конечный продукт лучше.
Эту модель в конце 90-х годов использовал Чак Темплтон — основатель сервиса по онлайн-бронированию ресторанов, билетов и многого другого. Он не стал сразу вкладывать сотни тысяч долларов в техническую реализацию сервиса, а бронировал для других людей столики в ресторанах вручную. Так он проверил жизнеспособность идеи, понял, кто, сколько и за что готов платить и познакомился с целевой аудиторией.
Разрозненный MVP
Метод разрозненного MVP используют, когда идею можно проверить и реализовать без разработки уникального программного обеспечения. Вместо этого собирают готовые инструменты, объединяют в одну систему и преподносят в едином интерфейсе.
Если бы все компании начинались с разработки уникальных решений, которая обходилась бы в сотни тысяч долларов, мы бы не увидели много крутых проектов. К этому, как правило, переходят после запуска, получения обратной связи и первых результатов.
Посмотрите на популярный сервис совместных покупок Groupon. Когда-то он был простеньким сайтом на WordPress, где все взаимодействие с пользователями осуществлялось по электронной почте. Только после получения первой обратной связи и финансовых результатов были разработаны социальные функции, полноценная email-рассылка, автоматизация и мобильное приложение.
Продукт с одним параметром
Эту разновидность используют чаще всего, когда есть готовый продукт с минимальным набором функций (как правило, одной). По такому принципу действовали основатели Spotify, которых упомянули в начале статьи.
Выпуск продукта с одной функцией (параметром) позволяет сузить целевую аудиторию, получить обратную связь и проанализировать ее, после чего приступить к тестированию.
Когда и для чего нужно делать MVP?
Приступайте к разработке MVP на начальных стадиях развития продукта. Идея может быть крутой только у вас в голове (да, такова уж суровая реальность), так зачем сразу вкладывать большие деньги в разработку, когда есть вариант с маленькими затратами и точной проверкой? После выпуска минимально жизнеспособного продукта вы определите спрос и поймете, в правильном направлении развиваете проект или нет.
Но самое крутое в MVP — сбор ценной информации от первых пользователей. Именно конечный потребитель расскажет о правильной реализации проекта. Собранные данные используйте для планирования дальнейших обновлений и определения наиболее приоритетных целей: какие функции реализовать в первую очередь.
Как сделать MVP правильно
В теории вы узнали, что такое минимально жизнеспособный продукт, теперь поговорим о практической части — создании MVP. Для получения хорошего результата разложите работу на мелкие итерации (шаги/этапы), обозначьте цели для команды в целом и задачи для каждого члена. Но в первую очередь донесите до коллектива общие принципы работы и создания продукта.
Нулевой этап: определяем основные принципы создания MVP
Проведите общее собрание коллектива, который примет участие в разработке MVP. На нем вы должны разобраться, все ли члены команды понимают, зачем это нужно. Обсудите видение минимально жизненного продукта, сложите все воедино и постройте первый примерный план дальнейшей работы.
В ходе общего собрания обсудите следующие вопросы:
Первый этап: поиск проблемы, которую решит MVP
После определения основных принципов MVP, ответьте на вопрос: «Какую проблему решает продукт?». Опишите его ценность в нескольких предложениях. Во-первых, это полезно для себя и команды, во-вторых, в дальнейшем поможет в создании уникального торгового предложения, лендинга и рекламной кампании.
Например, создаем сервис по финансовому планированию для физических лиц. Он решает проблему «бесконтрольного расходования денежных средств, помогает организовать бюджет и ставить долгосрочные цели».
Второй этап: находим целевую аудиторию
Распространенная ошибка начинающих продактов и предпринимателей — они считают, что их проект решает проблему широкой аудитории (всех людей). Такой подход в разы повышает вероятность провала. Сфокусируйтесь на определенной целевой аудитории.
Составьте портрет клиента, который обязательно купит продукт. Опишите его пол, возраст, социальное положение, уровень дохода, потребности, привычки, используемую им технику, распространенные проблемы, предпочтения в отдыхе и т.п.
Не торопитесь на этом этапе! Лучше потратить несколько часов для формирования портрета ЦА, чем потом «слить» весь рекламный бюджет и получить минимальную конверсию. И не забывайте про то, какую проблему решает MVP (это определяется на первом этапе).
Пример с сервисом по составлению финансовых планов для физических лиц:
Третий этап: определяем основных конкурентов
Не думайте, что ваш продукт (идея) уникален и такого больше нигде нет. Если вы с ним не сталкивались лицом к лицу, это не гарантирует уникальность. И вообще есть гипотеза «множественного открытия»: все исследования и изобретения делаются сразу несколькими учеными независимо друг от друга.
Эту гипотезу подтверждает история с разработкой радио. В России считают, что его изобрел Александр Попов, а вот в Италии лавры отдают Гульельмо Маркони. Оба начали работать над реализацией идеи в 1894 году, но Попов свою разработку презентовал в марте 1896 года (но при этом не запатентовал), а Маркони в июне 1896 года подал документ на патент. Кстати, есть еще несколько ученых в разных странах, которые также претендуют на звание «создатель Радио».
История с MVP аналогичная: вы должны потратить немало времени, но постараться найти конкурентов. Вам повезет, если идея все-таки окажется уникальной, а если нет, тогда решите следующие задачи:
Для удобства советуем составлять сводную таблицу со всей собранной информацией. Впоследствии будет проще ориентироваться в больших массивах данных и принимать какие-либо решения.
Четвертый этап: проводим SWOT-анализ
SWOT-анализ представляет собой таблицу, состоящую из четырех блоков:
Не расписывайте пункты на целые абзацы. Они должны быть короткими и понятными для всей команды.
Обратите внимание, что таблица разделена на две части. Сильные и слабые стороны, как правило, относятся к внутренним факторам, а возможности и угрозы — к внешним.
Цель SWOT-анализа выявить сильные стороны и возможности, чтобы сосредоточить работу на них для минимизации негативных последствий от слабых сторон и угроз. Сделанные выводы помогут выбрать стратегию развития и позиционирования бизнеса на рынке.
Пятый этап: создаем карту пути пользователя
Простой блиц для определения удобства продукта: если вы сами не понимаете, что надо делать с вашим сервисом (продуктом, услугой и т.п.), то потребитель разобраться точно не сможет!
Чтобы избежать такого недоразумения, на пятом этапе создания минимально жизнеспособного продукта составляют карту пути пользователя — что делает пользователь при взаимодействии с продуктом. Вы должны понимать, какие у аудитории требования к контенту, дизайну, интерфейсу.
Кстати, не забывайте корректировать карту пути пользователя (user flow) после получения обратной связи от первых клиентов. Они расскажут, что хорошо, а что плохо или неудобно. На основе этого корректируйте карту, чтобы конечный потребитель получал то, что хочет.
Например, для сервиса по финансовому планированию сделали такую карту:
Шестой этап: составляем перечень функций продукта
На прошлом этапе вы определили основные взаимодействия пользователя с продуктом, теперь для каждого опишите конкретные функции. Для удобства составьте специальную карту: взаимодействия и функции для каждого. Сначала она выглядит так:
Дальше для каждого взаимодействия определяется перечень функций. Здесь помогут логика и пользовательские истории. В первом случае самостоятельно или вместе с командой подумайте, что нужно сделать для обеспечения того или иного взаимодействия.
Но как вы помните, наше видение часто искажено, а вот реальные пользователи дают объективную информацию на основе опыта. Пользовательские истории описывают те или иные действия людей, на основе которых определяются необходимые функции.
Дальше расставьте все функции по приоритету. Самые востребованные (которыми пользуются чаще всего) ставим в начало списка, редко используемые — в конец. Должна получиться вот такая карта:
Седьмой этап: определяем функции MVP
На этом этапе вы должны определить функционал MVP или иными словами — запланировать объем минимально жизнеспособного продукта. Для начала определите несколько основных функций, без которых проект вообще не сможет существовать, от него не будет никакого толку. Это — каркас или наименьшая полезная версия продукта.
Каркас как дом без отделки — вроде бы, жить можно, но как-то не очень. Поэтому в большинстве случаев MVP дополняют разными «полезностями». Для этого необходимо определить существенные и несущественные функции: какие нужны сейчас, а какие можно доработать потом в процессе развития проекта.
Опять же, классифицировать функции лучше коллективом. Обсуждения, споры, аргументация — это приведет к определению оптимального объема минимально жизнеспособного продукта. На карте выделите каркас и дополнительные функции в рамках MVP для удобства дальнейшего планирования. Должно получиться что-то наподобие этого:
Такую карту с объемом минимально жизнеспособного продукта можно сделать на компьютере или на магнитной доске, стоящей в переговорной или аналогичном помещении. В ходе разработки допускается внесение корректировок.
Восьмой этап: выберите метод управления и разработки
Вы готовы к началу работы: определена идея, задачи, цели объем MVP. Осталось выбрать модель управления для достижения максимальной эффективности и соблюдения установленных сроков разработки. Возможно несколько вариантов:
Девятый этап: проводите тестирования
Тестируйте MVP короткими итерациями: альфа- и бета-тестированием. Альфа — внутренний этап: закончили разработку, пользуйтесь продуктом внутри команды несколько дней. Если все окей, запускайте бета-тестирование — внешний этап, дайте доступ к проекту первым пользователям. Длительность: 7-14 дней.
После первой беты соберите отзывы, статистику посещений, аналитику поведений и проанализируйте весь массив данных. Так вы узнаете, что надо доработать, что можно убрать, а что, наоборот, надо добавить в срочном порядке.
Несколько итераций «разработка-альфа-бета» помогут прийти к оптимальной первой версии продукта, который можно выпускать на рынок для массового пользователя и продолжать дорабатывать.
Еще раз поговорим всю последовательность этапов:
Самые распространенные ошибки при создании MVP
Теперь вы знаете, как создать свой MVP. Но есть еще один момент: новички (им это простительно, кстати) часто допускают ошибки при планировании первых минимально жизнеспособных продуктов. На второй-третий раз, набравшись опыта, они работают быстрее и эффективнее.
Но зачем учиться на собственном опыте, когда есть чужой? Почему бы не использовать его и постараться избежать неточностей на своем пути? Поэтому далее поговорим о самых распространенных ошибках начинающих продакт-менеджеров и предпринимателей.
Попытки достигнуть идеала
Закройте в клетке своего перфекциониста, потому что в ходе разработки MVP он сыграет с вами злую шутку! Запомните, задача минимально жизнеспособного продукта — дать пользователю базовое представление о продукте, он априори не должен и не может быть идеальным.
Вы тестируете гипотезу! Поверьте, маленького MVP хватит для определения потенциала идеи. Если она крутая, то спрос на продукт не испортит даже плохой дизайн, интерфейс и минимальная скорость работы. И только при подтверждении этой гипотезы начинайте тратить ресурсы на юзабилити и красивый фантик.
Небрежная работа
Если MVP не должен быть идеальным, это не значит, что его можно делать, как попало. Некоторые продакты бросаются из крайности в крайность, в результате получает вообще что-то непонятное.
Минимально жизнеспособный продукт должен быть простым, но качественным. Например, если делаете сервис, то купите хотя бы домен второго уровня, не надо оставлять его на поддомене какого-то бесплатного конструктора.
Отсутствие обратной связи
Некоторые новички так увлекаются разработкой, что забывают о приоритетной цели — сборе обратной связи. Еще на стадии планирования следует определить ключевые метрики, которые покажут успешность проекта. Это может быть количество скачиваний или покупок, число новых пользователей, коэффициент удержания клиентов и т.п.
«Пустые» обещания
Когда «глаза горят», есть ощущение способности свернуть горы! И в такие моменты руководитель начинает делать анонсы крутых и необычайных возможностей. Конечно, это все здорово с точки зрения маркетинга, но если не сдерживать обещания, пользователи начнут покидать проект.
Поэтому всегда принимайте решения о новых анонсах на «холодную» голову. Объективно оценивайте, что сможете сделать, а что нет.
Отказ от анализа и аналитики
Окрыленность собственной идеей часто дурманит разум и вся команда перестает обращать внимание на объективные факты: плохие метрики, отрицательные отзывы и т.п. Начинают думать, что просто пользователи не все понимают сейчас, а вот когда финальная версия продукта будет готова, тогда они оценят.
Нет, не оценят. В этом деле всегда важен объективизм. Есть обратная связь от реальных пользователей, слушайте ее, корректируйте работу проекта в соответствии с желаниями конечных потребителей, иначе во всей этой суете нет никакого смысла.
Итак, подведем краткий итог: MVP — минимально жизнеспособный продукт, который делают для тестирования идей и гипотез, сбора обратной связи от первых потребителей (и да, MVP ≠ PoC). Реализовать можно за 10 этапов и постараться избежать наиболее распространенных ошибок. Если вы планируете создание нового продукта, начинайте с MVP: это позволит избежать больших ресурсных потерь в случае плохого потенциала идеи.