Как определить объем MVP за 3 часа

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

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

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

Обзор варианта использования

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

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

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

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

Решение о дизайн-спринте

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

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

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

Процесс разработки MVP

Подготовка

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

Затем создайте презентацию для дизайнеров и инженеров. Это должно объяснить:

• Проблема, которую вы пытаетесь решить.
• Продукт, который вы создаете.
• Как продукт решит эту проблему с точки зрения метрик и UX.
• Прогнозируемое влияние продукта на ваш бизнес и бизнес вашего клиента.
• Миссии, цели и ключевые результаты (OKR) на уровне компании и команды, а также то, как продукт помогает выполнять эти миссии и достигать этих OKR.

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

Трехчасовая стартовая встреча

В стартовом процессе должна участвовать вся команда разработчиков, что позволит им участвовать в каждом этапе процесса, от идеи и создания истории до разработки концепции MVP. Сюда входят старшие, младшие и младшие менеджеры по продуктам; владельцы продукта; продуктовые лиды (если применимо); UX-дизайнеры; инженеры-программисты; и QA-инженеры.

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

Соберите всех в конференц-зале или виртуальном рабочем пространстве. В нашем случае нас было 10 человек. Заблокируйте три часа.

Продукт и путь пользователя (60 минут)

1. Проведите презентацию. (15 минут)

2. Начните идентифицировать всех пользователей вашего продукта. Даже если вы еще не определили какие-либо потоки или функции, вы можете определить количество потоков, которые необходимо создать. (10 минут)

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

   Пример использования: у нас было три персонажа: менеджер магазина (или администратор), кассир и конечный покупатель. Были и другие потенциальные персоны старшего уровня, такие как владелец магазина, но для целей MVP они могли быть покрыты администратором.

3. Составьте карту пути пользователя от начала до конца. Назначьте цвет каждому персонажу, чтобы помочь определить каждый шаг потока, с которым столкнется пользователь. Для личных встреч разместите стикеры на стене или используйте белую доску. Для виртуальных встреч используйте доску FigJam или что-то подобное. (35 минут)

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

   Пример использования: Вот список функций нашего кассира:

   • Откройте приложение торговой точки.
   • Войдите, используя PIN-код.
   • Определите первый товар для покупки клиентом.
   • Определите количество товара.
   • Определите любые дополнительные элементы для покупки клиентом.
   • Добавьте скидку на товар (если применимо).
   • Суммарная стоимость всех товаров в корзине (в этот момент отображается полная стоимость покупки, включая налог с продаж).
   • Полная проверка и обработка платежей.
   • Подтвердите покупку.
   • Разрешить клиенту добавить чаевые.
   • Закрыть продажу.
   • Показать сумму всех ежедневных продаж.
   • Получите тайм-аут после заданного периода бездействия (например, пять минут).

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

   

Основные характеристики пути пользователя (45 минут)

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

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

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

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

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

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

Дизайн продукта, тестирование и разработка (75 минут)

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

2. Позвольте специалистам по продукту и дизайнерам поработать вместе над небольшим UX-тестированием каркасного дизайна. (15 минут)

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

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

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

Результаты и основные выводы

До наших усилий наше приложение представляло собой клавиатуру с цифрами от 0 до 9, десятичной точкой и кнопкой зарядки. Из-за этого ограничения и созданного им неэффективного рабочего процесса в течение года наше удержание было низким — около 20%. Хотя мы привлекали новых пользователей быстрее, чем наши конкуренты, мы теряли их почти так же быстро.

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

1. Загружайте предметы в инвентарь прямо с мобильного устройства, просто используя камеру, вводя имя и цену.
2. Выберите эти товары и добавьте их в корзину покупателя.
3. Закройте продажу, просматривая продаваемые товары.
4. Смотрите количество товаров, проданных за определенный период времени.

Клиентам понравился улучшенный продукт. Уровень удержания составил 45% среди новых пользователей, которые воспользовались функциональными возможностями каталога для оформления заказа не менее пяти раз в течение первой недели после загрузки товаров.

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

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

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

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