Customer Persona окупается, только когда отменяет фичи

Персона, которая не отменила ни одной фичи, не работает. Проверить это можно за час: у скольких из 20 задач бэклога есть персона и задача? В примере ниже пара нашлась у 13, и три четверти спринта ушли на работу без адресата.

Сам приём придумал дизайнер Алан Купер. В книге The Inmates Are Running the Asylum (1999) он предложил вместо среднего пользователя описывать конкретный образ с целями и поведением. Карточка на стене с именем, возрастом и цитатой теряет как раз эту мысль: персона задаёт того, для кого принимают решение. А решения тем временем принимают по интуиции и по следам последнего разговора с крупным клиентом.

Персона живёт как документ, а работать должна как способ думать

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

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

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

Именно эту логику высвечивает подход Jobs to Be Done. Представьте кофейню у выезда на трассу. Утром кофе с собой берут водители, которым впереди час дороги, днём тот же кофе берут родители, пока ребёнок сидит на кружке по соседству. Возраст и доход у этих людей могут совпадать, а выбирают они по разным признакам: первым нужна крышка, которая не протечёт в машине, вторым место у окна и розетка. Демография здесь ничего не объясняет. Объясняет работа, ради которой продукт нанимают, и хорошая персона описывает как раз её. Без этого под одну Customer Persona подходит любое решение, и она перестаёт хоть что-нибудь ограничивать.

Где рвётся связь между исследованием и решением

Персона полезна, только пока работает по кругу. Исследование даёт портрет клиента. Портрет влияет на решение. Решение даёт результат, а результат уточняет портрет. Стоит разорвать этот круг в любом месте, и персона повисает в воздухе.

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

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

Модель имеет право ошибаться, но не имитировать

От персоны часто ждут точности. Но это всего лишь модель, и ошибки в ней неизбежны. Важно отличать ошибки, которые не мешают, от тех, что делают персону бесполезной:

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

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

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

По каким решениям видно, что персоной не пользуются?

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

В приоритизации и разработке разрыв виден по универсальным решениям. Фичи делают «для всех», потому что персона слишком размыта, а приоритеты определяют технические и организационные факторы, словно клиента в этом процессе нет вовсе. Зрелая персона, наоборот, помогает отказываться от идей, которые не решают ключевую задачу, и это её самая недооценённая функция.

В разговорах команды незрелость слышно по размытым формулировкам. О пользователе говорят абстрактно, аргументы легко подменяются, и каждый отдел (продукт, маркетинг, разработка) трактует клиента по-своему. Общая персона снимает часть споров просто потому, что даёт единый язык: у всех трёх отделов в споре одна и та же модель клиента.

Персона-декорация против персоны-инструмента

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

Здесь помогают два простых признака. Первый: каждая продуктовая гипотеза прямо называет, для какой персоны и какой задачи она придумана. Это дисциплинирует и отсекает идеи без адресата. Второй: команда записывает, что считает правдой о мотивах, страхах и ограничениях клиента. И потом эти допущения проверяет. Там, где персона живёт сама по себе, не связана с бэклогом и не участвует в оценке решений, она снова становится декорацией. Разницу удобно свести в таблицу.

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

Проверка на бэклоге: 20 задач за один час

Проверить, работает ли персона, можно без опросов и воркшопов, на одном бэклоге. Возьмите 20 верхних задач и для каждой запишите пару «персона плюс задача клиента», ради которой её делают. Задачи, для которых пары не нашлось, пометьте.

Допустим, из 20 задач пара нашлась у 13. Семь оставшихся весят 45 стори-поинтов при ёмкости команды 60 поинтов на спринт, то есть три четверти спринта уходят на работу без адресата. Здесь персона либо слишком размыта, чтобы к ней привязать хоть что-то, либо её не открывали с момента сборки. Обе причины видны сразу: если пары не находятся потому, что персона описывает «мужчину 30 лет», чинить надо её; если персона конкретна, но про неё никто не вспомнил, чинить надо процесс приоритизации.

