Практические примеры MVP для проектов, продуктов и фичей

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

Любой продакт менеджер знаком с идеей MVP. Если в двух словах, там все довольно интуитивно:

В теории все просто. Но почему все еще так много запаздывающих проектов, которые вкладывают так много времени и усилий во что-то, куда пользователи не вовлекаются? Корень проблемы в определении того, что есть «минимального» продукт. Менее опытные продакты обычно уже имеют в голове картинку продукта или фичи и следуют ей. Более опытные на каждом шагу спрашивают себя: "А можно ли это уменьшить? Могу ли я сделать фичу меньше, сохранив при этом суть?» Чем синьорнее менеджер продукта и чем сложнее его проукты, тем чаще ответ на этот вопрос положительный.

Давайте посмотрим на Groupon. Они заработали свое состояние на том, что связали бизнес с клиентами с помощью больших скидок. Например, спа-салон в моем районе предлагает мне хорошую такую скидку в 50% на первое посещение - грех не сходить в сауну, почти халява! Это работает и для салона: еще один лид, потенциально преобразованный в постоянного клиента после пробного посещения.

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

Основатель проекта Эндрю Мейсон начал с простого блога WordPress, где он каждый день публиковал «предложения». Когда кто-то проявлял интерес, он вручную генерировал купон в формате PDF и отправлял его по электронной почте. Не было никаких сложных технологий, никаких платежей, только простой блог и несколько самодельных скриптов. Они стали вкладываться в сложность только после того, как поняли, что есть отклик. Это радикальный подход MVP в действии — они отсекли почти все!

Что могло бы пойти не так? Например, они могли бы вложиться в сложную систему маркетплейса и двухуровневые скидки, интеллектуальное ранжирование с помощью ML, AI-описания и другие навороты, и после двух лет разработки они бы поняли, что:

К счастью для Groupon, у них был умный (и не имеющий средств) основатель, который начинал с малого.

Это был MVP компании. Если присмотреться, мы увидим, что он состоит из списка фич (веб-сайт, купон, метод погашения и т.д.) и решений, принятых для каждой из них. Например, для веб-сайта основатель мог бы избрать большой путь (создать приложения Android и iOS сразу) или маленький (блог WordPress). Это подводит нас к следующей теме.

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

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

Посмотрим внимательно на первые два шага Customer Journey Map. Они состоят из нескольких процессов (регистрация, поиск, избранное), каждый из которых имеет несколько фич: регистрация по электронной почте, Google и X). Мы можем (и должны!) применить подход MVP для каждой фичи.

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

Если вы думаете: «Тоже мне проблема! Это займет у разработчиков пять минут» — то это не вполне корректно. В сложных проектах с широкой сетью микросервисов добавление еще одной базы данных (для хранения писем и паролей), системы уведомлений (для отправки писем с подтверждением) и двух внешних интеграций (с API Google и X) — это никак не пять минут. Это может занять месяцы для компаний среднего размера и год-два для гигантов вроде Amazon.

Так что убираем сложность и оставляем только регистрацию по электронной почте. И движемся дальше!

Продакта с MVP-подходом уже не остановить! Что "порежем" дальше? Нам правда нужно Избранное? Ничего не хочу сказать, это полезная фича, но она имеет свою цену: время и усилия.

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

Хотите еще потренироваться убирать лишнее из MVP? Обратите внимание на симуляторы ProductDo, в данном случае на "Основы продакт менеджмента". Там надо будет строить MVP кейса аренды одежды и самому принять решения по каждой фиче, а потом и считать экономику, оценивать рынок, ставить OKRы - и все самому, на задачках.

Мы посмотрели, как сделать MVP всей компании более «минималистичным», удалив ненужные фичи. Ту же концепцию можно применить и к самой фиче!

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

Подход MVP дошел до своего предела? Нет!

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

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

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

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

#productmanagement #product #продактменеджмент #продукт #mvp