Выкатили новую фичу, но клиенты не используют, потому что хотели её под Новый год, а сейчас — июнь. Реализовали улучшение, а оно не востребовано, потому что мы не подумали, как клиенты будут его использовать. Мы работали в стол, а потом задумались, почему так происходит, и построили иерархию метрик. Теперь четыре из пяти внедренных фич получают высокую оценку клиентов. Показываем, как так получилось, и делимся шаблоном.
Привет, Хабр, я Дима Бондаренко, менеджер команды разработки в Mindbox. Отвечаю за результат, эффективность и рост команды. В команде 25 человек: 20 разработчиков и 5 продактов. Именно работа продакт-менеджеров помогает строить иерархию задач, которая нас выручает, в статье расскажу, как так вышло.
Почему команда работает в стол
Пару лет назад мы брались за десятки задач, но по данным нашего мониторинга, больше половины усилий по развитию продукта не доходили до запусков с клиентом.
Что разрабатывать, решал лид команды продакт-менеджеров, опираясь на чуйку и кусочки клиентских кейсов из собственной памяти. На командных встречах подбирали небольшие задачи для следующих спринтов, звучало это так: «На одном проекте просят фичу, берем в следующий спринт». Или: «На этой неделе приходил клиент с проблемой, и месяц назад, кажется, был похожий случай, давайте сделаем».
Однажды клиент пришёл к нам перед праздниками с запросом на автоматизацию запуска всплывающих сообщений. Дело было перед Новым годом, в предпраздничной суете лид упустил этот запрос из виду. Продакт-менеджер, который пришёл к клиенту уточнить задачу, услышал от клиента, что маркетологи вручную запускали праздничные акции все две недели новогодних каникул.
Продуктовое изменение ценой в 3 месяца команды из 10 человек не использовал ни один клиент. Ещё четыре изменения поменьше, на каждое из которых ушло по несколько недель разработки, постигла та же участь.
Проблемы, с которыми приходили клиенты, и «похожие случаи» — это бэклог продукта, который стихийно пополняли продакт-менеджеры. Истории годичной давности всё ещё были в бэклоге и считались «актуальными». С таким старым запросом продакт-менеджер тратил недели на актуализацию данных и часто обнаруживал, что клиенту эта задача давно неинтересна. А ещё в бэклоге хранились одновременно продуктовые решения без запросов от клиентов и проблемы клиентов без решений.
Я увидел в этой ситуации возможность для улучшения и сформулировал её так: «Сейчас есть бэклог, который не вызывает доверия, не помогает принимать решения и не показывает актуальные клиентские проблемы. Чтобы упростить принятие решений и расставить приоритеты в запросах клиентов, нужно визуализировать клиентские проблемы».
Откуда задачи попадают в бэклог
Первым делом я стал разбираться, что делают продакт-менеджеры перед тем, как отправить задачу в разработку — может, им вовсе не бэклог нужен.
Узнал, что продакт-менеджеры выявляют задачи клиентов из среднего и крупного бизнеса и предлагают им решения — так появляются задачи для разработки. Делают они это разными способами:
Отвечают на запросы клиентов, как третья линия поддержки. Продакты разбираются с задачей клиента и предлагают решение для сложных запросов, которые не могут решить в поддержке первой и второй линии.
Приглашают клиентов на интервью — запрашивают обратную связь о продуктах или выявляют новые задачи.
Перебирают весь бэклог, чтобы подтвердить необходимость дорогих продуктовых изменений или выбрать небольшую задачу на следующий спринт.
И так выходит, что отправной момент всех изменений в продуктах — клиентские задачи и истории, которые мы в команде называем кейсами. Продакт-менеджеры уже их выявляют, собирают для крупных задач, на их основе как-то сортируют мелкие задачи. И кейсов собирается немало — от 10 до 15 в неделю. Но этот сбор никак не систематизирован: нет единой формы, нет распределения по направлениям, сортировки. Я решил усовершенствовать сбор кейсов, чтобы увидеть, удастся ли на их основе построить выбор задач.
Из чего состоит клиентский кейс
Чтобы предложить клиенту подходящее решение, мы должны понять его задачу. А чтобы сделать это, нужно вникнуть в ситуацию клиента и описать её так, чтобы любой читающий понял её не хуже того, кто описывал. Эту историю будут читать другие продакт-менеджеры, дизайнеры или разработчики, и у них должно сложиться такое же понимание ситуации, как у автора кейса. Иначе кейс может быть неверно понят, и решение, принятое на его основе, рискует опять попасть «в стол».
Я решил, что нужно сохранять максимально полный контекст клиентской задачи и его первоисточник (интервью, карточка в поддержке, любые ссылки). Сделать так, чтобы не зависеть от воспоминаний, когда приходит время формулировать задачи для разработчиков.
За основу я взял формат STAR-интервью, он близок к формату JTBD, который уже применяется в Mindbox.
Что такое STAR
Фреймворк STAR — это методология, которая расшифровывается как:
S (Situation) — ситуация, в которой находится клиент;
T (Task) — задача, которую клиент хочет решить;
A (Action) — действие, которое клиент предпринимает для решения задачи;
R (Result) — результат, который клиент получает.
Этот подход помогает структурировать работу над продуктом, чтобы решения были ориентированы на реальные потребности пользователей.
Получился список обязательных полей клиентского кейса:
Ситуация. Сюда пишем факты: чего клиент хочет добиться, что у него получается, а что не получается. При этом «хочет фичу» или «неудобно что-то делать» — не ситуация, надо уточнять, почему неудобно и зачем нужна фича.
Задача клиента: конкретный следующий шаг к его цели в его ситуации.
Ожидаемый результат — влияние на бизнес клиента или на работу маркетолога. Например, клиент надеется, что сможет автоматизировать задачу, или считает, что сэкономит деньги на рекламе или оплате стороннего приложения.
Как клиент решает задачу сейчас — опционально: если задача решена, то как, с какими результатами. Если клиент использует сторонние продукты или делает что-то вручную, это должно быть отмечено в кейсе. Если искал, но не нашел решения — тоже.
Когда определился со структурой, взял одну из крупных задач в работе, по которой уже были расписаны клиентские кейсы, собрал таблицу и пошел к команде.
Таблица, с которой я пришел к команде. Для наглядности удален столбец с именами клиентов | ||||
Ситуация клиента | Задача | Ожидаемый результат | Как решает задачу сейчас | Комментарий |
Клиент хочет как можно чаще рассказывать о новых фильмах, которые сейчас идут в прокате | Показывать раз в неделю In-App с рекламой нового фильма, пока он идет в прокате | Вырастет выручка от продажи билетов | Показывают один раз или заводят In-App повторно | Повторный показ In-App Аквамен дал клиенту еще 9 заказов и увеличил общую выручку от кампании |
Клиент хочет напоминать пользователям о возможности пролонгации займа при его погашении | Показывать In-App о возможности пролонгации каждый раз перед погашением займа, минимум пять раз | Увеличится количество пролонгаций займа | Клиент информирует о пролонгации займа только в мобильных пушах | Пользователь может в рамках договора пять раз просить пролонгацию, поэтому надо минимум пять раз показать In-App на пролонгацию или чаще |
Маркетолог вручную запускает коммуникации по нескольким каналам в т.ч. на выходные и праздники | Автоматизировать запуск и остановку In-App | Сократится время на запуск и остановку кампаний | Пробовали вручную, маркетолог понял, что тратит на это много времени и перестал пользоваться функционалом | Отключили модуль, в том числе по этой причине. Пример In-App, который запустили 23 февраля вручную. |
На примере этой таблицы мы с командой продакт-менеджеров поняли, что можно будет хранить кейсы, чтобы потом связывать их с задачами. Не надо вспоминать клиентские проблемы, переносить руками, приводить к одному формату.
Мы договорились с командой, как и когда вносить кейсы: после интервью с клиентом или в работе над обратной связью, если в продукте решения нет или оно «костыльное». Для интервью создали шаблон.
Перестроили работу с кейсами, чтобы они заполнялись по шаблону. Хорошо заполненный кейс должен обязательно содержать описание ситуации клиента, задачу и ожидание клиента.
Новый кейс теперь проводим через три шага: сначала он попадает на проверку-сортировку, которую мы назвали «триаж». Команда продакт-менеджеров проверяет каждый на полноту — заполнение обязательных полей. Если продакт заполнил все поля и информация наполнена смыслом, то кейс считается валидным, если нет — отправляется на уточнение.
Как отбираем задачи для разработки на основе кейсов
Нашим продакт-менеджерам поступает по 10 и больше запросов в неделю от техподдержки и напрямую от клиентов. Мы формируем из этих запросов кейсы, на их основе — задачи для разработчиков. Разбирать каждый кейс отдельно неудобно — не видно, есть в них одна общая задача или десятки разных никак не связанных. Часто истории клиентов похожи, как в таблице с примерами выше: несколько клиентов хотели автоматически запускать In-App в выходные и праздники, одно действие, хоть и с разными целями. Чтобы ориентироваться по кейсам, стал складывать их в папки по схожим или одинаковым задачам клиентов.
Папки-проблемы указывают, какие задачи нам предстоит решить в продукте. Чтобы определить, какую проблему решать первой, папкам присваивается вес. Чем он больше, тем раньше задача отправится на доработку. У нас папки распределяются на три стопки:
в работе — по ним есть задачи, выделены ресурсы;
в фокусе — по ним запланированы задачи;
не в фокусе — еще не дозрели или уже решены и больше не беспокоят.
Как оцениваем приоритет папок с кейсами
Чтобы расставить приоритеты, нужна объективная и понятная система оценки. Из разных моделей приоритизации бэклога я выбрал общеизвестную RICE.
Что такое RICE
RICE помогает расставлять приоритеты и выбирать проекты с максимальной отдачей при минимальных затратах. Это метод оценки идей и проектов по 4 критериям:
Reach (Охват) — сколько пользователей/клиентов затронет решение (в месяц, квартал).
Impact (Влияние) — насколько сильно решение повлияет на пользовательский опыт (например, от 1 до 3: низкое, среднее, высокое).
Confidence (Уверенность) — насколько вы уверены в оценке (от 50% до 100%).
Effort (Затраты) — сколько времени или ресурсов потребует реализация (в человеко-месяцах).
Считаю, что можно не оценивать время на разработку, когда мы собираем и структурируем проблемы, а не решения, поэтому моя формула выглядит так:
Все критерии оцениваются в диапазоне от 0 до10, их произведение обозначает приоритет проблемы.
Охват (Reach)
Значение метрики охвата зависит от того, сколько уникальных клиентов затрагивает проблема. Мы используем общепринятую метрику MAU (monthly active users): внедряем улучшение, если в нем нуждаются больше 50 уникальных клиентов в месяц.
Чтобы учесть уникальных клиентов для иерархии бэклога, мы не ждем, пока придет 51 клиент с проблемой: если мы знаем о двух, то есть еще два, если знаем о 25 клиентах, то найдем еще 25. Поэтому присваиваем охвату десятку, если знаем о 25 клиентах с проблемой, и валидируем значение экспертным мнением продакт-менеджеров, проще говоря, опираемся на их чуйку.
Влияние (Impact)
Тут определяем, что изменится, если решим проблему (или не решим).
Я хотел уйти от оценочных суждений в духе «10 за огромное влияние, 5 за среднее, 1 за минимальное» и взять измеримые ориентиры. Для этого я внедрил иерархию метрик, с помощью которых мы следим за внедрением продуктов.
Процент проникновения — ключевая метрика для дополнительных модулей Mindbox. Модули дополняют основной продукт и тарифицируются отдельно. Проникновение показывает, какой процент клиентов платит за такие дополнения.
История успеха клиента — если мы принесли измеримую пользу, то клиент запустит сарафанное радио, а мы сможем прийти с результатами к похожим клиентам. Это обеспечит приток новых пользователей и удержание существующих. Наш опыт показал, что лучше всего новых клиентов привлекает успех уже существующих. Еще можно привести клиентов, если увеличить рынок: адаптировать продукт под новый сегмент или индустрию.
Отток клиентов разложил похожим образом: выделил основные критерии несчастья. Например, клиентам плохо, если наш продукт работает ненадежно и не выполняет обещаний (SLA). Отдельно выделил метрики поддержки продукта — когда у клиента что-то не получается в работе с продуктом, он приходит к нам, мы вместе тратим время.
Time-to-value механик — насколько дорого клиенту пройти путь от идеи до реализации маркетинговой кампании. Если дорого — клиент может уйти.
Важность оценивал, опираясь на собственный опыт. Метрика — понятный ориентир, чем она важнее, тем больше влияет на вес кейса.
Иерархия метрик позволяет быстро перевзвесить бэклог. Например, если мы видим, что клиенты жалуются на надежность или выросли метрики техподдержки, то даем больше веса метрике SLA или техподдержки, чтобы в ближайший квартал/полгода работать именно на нее.
Уверенность (Confidence)
Мы ушли от оценочных суждений и опираемся на клиентские кейсы, поэтому увереннее отдаем задачи в разработку. Значение этой метрики по умолчанию — единица: мы уверены, что проблема существует.
Если клиент придумал, как решать проблему самостоятельно — за такой кейс начисляем балл Confidence. Клиент не стал бы тратить силы на пустые проблемы. Клиент сделал все вручную и закрыл кейс — добавляем балл в метрику Confidence.
Я умышленно не стал добавлять усилия (Effort) из исходной формулы RICE для оценки приоритетов: в бэклоге хранятся и оцениваются проблемы, а не решения. Стоимость решения зависит от нашей изобретательности и упорности — где-то будет достаточно хорошо от небольших изменений, а где-то мы готовы вкладывать месяцы разработки в несколько подходов.
С новым подходом бэклог стал более актуальным. Если раньше в нем можно было найти карточки годичной давности, теперь мы приняли волевое решение: не учитывать кейсы, в которых не было изменений за последние 180 дней, признать их неактуальными.
Было | Стало |
Выбирали задачу и тратили неделю продакт-менеджера на подбор и актуализацию клиентских кейсов | Только валидные кейсы в бэклоге. Продакт-менеджер открывает бэклог и сразу получает пакет актуальных и полноформатных кейсов |
Тратили время на решение проблем, которые были актуальны полгода-год назад | Не учитываем кейсы, которые не обновлялись за последние 180 дней. Если вес папки растет, то кейсы свежие и актуальные |
Что выиграли от нового подхода к бэклогу
Начали собирать и триажить кейсы, сделали привязку кейсов к продуктовым задачам, выровняли по приоритету. В результате получили несколько заметных улучшений.
Воронка клиентов всегда актуальна. Перестали тратить время на раскопки и актуализацию клиентских ситуаций. Сразу идем к клиентам с намерением запустить пилот и решить их задачу.
Создаем полезное. С начала отстройки бэклога от клиентских кейсов прошел год. За этот год 20 из 25 малых продуктовых изменений довели до пользы клиентам — есть запуски, фидбек, результаты клиентов. Все 11 крупных изменений в продукте довели минимум до пилотов.
Получили прозрачные результаты работы. Цель изменений в продукте — помочь клиенту дойти до успеха, решив его проблемы и задачи. В процессе разработки у кейса в бэклоге начинается вторая жизнь. Продакт-менеджер возвращается к клиентам и предлагает решение, отслеживает внедрение и собирает обратную связь — удалось ли решить проблему. Про успешные продуктовые изменения мы рассказываем на продуктовом демо для всей компании.
Улучшили онбординг продакт-менеджеров. Одновременно с бэклогом в команде появилось два junior продакт-менеджера. Каждую неделю они приносили истории клиентов на триаж — и неминуемо получали обратную связь (поначалу записи были поверхностны и абстрактны). За время испытательного срока ребята поняли, что кейсы — это важно, скорректировали свой подход к работе с ними, начали докапываться до корней. Теперь качественные кейсы — один из критериев прохождения испытательного срока.
Лиля Анохина, lead product manager web&mobile: Раньше продакт-менеджеры заполняли каждый свои карточки, не пересекались друг с другом и варились в собственном соку. Триажи помогают распространить опыт и экспертизу, избежать дублирования решений и увидеть повторяющиеся проблемы.
Также стало удобнее готовиться к интервью: в карточке клиента видно его кейсы, прошлые интервью, особенности договора с ним. Раньше мы задавали одни и те же вопросы, это создавало впечатление небрежного отношения к клиенту.
Упростили путь задач в разработку. Перед тем, как отправить задачу программистам, продакт-менеджер делает ее питч, чтобы члены команды смогли высказать свои опасения и возражения. Для питча изменения в продукте ему нужно три слагаемых:
Драйвер изменений (обычно это клиентские кейсы).
Продуктовое решение.
Ожидаемая польза от изменений.
Теперь кейсы всегда под рукой и в понятном формате. Стало проще «накладывать» предлагаемое решение на клиентские проблемы и видеть белые пятна в решении. Разработчикам стала понятнее мотивация изменений в продукте.
Наташа Фокина, product manager web&mobile: Теперь кейсы по проблеме объединены, и мы видим неочевидные особенности, которые иначе могли бы упустить.
Например, у нас было два клиентских кейса с In-App. Первый клиент пожаловался, что пользователи пропускают важные сообщения. Мы выяснили, что это из-за foreground-сервиса (у пользователя отображалось местоположение курьера, даже когда приложение закрыто). Из-за этой фоновой работы в приложении не закрывалась сессия и не приходил новый In-App. У второго клиента за 3-дневный период короткой акции In-App показался не всем. Оказалось, что сообщение не увидели те пользователи, которые недавно заходили в приложение — их предыдущая сессия еще не закончилась.
Оба кейса в бэклоге попали в одну проблему «Клиенты не видят in‑app из‑за продолжительности сессий». Несмотря на то, что ситуации у клиентов были разные (в одном — особенность приложения, в другом — особенность механики), в итоге было сделано одно решение, которое подходит для обоих кейсов.
Распространили новый подход и инструмент на другие продуктовые команды. Тут просто покажу отзывы коллег, которые внедрили у себя новшество.
Антон Мавзютов, engineering manager loyalty, Андрей Медведев, lead product manager loyalty: Новый подход помог организовать работу продуктовой команды. Мы через бэклог обрабатываем и проблемы, и гипотезы. Проблема проявляется на основе обратной связи от клиента, гипотеза исходит от продакт-менеджера, а кейс — только на интервью, так что мы немного изменили процесс под себя. Раньше мы это всё из головы тянули, как Дамблдор с омутом памяти, теперь всё структурировано и видно, какие гипотезы валидны, какие проблемы решаются.
Но бэклог не решит за вас, что делать. Это только инструмент в помощь, кристаллизованный клиентский опыт. В основе выбора все равно здравый смысл. Бэклог подсказывает, но решение принимает человек.
Лиля Анохина, lead product manager web&mobile: Бэклог не говорит, что конкретно делать дальше, нужен аналитический взгляд продакт-менеджера. Но в новой структуре лучше видно, где надо принять решение. Стало проще погрузиться в проблему клиентов и подготовить продуктовое решение.
А теперь — делимся инструментом. Предлагаю уважаемым хабровчанам опробовать наш инструмент и способ работы с бэклогом. Вопросы задавайте в комментариях к статье.
