«При решении задач пользователя стоит перенести фокус с персоны на контекст»

Бывший менеджер продуктов «Яндекса» и автор Telegram-канала об управлении проектами Анна Булдакова о том, что такое концепция Jobs-to-be-done и как она помогает улучшать продукты.

Хочу рассказать про один классный фреймворк, о котором, к сожалению, знают немногие: Jobs-To-Be-Done (JTBD). Его популяризировал профессор Гарвардской школы бизнеса и автор «Дилеммы инноватора» Клейтон Кристенсен.

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

Пять минут назад Петя купил Sniсkers. Повлияла ли какая-то из характеристик, перечисленных выше, на факт покупки? Нет, не повлияла. Петя купил Snickers не потому, что ему 30 лет, а потому что он проголодался.

У всех нас постоянно возникают какие-то задачи («работы» в терминологии JTBD): убить время, стоя в очереди; приготовить полезный завтрак; поделиться впечатлениями от поездки. Когда мы начинаем пользоваться каким-то продуктом, мы фактически «нанимаем» его, чтобы он помог нам выполнить какую-то конкретную «работу». Продукт не совпадает с человеком или его особенностями, но совпадает с проблемами, которые он решает.

Конечно, идея строить продукт вокруг проблемы совсем не нова (собственно, и JTBD существует уже больше 30 лет, но применялся преимущественно в производстве физических продуктов). JTBD просто дает удобный фреймворк и инструментарий для работы, вот и всё. Но разница в организации команды, в построении стратегии и разработке фич — огромная.

Даже если вы не эксперт в UX, то наверняка встречали такой шаблон:

В сущности это и есть user story — то есть какое-то краткое описание фичи со стороны пользователя. <Type of user> обычно основывается на одной из ваших персон. Про персон можно подробнее почитать здесь. Если вкратце: вы проводите user researches, анализируете онлайн-данные и создаете несколько (стандартно пять-шесть) собирательных пользователей, которые представляют ключевые сегменты вашей аудитории.

Честно, я несколько раз пыталась использовать персон и user stories в работе, но постоянно сталкивалась с одними и теми же проблемами.

Какие-то аспекты и вовсе могут сбить с толку: к примеру, мы делаем фичу «поделиться в соцсетях» для новостного сайта. То, что наша персона работает врачом, должно как-то повлиять на разработку фичи, должны ли мы это как-то учесть? Вот здесь у меня, например, начиналась трансформация what в why: а зачем вообще кому бы то ни было делиться нашими новостями в соцсетях? Что движет пользователем, какая у него мотивация? И, как ни странно, многие персоны при ответе на этот вопрос объединялись в одну группу.

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

Таким образом, мы плавно подошли к job stories, которые Intercom и изобрели. И смысл в том, что фокус с персональных характеристик тут смещается на контекст:

Разберем теперь более подробно, как составлять job story.

Например, у нас есть спортзал, где мы хотим увеличить продажи месячных абонементов. Сначала посмотрим на персон (описание довольно условно, в реальности оно более подробно и детализировано):

В каком случае такие описания будут нам полезны? Например, для таргетированной рекламы. Хотим мы привлечь больше Маш или Никит — пожалуйста: устанавливаем настройки кампании в соответствии с определенными характеристиками наших персон и ждем.

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

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

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

Вот пример job story, который мог бы случиться:

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

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

Легче всего это понять на примере Uber. Вроде как здесь-то уж точно есть две конкретные персоны: водитель и пассажир. На самом же деле, эта характеристика лишь часть контекста: в зависимости от ситуации водитель может оказаться на месте пассажира, и наоборот.

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

Персоны, безусловно, гораздо лучше, чем ничего. Более того, многие успешные компании до сих пор работают с этим фреймворком и прекрасно себя чувствуют. В любом случае, job stories — это лишь ещё один хороший способ с другой стороны взглянуть на свой продукт.

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

Допустим, мы прониклись и хотим написать хорошую job story. С чего начать? Конечно, с исследования.

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

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

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

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

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

До нового спортзала был предыдущий спортзал. До предыдущего спортзала была зарядка на коврике по утрам. До коврика были бургеры и мороженое в McDonald’s (это уже непрямая конкуренция, о ней дальше).

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

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

Если ваш продукт делает слишком мало, в глазах пользователя он не стоит того, чтобы его устанавливать (и, тем более, платить за него). Если продукт делает слишком много, он вступит в конфликт с уже существующими элементами workflow, которые вполне устраивают пользователя.

Так где же золотая середина? Давайте разберем на простом примере. Допустим, вы пишете приложение-будильник, в этом случае workflow может выглядеть так:

«Работа» вашего продукта должна начинаться с того шага, где вы можете добавить какую-то ценность для пользователя. Для нашего примера это, скорее всего, шаг номер 3. Мы, конечно, можем влезть и раньше: например, если пользователь обычно встает в 7:00, а уже 12:00 вечера, и телефон активен, наше приложение отправит напоминание: «А не хотите ли поставить будильник и пойти спать?».

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

Нужно ли это? Испытывает ли пользователь «нужду», соответствующую масштабам исследований и разработки? Это и нужно понять и решить продуктовой команде в самом начале.

Когда «работа» должна заканчиваться:

Какое-то время назад я писала про компанию BVG, которая де-факто монополист в сфере общественного транспорта в Берлине. BVG тратит огромные деньги на рекламу. Вопрос: зачем она это делает, если и так все метро, автобусы и трамваи принадлежат исключительно ей?

Если посмотреть на этот вопрос с точки зрения JTBD, ответ придет сам собой. «Работа» пользователя в этом контексте — добраться из точки А в точку Б, а не воспользоваться общественным транспортом. И тут BVG оказывается никаким не монополистом, а лишь одним из участников рынка наравне с:

JTBD позволяет шире посмотреть на проблемы пользователя и выявить ваших настоящих конкурентов.

С прямой конкуренцией всё понятно. Но есть ещё один вид конкуренции, о котором все забывают.

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

Прямая конкуренция — соперничество за «работу». Непрямая конкуренция — соперничество за «результат».

Вот этот outcome нам и важно определить. В этом контексте Skype, например, соперничает с полетами бизнес-классом, потому что «результат» у них один — провести бизнес-встречу. Возвращаясь к бургерам и спорту, «результат» может быть: «почувствовать себя счастливым и более уверенным» или «ощутить принадлежность к какой-то социальной группе».

Определение глобального «результата» вашего продукта помогает не только правильно позиционировать себя на рынке, но и работать с конкурентами. Чтобы двигаться вперед, вы должны либо сделать «результат» другого продукта менее привлекательным в глазах пользователя либо изменить позиционирование продукта, чтобы «результаты» больше не находились в конфликте.

В материале использован вольный перевод некоторых отрывков из книги Jobs-To-Be-Done от Intercom.

#Колонка