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

Начнем с простого, что такое CJM? В целом это один из инструментов, который позволяет эффективно разрабатывать продукт. Эффективно, значит экономя ресурсы, в первую очередь, время и деньги.

Фактически создание CJM - customer journey map или попросту карты пользовательского опыта, сводится к проведению глубоких пользовательских интервью, с целью понять своего клиента и нащупать точки роста. 

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

Структурно CJM это таблица столбцы которой это этапы взаимодействия, а строки это информационные слои, которые содержат полезную информацию о взаимодействии клиента с продуктом.

Пример, очень крутого CJM. 

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

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

Собственно, создание хорошего CJM это сложный и кропотливый процесс, про то как это делать написано много отдельных материалов, я смотрю, например, то, что пишет, Станислав Хрусталев. Однако мне как специалисту по Data Driven интересно другое. CJM это инструмент не только понимания что болит у клиента, но еще и инструмент понимания, что делать. Для этого на CJM я предлагаю добавить слой технологических карт blueprint, в которых отображать продуктовые процессы, которые работают в данной точке касания. 

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

Следующим этапом мы используем юнит-экономику для оценки вклада каждой боли в результат, например в прибыль через расчет маржинальной прибыли. Фактически, CJM в большом проекте позволяет понять куда смотреть в первую очередь, и какая часть большого проекта требует наиболее пристального внимания, а юнит-экономика уже позволяет определять в каком порядке устранять эти потребности клиента.

В итоге наш процесс работы над повышением эффективности продукта через удовлетворение потребности клиента строиться следующим образом:

1. Строим CJM продукта.

2. Описываем технологические процессы для каждой точки касания.

3. Описываем и определяем значение метрики, связанной как с точкой касания, так и с процессом.

4. Определяем точки скопления проблем у клиента.

5. Строим юнит-экономику и фокусируемся на конкретных болях, которые дают наибольший вклад в целевую метрики, в общем случае в прибыль.

Пока это лишь общая, вводная статья, далее я буду расписывать процесс более детально, но так как не являюсь большим специалистом именно в CJM, буду акцент делать на использовании юнит-экономики и метрик при работе с CJM.