Создание MVP
Product manager c 0 до Junior за 9 месяцев
Minimum Viable Product — способ проверки бизнес-идеи, и одновременно основа для создания полноценного цифрового продукта. Как избежать ошибок при создании MVP, на что необходимо обратить внимание, какие элементы не являются критически важными на данном этапе — все это мы разберем в данном материале.
Как создание MVP помогает бизнесу
Основная задача MVP — проверить бизнес-идею и запустить циклы последовательного тестирования гипотез. Это позволит проверить жизнеспособность идеи, доработать ее в соответствии с реальными потребностями рынка и выявить спрос.
Потребители начинают использовать минимальную версию вашего продукта, которая помогает «закрывать» их потребности — и именно это показывает, что MVP полезен рынку и имеет шансы стать полноценным бизнесом.
Обратная связь от пользователей помогает понять реальную потребность целевой аудитории и выпустить востребованный продукт. В противном случае фаундер рискует потратить деньги и время на то, что никому не нужно, зачастую создавая все новые и новые надстройки для решения огромного количества несуществующих проблем.
В итоге исправление подобного продукта до состояния, когда он решает хотя бы одну конкретную проблему, может стоить дороже, чем разработка аналогичного проекта с нуля.
В чем преимущество MVP-подхода к разработке? С его помощью вы сможете:
- Проверить идею за небольшие время и деньги;
- Обкатать идею на бета-тестерах и собрать обратную связь;
- Привлечь инвестиции на самой ранней стадии (инвесторам интересно увидеть рабочий продукт, а не «влажные фантазии»);
- Показать руководству ценность идеи;
- Провести процесс трансформации в крупной корпорации поэтапно и с минимальными рисками.
MVP-подход также применим в корпорациях. Если запланировано введение инноваций, можно попробовать оптимизировать не весь процесс производства, а начать с малой его части. Это позволит собрать обратную связь от пользователей на каждом этапе, увидеть слабые места и улучшить их.
Для того чтобы MVP вышел действительно жизнеспособным, необходимо до начала проектирования и разработки четко определиться, какие конкретно задачи решает продукт и в чем его преимущество перед существующими способами.

Как определить минимальный набор функций для первой версии продукта
Существует определенная методика, следуя которой можно определить минимальный функционал продукта, создав на его базе техническое задание для разработчиков:
- Четко сформулируйте проблему, которую решает ваш продукт. Не стоит пытаться решить много задач одновременно. Сконцентрируйтесь на одной, максимум — двух задачах.
- Опишите вашу целевую аудиторию. Максимально детализируйте данные, чем больше их, тем лучше. Желательно опираться на конкретных людей, которые могут стать вашими первыми бета-тестерами.
- Подтвердите существование проблемы. Пообщайтесь с потенциальными пользователями. Возможно, проблема, которую вы хотите решить, существует только в вашем сознании. Как вариант, используйте для этого методологию Customer Development.
- Убедитесь, что ваш продукт действительно решает описанную проблему.
- Поищите аналоги. С очень большой долей вероятности они уже существуют. Обязательно проверьте подборки проектов на зарубежных сайтах (например, betalist.com, producthunt.com).
- Сформулируйте гипотезы. Старайтесь делать это таким образом, чтобы их можно было измерить.
- Определите минимальный набор функций. На этом этапе очень важно заложить только тот функционал, который позволит проверить сформулированные гипотезы.
- Обозначьте критерии успеха. Это позволит вам двигаться к осязаемой цели и понять, что вы ее достигли и продукт можно масштабировать или наращивать функционал.

MVP – минимально жизнеспособный продукт – этот термин прочно укоренился в нашей голове как один из столпов IT-индустрии и современного предпринимательства. Войдя в обиход в начале 2000, сейчас он встречается в абсолютном большинстве статей о создании продукта, вакансий в области управления в IT и, хочется верить, активно применяется как подход к построению бизнеса. Итак, этот зверь должен обладать минимальным достаточным набором функций, чтобы проверить гипотезы, на которых планируется строить и развивать что бы то ни было. Вот в этом “что бы то ни было” кроются интересные факты, ведь если посмотреть вокруг, MVP, как подход к делу, можно найти в абсолютно разных, порой никак не связанных с IT, сферах.
Кинематограф
В случае с кинематографом, режиссер не может позволить себе двигаться итеративно и постепенно усложнять сцены, у него есть только один выстрел. Поэтому ему на помощь приходит раскадровка и аниматик. То есть все сцены рисуются в виде комикса, передавая все детали и ракурсы, а далее при необходимости все это анимируется. Главная цель такого процесса – синхронизировать видение команды и оптимально спланировать производство. Чем не динамичный прототип?
Пошив одежды
Некоторые продукты могут быть настолько персонализированы, что должны быть четко подогнаны под нужды пользователя, а исправление ошибок “на живую” будет слишком дорогим. Так, например, происходит при пошиве одежды. Сначала создается макет изделия из дешевой ткани, затем он подгоняется до идеального состояния и только после этого начинается сам пошив. Семь раз отмерь, один отрежь, как говорится.
В 2009 году Ян Кум и Брайан Эктон решили создать мобильную телефонную книгу, которая бы показывала статус контакта: доступен, занят, на совещании и так далее. Контакты пользователей этой книги получали соответствующие всплывающие уведомления. Однако вскоре они стали использовать статусы для общения. Тогда создатели выпустили новую версию WhatsApp с функцией отправки сообщений.

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

Заключение
Теперь резюмируем основные мысли. Для нас MVP – это прежде всего путь к созданию идеального продукта. Основными движущими силами на этом пути являются следующие желания:
- протестировать продуктовую гипотезу;
- минимизировать человекочасы, потраченные на разработку;
- минимизировать потраченные средства;
- доставить продукт первым последователям как можно быстрее;
- получить как можно больше информации о пользователях и рынке.
Чтобы пройти этот путь максимально эффективно, нужно идти от общего к частному:
- определить глобальное видение вашего продукта и его основную ценность;
- определить вашу целевую аудиторию и выделить из нее потенциальных первых последователей и евангелистов;
- выделить самую острую под-проблему, волнующую ваших первых пользователей, которую вы можете решить минимальными усилиями, и сформировать необходимый для решения этой под-проблемы набор функций;
- создать первую версию вашего продукта, выбрав максимально подходящий под ваше предложение тип MVP;
- настроить петлю обратной связи с вашими пользователям.
В результате вы выйдете на рынок с продуктом, у которого:
- достаточно ценности – то есть люди готовы за него платить;
- есть очевидные плюшки в будущем – люди буду к вам возвращаться;
- настроена обратная связь – вы понимаете, как его развивать.
Если ваша первая версия передает лишь ключевую ценность продукта – вы получаете право на ошибку, которая вас не разорит. Цель создания MVP не попасть сразу в самое яблочко, а максимизировать обучение и не пойти по неправильному пути. MVP всегда приходит к одному из двух концов: состояние product/market fit или понимание, что ваш продукт бесполезен.
Не бойтесь быстро провалиться и продолжайте тестировать, ведь именно так вы можете найти самую выгодную идею вашей жизни!

Спасибо за внимание ❤️
Домашнее задание:
Найдите в интернете любой пример MVP
Опубликовать вариант в "комментариях" под постом.
Не боимся делать ошибки, т.к мы только учимся.
😱 Дедлайн ДЗ: Пятница (29.04) до 12:00