Как уже было отмечено выше, команды по работе с клиентским опытом отвечают за то, как ценность продукта воспринимается фактическими пользователями или клиентами.
Ключевой момент в том, что эти команды получают самые широкие полномочия в тот момент, когда на них возлагается как можно больше сквозной ответственности.
Чаще это происходит, когда объем ответственности каждой команды соответствует другим естественным структурам бизнеса, таким как каналы продаж, сегменты рынка или типы пользователей.
В большинстве случаев это означает создание топологии, согласованной с потребностями клиента.
Вот несколько примеров такой согласованности:
• по типу пользователя или его имиджу (например, «команда гонщиков», «команда водителей»);
• сегменту рынка (например, «команда по электронике», «команда модельеров»);
• клиентскому пути (например, «команда по адаптации», «команда по удержанию персонала»);
• каналам продаж (например, «команда самообслуживания», «команда прямых продаж»);
• ключевым показателям эффективности бизнеса, KPI (например, «команда по привлечению новых пользователей», «команда по конверсии»);
• географическому положению (например, «команда Северо-Американского региона», «команда Азиатско-Тихоокеанского региона»).
Эта согласованность не означает, что у команд по работе с клиентским опытом есть сферы приложения сил, соответствующие конечным результатам, которые нужны бизнесу. Между бизнес-результатами и работой над продуктом практически не требуется соответствия, и командам может быть предоставлена автономия, чтобы напрямую решать проблемы бизнеса.
Согласованность с клиентом для разных типов продуктов означает разное. Далее приведено несколько примеров согласованности. Этот список ни в коем случае нельзя считать исчерпывающим, и это не единственные возможные способы организации топологии команд по работе с клиентским опытом для данных ситуаций. Тем не менее есть определенные общие модели, которые доказали свою эффективность и их можно применять для создания вашей собственной топологии.
Для журналов, новостных сайтов или стриминговых сервисов команды по работе с клиентским опытом можно организовать на основе рубрикации контента.
Управлением и общими возможностям контента занимаются платформенные команды, которые предоставляют общие сервисы ряду команд по работе с клиентским опытом (могут составлять большую часть персонала, работающего над продуктом).
Каждая команда по работе с клиентским опытом охватывает комплексные потребности каждой медийной категории (спорт, местные новости, погода) или бренда. В некоторых случаях одна команда может охватить несколько аналогичных категорий, а более широкие или узкоспециализированные категории опыта потребуют отдельных команд.
Такой подход помогает добиться удовлетворения потребностей разных типов клиентов. Кроме того, он способствует согласованности работы команды клиентского опыта с разными бизнес-целями в каждой категории и стратегиями вывода продукта на рынок, которые в таких компаниях обычно общие.
Электронная коммерция может строиться по модели, аналогичной модели медиапродукта, особенно если опыт совершения покупок существенно различается в зависимости от категории (автозапчасти, билеты на концерты, ювелирные украшения).
И здесь продукт тоже создается на большой платформе общих сервисов (управление каталогом, биллинг, управление учетными записями и т. д.). Команды по работе с клиентским опытом распределяются по категориям.
Корпоративные продукты часто должны быть подогнаны под потребности клиентов из разных сегментов. В одних случаях различия обусловлены вертикальным рынком клиентов (промышленное производство, финансовые услуги, розничная торговля). В других случаях различия, и весьма существенные, основаны на стратегии вывода продукта на рынок. Иногда они вызваны размером компании клиента (например, с компаниями из сегментов малого и среднего бизнеса можно связаться через портал самообслуживания, тогда как для более крупных клиентов требуются торговый персонал и API для кастомизации продукта с учетом их потребностей).
Здесь целесообразны команды по работе с клиентским опытом на основе любой сегментации, связанной с деятельностью компании. Цель — организовать команды таким образом, чтобы дать им возможность предоставить оптимальное обслуживание конкретному клиенту, а также увязать свою работу с другими частями компании.
Многие продукты имеют цель соединить разные группы людей с взаимодополняющими целями, например продавцов и покупателей, водителей и пассажиров, владельцев отелей и гостей. Большинство маркетплейсов — двухсторонние, но сторон может быть и больше.
В основном потребности людей по разные стороны маркетплейса не совпадают. Это относится и к остальному бизнесу, который старается поддерживать и ту и другую стороны.
В силу этих причин расширяются возможности для топологии, для организации команды по работе с клиентским опытом в зависимости от стороны, занимаемой на маркетплейсе.
Продуктовая команда по поддержке клиентов создает инструменты и системы, которые используются сотрудниками внутри компании, обеспечивающими довольно значительную часть клиентского опыта.
Среди них могут быть, к примеру, системы для расширения возможностей службы поддержки клиентов или непосредственных работников магазина.
В этом случае топология может дать командам по работе с клиентским опытом более широкие полномочия, согласуя их с комплексными потребностями пользователей внутри компании.
И последнее: ваша топология не обязательно должна организовывать все команды по работе с клиентским опытом в соответствии с одним параметром, таким как вертикальный рынок или размер компании клиента. Некоторые топологии используют разные параметры согласованности в разных областях, если так лучше для дела.
Топология и дизайн
Большинство компаний понимают, что кросс-функциональная продуктовая команда — по крайней мере, для команды по работе с клиентами — должна иметь предметно-ориентированного продуктового дизайнера. Это свидетельствует о признании значимости продуктового дизайна для создания высококачественного продукта.
Однако в некоторых случаях руководитель по продуктовому дизайну компании предпочитает другую модель, которая называется моделью внутреннего агентства. В этом случае у руководителя есть сервисная команда дизайнеров, и продуктовые команды должны обращаться к ней с просьбой о создании дизайна для их продуктов.
Будет справедливо признать, что у этого подхода есть ряд определенных преимуществ, особенно в плане обеспечения целостного взгляда на дизайн.
Однако, как говорится, «нужно быть среди тех, кто принимает ключевые решения».
Модель внутреннего агентства не предполагает, чтобы дизайнер делал именно так, и, следовательно, дизайнеру — а в итоге и нашим пользователям — приходится за это расплачиваться.
Дизайн продукта слишком важная вещь, чтобы рассматривать его как задачу внутреннего поставщика услуги. Дизайнер должен быть полноправным членом продуктовой команды первого ряда, таким же, как менеджер по продукту и техлид.
Менеджер по дизайну может обеспечить целостный подход к дизайну продукта, устанавливая стандарты дизайна, его правила и системы, проверяя работу дизайнеров, а также реализуя стратегию дизайна и проводя обзорные сессии с более широкой группой продуктовых дизайнеров.
Обратите внимание: для компаний, где используются функциональные команды, это, по сути, не имеет значения, поскольку ключевые решения принимаются до того, как происходят первые консультации с дизайнером.
Топология и структура подчинения
Структура подчинения инженерного персонала чаще всего строится на основе конкретных наборов навыков. Например, группы инженеров по обработке данных, фронтенд-инженеров и мобильных инженеров, как правило, подчиняются разным менеджерам. Благодаря такой системе любой менеджер по инжинирингу может проводить специализированный коучинг для каждого инженера в своей команде.
Это не является большой проблемой, но руководители технологических компаний могут поддаться искушению полностью выстроить продуктовые команды в соответствии с подобной структурой подчинения. Например, создать отдельную команду только из фронтенд-инженеров.
Такой подход редко приводит к созданию продуктовых команд с расширенными полномочиями, поскольку команды не связаны ничем, кроме набора технических навыков, что редко оказывает влияние на конечные результаты, нужные бизнесу.
Например, при топологии, которая делит организацию на веб-команду, iOS-команду, команду Android и бэкенд-команду, очень трудно предоставить любой из них возможность отвечать за многоканальное обслуживание клиентов.
Знаменитый программист Мелвин Конвей придумал то, что часто называют «законом Конвея». Он гласит, что «любая организация, проектирующая системы, неизменно создает проекты, копирующие коммуникационную структуру этой организации».
Можно сформулировать это иначе: будьте внимательны, не рассылайте потребителям схему вашей оргструктуры.
Одно из преимуществ кросс-функциональных команд в том, что участие в них определяется тем, что будет полезней для продукта.
Подведем итог: нет никаких оснований утверждать, что схема подчинения должна диктовать топологию команд.