Продуктовый подход + MVP: как быстро адаптироваться к изменениям рынка

Зачем нужен продуктовый подход: акцент на пользователях и быстрая реакция на перемены

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

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

«Такой подход позволяет гибко реагировать на рыночные трансформации: разработать небольшую часть продукта намного быстрее, чем продумывать сразу все функции. Обновления выпускаются каждые 2–4 недели, что помогает клиентам практически молниеносно откликаться на внешние изменения. Это особенно важно в турбулентные времена, когда появляются новые технологии, темпы разработки растут, выдерживать конкуренцию на рынке становится сложнее», — комментирует Марина Кошелева, Head of Digital в ONY.

Стремление адаптировать решения под потребности пользователя помогает создавать и развивать прорывные продукты. Так, к примеру, разрабатывался Telegram, который сначала был просто мессенджером, а потом стал постепенно обрастать все новыми возможностями. Или Airbnb — сперва команда проекта создала самый простой сайт с фотографиями квартир, чтобы оценить спрос на новый формат краткосрочной аренды, и только потом приступила к разработке полноценной платформы.

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

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

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

Кейс Dantone Home

Как быстро создать MVP: гипотезы, исследования и снова гипотезы

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

Шаг 1. Сформулировать гипотезу и провести исследование

В первую очередь нужно определить, какие гипотезы предстоит проверять с помощью MVP. А чтобы выдвигать гипотезы, понадобится изучить потребности аудитории: провести качественные и количественные исследования, организовать юзабилити-тестирование продуктов конкурентов, проанализировать ситуацию на рынке, тренды.

Гипотезы нужно будет проверить — значит, потребуется определить ключевые показатели эффективности. В этом помогут метрики, они покажут, насколько успешным был запуск.

Выбор метрик зависит от задачи, но чаще всего команды опираются на:

• разные показатели конверсии в воронке, к примеру, какой процент пользователей переходит в корзину, или сколько из тех, кто положил товар в корзину, купил его;
• разные финансовые показатели, включая выручку, прибыль и CAC (Customer Acquisition Cost), стоимость привлечения клиента;
• LTV (Lifetime Value), жизненный цикл клиента;
• RR (Retention), удержание пользователей, количество людей, которые вернулись после первого входа в продукт;
• NPS (Net Promoter Score), индекс лояльности клиентов;
• MAU и DAU, количество пользователей продукта за месяц и день.

Опора на метрики помогает принимать более обоснованные стратегические решения. Данные надежнее интуиции, а еще аргументировать свои решения с ними проще.

Шаг 2. Спроектировать и реализовать MVP

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

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

• Классическая структура user story выглядит так: «Как [роль], я хочу [действие], чтобы [результат]».
• На практике это может звучать так: «Как клиент интернет-магазина, я хочу получать уведомления о скидках, чтобы успевать покупать товары по выгодной цене».

Чтобы полностью охватить требования к продукту, полезно продумать все пользовательские истории в контексте пользовательского пути и этапов взаимодействия с продуктом — составить user story mapping. Инструмент помогает пошагово спроектировать действия пользователей на основе реальных сценариев и приоритезировать задачи.

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

Шаг 3. Протестировать MVP и собрать обратную связь

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

Шаг 4. Вернуться к шагу 1 и повторить цикл

На основе обратной связи команда решает, что изменить в продукте, как улучшить UX и UI, что нужно для роста прибыли и масштабирования. А значит, снова проводит исследования и выдвигает гипотезы — то есть возвращается к первому шагу.

По такой схеме мы работали с приложением международной фармацевтической компании Bausch + Lomb, которая создает контактные линзы и другие товары для здоровья. Сперва мы сосредоточились на базовых функциях: регистрации, накоплении бонусных баллов за покупку и возможности проверки бонусного баланса. Так мы смогли протестировать основные гипотезы и получить первые данные о поведении пользователей.

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

Кейс Bausch + Lomb

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

Мы в ONY комплексно работаем над проектами: берем на себя запуск MVP и последующее развитие продукта. Вот с чем можем помочь.

Помимо этого, мы решаем точечные проблемы клиентов при запуске продуктов. Вот некоторые из них:

1. Отсутствие четкого видения и целей — может привести к разрыву между ожиданиями команды и стейкхолдеров.
2. Недостаточное понимание потребностей пользователя. Следствием становится то, что продукт не соответствует требованиям.
3. Слабое планирование, некорректная расстановка приоритетов. В итоге команде не хватает ресурсов, чтобы создать качественный продукт. Или продукт перегружается продуктами и становится слишком сложным.
4. Недостаточная координация внутри команды, непрозрачность процессов. Проблемы в коммуникациях могут приводить к конфликтам и ошибкам.
5. Слабая архитектура и технический долг.

Как внедрить продуктовый подход: эксперименты, данные и T-shaped команда

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

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

«Достигать целей и нести общую ответственность за результат проще, когда команда кросс-функциональная — в нее входят разработчики, маркетологи, дизайнеры и другие эксперты по клиентскому опыту, аналитики, продакт-менеджеры, тестировщики. Причем зачастую это T-shaped-специалисты, которые обладают навыками из сразу нескольких профессий: к примеру, дизайнер со знаниями в разработке или фронтенд-разработчик, понимающий принципы работы над дизайн-системой», — отметил Георгий Кустов, Digital Art Director в ONY.

Бывает, что внутри компании собрать такую команду трудно, быстрее и выгоднее привлечь к работе агентство. Для внедрения продуктового подхода лучше, чтобы в агентстве был СPO — Chief Product Officer, руководитель по управлению продуктами. У такого эксперта много опыта и насмотренности: наша практика показывает, что работа CPO напрямую влияет на успешность проектов и пользу, которую мы приносим клиентам.

Продуктовый подход предполагает две модели финансового взаимодействия с заказчиком.

1. Time & Material — оплачивается фактическое время работы специалистов, это удобно, когда на старте нет ясного понимания объема работ.
2. Retainer Agile — предполагает оплату за заранее определенное количество времени или ресурсов, которые выделяются на выполнение проекта. Чаще всего используется для работы над крупными проектами: маркетплейсами и интернет-магазинами, медиа, сложными корпоративными платформами.

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

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

Еще больше кейсов, подкастов от нашей команды и новостей дизайн-индустрии вы найдете у нас в Telegram-канале, подписывайтесь!