Как понять, нужно ли делать фичу, которую просит крупный B2B-клиент
Привет! Меня зовут Диана Нурекеева, я UX-исследователь в Авито. Я выстраиваю процесс дискавери и провожу рисёрчи в трёх продуктовых командах. В статье расскажу, что мы сделали, когда к нам внезапно пришёл один крупный клиент и попросил сделать для него большую новую фичу.
Немного контекста: что такое Автохаб и как устроена работа продуктовых команд в Авито
Я занимаюсь Автохабом — это онлайн-сервис для управления ключевыми бизнес-процессами автодилера: от выкупа до продажи. С помощью Автохаба дилер может искать, выкупать и продавать авто сразу на трёх досках объявлений — у нас, на auto.ru и Дроме. А ещё, например, проверять юридическую чистоту автомобилей, управлять рекламными инструментами и получать аналитические отчёты.
Мы в Авито планируем дискавери-процессы по фреймворку Double Diamond. Сначала исследуем множество причин для пользовательской проблемы, чтобы определить ключевую потребность. Затем генерируем множество решений, выбираем самое удачное, валидируем его и отдаём в разработку.
Наш фреймворк для процесса дискавери
Но иногда работать по такому процессу не получается.
У нас есть крупные клиенты-дилеры — наши бизнес-партнёры. Они часто приходят к нам с идеями, трендами и новыми фишками, и мы развиваем Автохаб с учётом их пожеланий.
Однажды один из крупных клиентов предложил сделать фичу, которая будет автоматически снимать с публикации объявления о продаже авто при определённых условиях. Например, если оно собирает мало трафика. Это позволило бы дилеру сэкономить и автоматизировать рутинную работу, которой сейчас занимаются вручную.
Проверили потенциал фичи с помощью опросов, аналитики и интервью
Прежде чем бросаться делать новую функцию, мы решили узнать, есть ли такая потребность у других пользователей.
Обратились к клиентским менеджерам, чтобы опросить пользователей. Но позже поняли, что допустили ошибку: мы не модерировали весь процесс, а только дали менеджерам список вопросов.
Они никогда не проводили исследования, поэтому могли задать вопрос в духе «а нужна ли вам такая-то фича?» На такое сложно не согласиться, поэтому одного опроса было недостаточно, чтобы удостовериться в существовании проблемы.
Обратились к аналитикам и узнали, сколько пользователей уже снимают объявления вручную. В выборку попала довольно большая доля, и мы решили, что у фичи есть потенциал. Но у нас не было ответа на вопрос — почему они делают это вручную? Мы не знали всех мотивов и причин.
Разделили пользователей на группы. Изучили, как часто они снимают объявления, с каких сайтов убирают их в первую очередь, выкладывают ли повторно.
Провели глубинные интервью с яркими представителями выборки. Результаты не были радужными: среди респондентов не оказалось тех, кто снимает объявления для экономии бюджета. А это была наша основная гипотеза. И клиент, который предложил фичу, считал это главной ценностью.
Объявления снимали по другим причинам, которые мы не могли отследить и автоматизировать. Например:
- авто в плохом состоянии, и его надо отправить на переподготовку, чтобы починить или почистить;
- у машины юридические проблемы;
Но были и хорошие новости: среди респондентов нашлись люди, которые заинтересовались этой функцией для экономии бюджета. Просто раньше они так никогда не делали.
Поняли, что явной потребности нет, но есть скрытый интерес. Клиенты озвучивали сомнения. Они хотели точнее узнать, как новая фича позволит сэкономить бюджет на маркетинг и отразится на других метриках, например, на оборачиваемости. Ведь если снять объявление, авто будет дольше продаваться и простаивать на складе, а за хранение надо платить.
Провели эксперимент: сделали MVP и протестировали его с одним клиентом
Мы решили провести тест с клиентом, который попросил нас создать новую фичу. Он уже снимал объявления вручную, знал последствия и не боялся рисковать. К тому же мы часто вместе обсуждали новые идеи, и у нас наладились партнёрские отношения.
Мы решили сделать упрощённый MVP, который почти не занял ресурсов разработки, протестировать его с клиентом и проверить, как изменились метрики.
Что включал MVP:
- базовый механизм снятия объявления с авто
- отслеживание трафика с разных площадок: если по объявлению давно нет звонков, просмотров, то мы автоматически его снимаем
После запуска MVP решили контролировать следующие показатели:
- как изменилась стоимость лида у партнёра
- удалось ли снизить затраты на размещение
- не уронили ли срок оборачиваемости
К марту 2024-го запуск MVP уже состоялся — сейчас следим за метриками. Решили, что если MVP покажет хорошие результаты, мы будем продвигать его другим клиентам и постепенно распространим новую функцию.
Подвели итоги
Весь дискавери-процесс занял 2 недели. Это была командная работа небольшими итерациями. После каждого интервью мы собирались и обсуждали инсайты, брейнштормили, меняли стратегию. Это позволило в сжатые сроки исследовать проблему со всех сторон и принять решение о разработке MVP.
Команда, которая работала над дискавери новой фичи
Вот к каким выводам мы пришли:
👉 «Мне нужна функция» ≠ «у меня есть потребность». Нужно глубже исследовать задачи пользователей, чтобы находить реальные потребности.
👉 Если с идеей приходит один клиент, стоит посмотреть на проблему шире и выяснить, есть ли такая потребность у других. У разных сегментов клиентов свои нюансы, которые следует учесть при разработке.
👉 Обогащайте сухие цифры инсайтами. Можно иметь достоверную аналитику, а потом начать копать глубже и понять, что боль пользователей вообще в другом. Поэтому лучше подкреплять аналитику глубинными интервью.
👉 Найдите для экспериментов клиента-партнёра, который не боится совершать ошибки и будет помогать развивать продукт.
👉 Не проводите исследование в одиночку — лучше исследовать проблему со всех сторон, обсуждать инсайты и принимать решения вместе с продуктовой командой.