Всем привет! Меня зовут Марина, я product manager в Mindbox — сервисе автоматизации маркетинга.

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

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

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

Как выглядел хаос в бэклоге

Бэклог хранился в системе управления задачами. Была мастер-карточка, в которой лежали заархивированные карточки продуктов Mindbox: CDP, рассылки, программа лояльности, мобильные пуши и т.д. А в карточках продуктов хранились ссылки на архивированные карточки фич. И только в карточке фичи можно было увидеть реальный клиентский запрос, из-за которого эту карточку завели. 

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

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

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

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

Не было доверия стейкхолдеров. В Mindbox есть внутренние стейкхолдеры: менеджеры из клиентского сервиса, саппорты, сейлзы, топ-менеджмент. Менеджерам нужно, чтобы клиенты могли запускать механики и улучшать свои бизнес-метрики, а продукт помогал в этом. Саппорты хотят, чтобы клиент мог работать без их помощи. Сейлзам важно, чтобы приходили новые клиенты, а мы не блокировали продажи. Топ-менеджмент хочет, чтобы компания росла.

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

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

Как наводили порядок в бэклоге

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

Навели визуальный порядок

Начали с того, что разархивировали все карточки и организовали систему хранения.

Завели общую доску и доски отдельных продуктов. Все входящие задачи поступают на общую доску. Если какая-то продуктовая команда планирует решать конкретную задачу, то уносит ее на свою доску. Если нет, задача остается висеть на общей доске и ждать своей очереди или отправляется в колонку «Слито». Продактам так удобнее работать: задачи каждой конкретной команды видны и не смешиваются с чужими. Стейкхолдерам тоже удобнее: статус задач отслеживать проще. 

Сделали единую точку входа заявок

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

Теперь все заявки на доработки собираются через онлайн-форму. Чтобы заполнить ее, недостаточно вписать требование клиента: нужно разобраться в его задачах и пользовательском пути, описать желаемый результат. 

Эта доработка помогла автоматизировать часть работы: теперь не нужно вручную заводить карточки. Сервис автоматически создает заявку на доске: описание проблемы затягивает в название карточки, имя клиента и продуктовую зону — в соответствующие поля карточки. Карточка попадает на общую доску в колонку «Входящие». 

Настроили процесс обработки заявок

Чтобы новый бэклог снова не превратился в свалку, внедрили процесс регулярной обработки входящих.

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

Каждую задачу оцениваем по трем критериям:

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

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

Соответствие стратегии. Укладывается ли клиентский запрос в стратегию компании? Объясню на примере. Задача Mindbox — автоматизировать маркетинг. Если клиент хочет с нашей помощью, например, автоматизировать бизнес-процессы, не связанные с маркетингом, такая задача считается невалидной. Если мы потратим ресурс на ее решение, скорее всего, получим результат, который не нужен другим клиентам. В таких случаях мы отказываемся от задачи, но совсем без помощи клиента не оставляем: можем предложить «костыльное» решение, но переделывать под нетипичную задачу продукт не будем.

Например, запрос: «Дайте возможность кастомизировать админку под операторов колл-центра, чтобы они могли менять контакты клиента, заполнять дополнительную информацию, списывать или начислять бонусные баллы». Mindbox — инструмент маркетолога, и под нужды колл-центра он не подходит. Такой запрос мы отклоняем и рекомендуем клиенту решать задачу с помощью CRM-системы, а измененные данные передавать нам через API. 

Провалидированная заявка получает мотивированный ответ, что мы будем с ней делать и почему, и перемещается дальше. Если польза для бизнеса понятна и задача соответствует стратегии, забираем карточку в свой бэклог. А если задача, например, не укладывается в стратегию, карточку безжалостно сливаем. Важно, что даже слитые карточки мы не удаляем, а отправляем в колонку «Слито» этого месяца. Делаем это для прозрачности: любой заинтересованный может найти карточку, прочитать ответ и обсудить его. 

Визуализировали процесс обработки задачи

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

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

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

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

Внедрили лимиты задач в работе

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

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

Начали сливать невостребованные карточки

Периодически я прохожусь по доске команды и повторно валидирую задачи.

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

Если сливаем карточку, которую уже забрали в бэклог команды, пишем объяснение и переносим на общую доску в колонку «Слито» этого месяца.

Как контролируем работу — SLA

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

SLA важен, потому что те обещания, которые мы даем клиентскому сервису, передаются клиентам. Например, клиент приходит с обратной связью, и наш менеджер должен ему что-то ответить, например: «Завтра я вернусь с ответом. А в течение недели может прийти продакт и позвать на интервью, чтобы лучше разобраться в проблеме». Эти сроки мы должны соблюдать.

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

Результаты

С обновленными процессами мы живем уже 11 месяцев. Можем подвести промежуточные итоги.

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

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

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

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

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

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

Mindbox растет, нам нужно все больше продактов, чтобы управлять его развитием. Если вы senior или middle product manager в поисках работы либо junior, готовый пройти продуктовую стажировку, напишите stepnova@mindbox.cloud.