JTBD исследование, часть 2 — анализ и синтез

Dmitriy Kapaev
7 min readMar 29, 2024

Провели пачку JTBD-интервью, выписали заметки, а дальше что? Формулировать работы, job stories, заполнять канвасы? Пробуем, но получается разрозненная фигня и, как на ее основе принять решения по продукту — не понятно. В статье будем разбираться что с этим делать.

Сложности анализа и синтеза в JTBD

Сложность №1 — потребности людей (aka работы) выглядят по-разному в зависимости от области исследования. Переменных много, но вот пара примеров:

  1. принятие решения о том, чтобы посмотреть Ютьюб, происходит за секунды и на стыке двух контекстов: в какой траектории интереса находится человек (учиться кататься на сноуборде) + в какой он проблемной ситуации (едет в метро и хочет сделать этот скучный процесс более приятным).
  2. принятие решение о покупке нового авто длится месяцами, но в одном растянутом во времени контексте: у нынешнего авто 2 двери, а мы с женой ждем ребенка и ездить втроем на нем будет не удобно.

Если засунуть эти две потребности в один и тот же артефакт, то исчезнут их особенности.

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

Сложность №3 — артефакты JTBD плохо стыкуются друг с другом, потому что их создавали люди с разным взглядом на теорию, из разных концов света, под разные рабочие задачи. У них получились артефакты, которые работали в конкретных ситуациях, но попытка их переделать или соединить, зачастую, ломает их и усложняет нашу работу.

Как же быть?

Вместо того, чтобы городить супер-фреймворк, который нейтрализует все сложности, я предлагаю принять их за норму (а че так можно было?). Да, всё разное и нет никакого единого правильного процесса. И остерегайтесь тех, кто вам его предлагает, тк в 100% случаев этот супер-фреймворк будет обкрадывать исследование: мешать увидеть уникальность исследуемой области и заставит натягивать находки на артефакт. Вспомните саму суть JTBD — нет идеальных решений, но существуют решения, которые подходят лучше других для конкретных проблемных ситуаций.

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

Примеры артефактов для анализа и синтеза в JTBD

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

1) Описание одной важной работы с помощью сил прогресса и JTBD-канваса.

Что это: карточка, где описана одна работа с драйверами и барьерами. С помощью нее может быть описана работа вашего продукта, история переключения с одного продукта на другой или потребность в улучшении без привязки к конкретному продукту. Меняются Точка А и Б, а драйверы и барьеры описываются по отношению к ним.

Вариант 1 — JTBD-канвас без заморочек

Драйверы и барьеры не разбиты по категориям, нет критериев найма.

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

Вариант 2 — полноценный JTBD-канвас

Драйверы и барьеры разбиты на 4 силы прогресса, а из них вытекают критерии найма / требования к решениям. Описаны Точки А и Б, видно кто конкурент, у которого хотим отнять аудиторию.

Продукт “Сделано” — сервис, который делает ремонт квартир с фиксированными сроками и стоимостью. Описана работа потенциального пользователя “Сделано”, который рассматривает найм на работу “бригаду от знакомых”. Артефакт помогает понять как переключить пользователя со знакомого решения на новое.

Возможности артефакта:

  • Его достаточно для описания работ продуктов, которые выполняют одну или несколько работ.
  • Акцент на детальном описании драйверов и барьеров помогает увидеть точки роста для продукта в рамках работы.
  • Если описать драйверы и барьеры по отношению к конкурентам (точка А — конкурент, точка Б — наше решение), то можно легко ответить на вопрос: “как переключить пользователей с на наш продукт?”

Ограничения артефакта:

  • На каждую работу — канвас. Если работ много или они дробятся на отдельные проблемные ситуации, то описать их через мильон JTBD-канвасов будет сложно.
  • Каждый канвас строится относительно конкретных Точек А и Б. Например, у нашего продукта три конкурента и хотим увидеть какие драйверы и барьеры существуют для их пользователей по отношению к нашему продукту — придется описать 3 канваса для 1 работы.

2) Детализация проблемных ситуаций в рамках работы с помощью JTBD-матрицы.

Что это: таблица с 2 уровнями детализации работ: 1) конкретные проблемные ситуаций и 2) более абстрактного описания прогресса, который человек хочет получить в этих ситуациях.

Проблемные ситуации, как правило, легче описать с помощью Job story, а более абстрактный уровень работы с помощью JTBD Statement. Хотя, нет жестких правил на этот счет.

Про JTBD-матрицу есть отдельная статья.

Продукта еще нет, а в таблице описана одна из 5 работ, на которые нанимают конкурентов — платформы с видеоконтентом. Тут мы не описывали Job Stories.

Возможности артефакта:

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

Ограничения артефакта:

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

3) Описание облака работ.

Что это: майндмэп, который описывает структуру потребностей человека, в определенной области. Например, потребности предпринимателя в области взаимодействия с государством. Акцент на визуализации взаимосвязей работ друг с другом.

Вариант 1 — Черновик

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

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

Продукт: кассовый аппарат в смартфоне для микро-бизнеса. Первый набросок облака работ. Формулировки кривые-косые, описаны на гипотезах команды.

Вариант 2— Облако Job Stories

Описаны два уровня работ на основе исследований. Облако уже в выбранной области интереса команды — рабочие пространства. Job stories отмечены тегами сегментов пользователей и из них растут идеи фичей и продуктов.

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

Продукт: сеть коворкингов / смарт-офис. Общее видение продукта уже есть, но надо понять какие потребности продукт будет закрывать и какими фичами.

Возможности артефакта:

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

Ограничения артефакта:

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

Бонус: Описание работ через уникальную схему принятия решения.

Бывает, ни один фреймворк не подходит для того, чтобы описать потребность человека. Тогда приходится создавать новый. Ниже наша попытка ответить на вопрос “как пользователь выбирает что ему посмотреть на Ютьюбе?”.

Продукта еще нет, а на схеме описан процесс принятия решения о том, “что посмотреть”. Зеленые стикеры — работы, бледно-желтые — примеры конкретных проблемных ситуаций, описанные с помощью Job Story, оранжевые — идеи фичей.

Со временем стало ясно, что подобная схема применима в других маркетплейсоподобных продуктах, вроде Авито или Букмейта, где решение о найме принимается одновременно на уровне платформы и продукта платформы (Ютьюб и видео). Но до готового артефакта она пока не созрела.

Как прийти к своему артефакту?

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

👉 Больше про JTBD на курсе.

Больше про фреймворки, продуктовые исследования и сервис-дизайн в моем Телеграм-канале.

Есть вопрос? Пишите в Телеграм.

--

--