Разница в том, чтобы сделать нужную работу

Руководитель продуктовой практики роботов Леонид Борисов рассказывает о продуктовом подходе, метриках, KPI и простом пользовательском счастье.

— Какого подхода придерживаются роботы в разработке продукта?

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

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

— Как это выглядит на практике?

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

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

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

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

— Какие KPI используют роботы? Насколько показатели зависят от особенностей продукта?

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

В рамках продуктового подхода мы стараемся принимать все решения на основе метрик, с оглядкой на то, как это повлияет на KPI продукта. Вся система принятия решений о развитии продукта опирается на цифры. Зная, какие показатели изменить, мы решаем, что для этого сделать.

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

Получать свой FYI

Ежемесячная подборка приятных металлических текстов

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

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

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

— Сколько времени нужно на проверку гипотезы?

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

Очень важная часть — работа с метриками. В случае, если у нас есть несколько гипотез, требующих подтверждения, проводим А/В-тестирование, чтобы выбрать оптимальный вариант.

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

— Продукт и проект: в чем разница?

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

Комментировать:

Facebook

Vkontakte

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

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

Комментировать:

Facebook

Vkontakte