Отсюда простое правило с настраиваемыми порогами. Если без пары остаётся больше 30% верхних задач, персона работает как декорация, и её пересборку стоит поставить выше любой из этих задач. Если меньше 10%, персона работает, и вопрос только в том, как часто её обновлять. Если результат между порогами, персона жива, но работает выборочно: обычно в исследованиях и почти никогда при выборе приоритетов.

Чтобы проверка не стала ритуалом, следите за двумя цифрами. Первая: в какой доле решений о приоритетах за квартал явно названы персона и задача. Вторая: сколько задач отменили из-за персоны, а потом пришлось вернуть. Если это число растёт, персона стала слишком узкой и отрезает реальные сценарии.

Ошибки сборки тянут за собой ошибки применения

Способов испортить Customer Persona немного, и они выстраиваются в цепочку. Начинается она при сборке: персону строят на догадках вместо исследований, ставят во главу демографию (возраст и профессию) и оставляют за скобками задачи и мотивацию. Из такой заготовки сразу выпадает контекст выбора, и уже непонятно, в какой ситуации клиент вообще принимает решение. Выпадает и боль, так что чётко сформулированной проблемы в персоне попросту нет. А без проблемы персона расплывается до того, что под неё подходит любой пользователь и любое решение.

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

Слышно это и в речи. «Наш пользователь мужчина 30 лет, любит технологии» описывает кого угодно, «давайте сделаем универсально, всем понравится» отказывается сужать выбор, «персона есть, но сейчас не до неё» выдаёт брошенный артефакт, «это слишком частный случай» отмахивается от реального сценария, а «клиенты сами не знают, чего хотят» снимает с команды обязанность разбираться. За каждой такой репликой стоит персона, которой либо не пользуются, либо подменяют её общими рассуждениями.

Персона вокруг задачи и персона по ролям

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

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

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

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

Нужна ли персона, если роль одна?

У персон есть серьёзные противники. Практики подхода Jobs to Be Done говорят, что решение о покупке определяет ситуация, а портрет человека тут почти ничего не добавляет. Тот же водитель, который утром берёт кофе в дорогу, в выходной может зайти в ту же кофейню с ребёнком, и это другая работа с другими критериями. Персона склеивает обе ситуации в одного человека и тем самым прячет разницу, которую продукту нужно видеть. Отсюда их вывод: описывайте работы и ситуации, а людей не описывайте вовсе.

Они правы, когда работ мало, а пользователи однородны. Внутреннему инструменту для 40 бухгалтеров, которые закрывают один и тот же месяц по одному регламенту, хватит двух-трёх историй задач (job stories) вида «когда..., я хочу..., чтобы...». Отдельная персона здесь только дублирует их.

Неправы они там, где у одной покупки несколько участников с разными интересами, как в B2B-случае выше: работа «закрыть месяц без ошибок» у бухгалтера, «не нарастить штат» у финансового директора и «не получить новую интеграцию» у ИТ-отдела. Здесь персоны по ролям нужны именно для того, чтобы развести эти интересы. Правило выбора: одна роль и до трёх работ означают job stories, несколько ролей в цепочке покупки означают персоны, привязанные к работам.

Что стоит проверить в собственной персоне

Собственную персону полезно прогнать по нескольким осям. Опирается ли она на реальные данные. Описывает ли задачу клиента, его боль и контекст, в котором он принимает решение, и названы ли критерии, по которым он выбирает. Живёт ли персона в работе: в исследованиях, в выборе приоритетов, в решениях отказаться от лишнего, или всплывает только в презентациях.

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

Персона окупается только тогда, когда меняет решения

Customer Persona стоит усилий в одной-единственной ситуации: когда её используют как способ думать о клиенте. Справка о клиенте таких усилий не окупает. Сегмент описывает группу, а персона описывает логику, по которой человек внутри этой группы выбирает. Она не гарантирует успех: её выводы нужно проверять по исследованиям и поведению клиентов, как и любые другие продуктовые гипотезы.

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