Имея возможность спроектировать и создать MVP за 30 дней, я многому научилась и поняла, с какими функциями следует начинать.
За последние несколько лет концепция запуска MVP (Minimum Viable Product) стала очень популярной и теперь является обычной практикой как для стартапов, так и для существующих компаний. Но, как и в случае с большинством концепций, получивших статус достойных внимания, возникает много путаницы. Есть стойкие сторонники, стойкие скептики и множество людей, которые просто разбрасываются этим термином, не зная, что он означает.
Общая идея MVP заключается в том, что вы должны создавать наименьшее количество своего продукта, из которого люди получают ценность, а затем добавлять к нему дополнительные функции. Сторонники MVP утверждают, что сначала создание наименьшего количества позволяет вам узнать, какие дополнительные вещи действительно нужны людям, чтобы вы не тратили свое время на создание набора функций, которые никто не использует.
Тем не менее, скептики MVP утверждают, что в действительности MVP просто становятся набором паршивых продуктов, у которых недостаточно функций, чтобы быть полезными или привлекательными. Эти дебаты привели к тому, что люди с обеих сторон придумали еще более забавные аббревиатуры, такие как «минимально ценный продукт», «минимум привлекательный продукт» или мой личный фаворит
Определите свое самое рискованное предположение и проверьте его
Запускайте свинью нужна максимальная скорость обучения за счет минимизации времени, чтобы попробовать что-то новое. Не просто минимизировать. Резко минимизировать. Даже с такими сложными идеями, как Google Glass, они построили первый прототип за 1 день!
Выявление лежащих в основе предположений требует много умственной энергии и дисциплины. Сформулируйте возможность как проблему клиента и работайте в обратном направлении. Что должно быть правдой, чтобы возможность существовала? Теперь возьмите каждое из этих предположений и спросите, какие основные предположения стоят за ними ? Повторяйте, пока не дойдете до основных предположений. Это похоже на 5 Почему . Продвигаясь снизу вверх, найдите доказательства, подтверждающие каждое предположение. Теперь у вас должно быть четкое представление о критических пробелах в ваших знаниях. Четкое представление о том, какими должны быть ваши самые рискованные тесты предположений.
Идея MVP — это просто концепция эволюции. Вещи начинаются с малого, а затем со временем развиваются. Например, школы, продуктовые магазины и города начинались как небольшие MVP по сравнению с тем, во что они превратились сегодня. Таким образом, вопрос о том, должны ли мы сначала сделать первоначальную уменьшенную версию нашего продукта, а затем добавлять к ней со временем инструменты это не должен обсуждаться. Конечно же, вы хотите сделать свой продукт лучше после того, как запустите его! В начале пути мы должны тратить время на то, чтобы выяснить самую сложную часть всей этой концепции и только после приступать к доработке.
КАКИЕ ФУНКЦИИ ДОЛЖНЫ БЫТЬ ЧАСТЬЮ НАШЕЙ ПЕРВОНАЧАЛЬНОЙ ВЕРСИИ, А С КАКИМИ СЛЕДУЕТ ПОДОЖДАТЬ?
Есть три вещи, которые делают этот вопрос таким сложным.
1) Мы не знаем, какие функции действительно понравятся нашим клиентам, пока они не начнут использовать продукт.
2) Люди по своей природе нетерпеливы и хотят всего и сразу. Дайте мне все функции! и
3) У нас мало практики в этом. Даже опытные предприниматели и дизайнеры приложений не выпускают MVP каждый день. Вместо этого они в основном сосредоточены на улучшении того, что у них уже есть.
Давайте разберем детальней
Шаг 1: Создайте историю для своего приложения.
Начните с записи основной проблемы или проблем, которые ваше приложение будет решать, а затем перечислите все шаги, которые человек должен предпринять на пути к преодолению этих проблем.
Шаг 2. Перечислите полезную информацию на каждом этапе
После того, как вы запишете путешествие в виде ряда точек принятия решений, ваша следующая задача — выяснить каждую часть информации, которая поможет кому-то сделать следующий шаг в своем путешествии.
Шаг 3: Создайте список всех возможных функций
В конце шагов 1 и 2 у вас должен быть длинный документ (или куча стикеров) с набором точек принятия решений и всей соответствующей информацией, которая понадобится людям, чтобы упростить принятие этих решений. Этот документ послужит идеальным источником вдохновения для создания списка всех возможных функций вашего приложения. Просто превратите эти действия и информацию в конкретные функции.
Шаг 4: Отметьте критически важные функции
Теперь, когда у вас есть полный набор функций (или настолько полный, насколько это возможно, без передачи вашего приложения в руки вашей аудитории), начните с отметки тех, которые являются критически важными. Эта функция на 100% необходима для завершения шага в путешествии?
Шаг 5. Улучшите свое приложение с помощью функций Easy Win
После того, как вы решили, какие функции необходимы на 100%, ваш продукт должен быть на том этапе, когда кто-то, использующий его, сможет, по крайней мере, выполнить основные задачи, поставленные вашим приложением (хотя, вероятно, очень некачественно). Теперь самое интересное. Вы должны выбрать все функции, которые облегчат работу ваших пользователей. Эти функции будут напрямую связаны с полезной информацией из шага 2, которая нужна людям для принятия этих решений.
Для того, чтобы определиться с рисковым предложение, задайте себе следующие вопросы:
- Легко ли реализовать эту функцию?
- Будут ли люди действительно использовать его так часто?
- Принесет ли это пользу вашим первым пользователя или это полезно только при большом количестве пользователей?
Если они вызывают какие-либо опасения по любому из этих вопросов, перенесите эту функцию в будущую версию.
ПОРА ЛИТЕТЬ!
После того, как вы завершили шаг 5, у вас должно быть четкое представление о том, какие функции должны быть в вашем MVP, а какие следует перенести на будущем. У вас также будет четкий список функций, которые вы можете добавить, чтобы легко превратить ваше приложение из минимально жизнеспособного в минимально привлекательное. Сколько из этих маленьких шагов вы сможете сделать до запуска, зависит от вашего бюджета, сроков и того, насколько простота в использования важна для вас и вашей команды.
Но дело не в том, чтобы зацикливаться на чем является ваш продукт MVP или MLP. Дело в том, что теперь у вас есть отличный список приоритетных функций, которые должны служить планом на будущее. Вы делаете фичи не только потому, что считаете их крутыми. Вы создаете лучшую первую версию своего продукта, которая привлечет наибольшее количество первых пользователей, создаст ощущение импульса и, в конечном счете, даст вам наилучшие шансы на успех.
Какое приложение вы собираетесь сделать сегодня?