JTBD (Jobs to Be Done): что это, примеры job story и проверка на данных

Коротко

JTBD (Jobs to Be Done, «работы, которые нужно выполнить») — подход, в котором продукт рассматривают как исполнителя: человек «нанимает» его, чтобы в определённой ситуации получить нужный результат.

• Единица анализа — работа: ситуация, мотивация и ожидаемый результат. Возраст, должность и город в неё не входят.
• Работу записывают в формате job story: «Когда …, я хочу …, чтобы …».
• Один человек нанимает продукт на разные работы, а одну работу выполняют люди из разных демографических групп.
• Работы находят в интервью. Данные показывают, какие сценарии встречаются и сколько в них людей, но не объясняют мотив.
• Из работы выводят метрику успеха и определение активации: пользователь активирован, когда работа впервые выполнена.
• На учебной базе 30,5% пользователей только открывают приложение, и платят они реже остальных: 15,5% против 21,6%. Большую часть этого разрыва объясняет состав каналов.

JTBD: что это простыми словами

В основе JTBD одна мысль: люди покупают не продукт, а продвижение в своей задаче. Дрель нужна ради отверстия, отверстие — ради полки, полка — ради порядка в комнате. Конкурентом дрели оказывается не только другая дрель, но и мастер по вызову, и клейкие крючки.

Термин закрепил Клейтон Кристенсен, профессор Гарвардской школы бизнеса. О работах он писал ещё в книге The Innovator's Solution (2003, с Майклом Рейнором), а развёрнуто изложил теорию в 2016 году: в статье в Harvard Business Review и книге Competing Against Luck с Тэдди Холлом, Карен Диллон и Дэвидом Дунканом. Его главный довод направлен против корреляций: то, что покупателю от 18 до 35 и у него высшее образование, не заставляет его купить продукт. Причина покупки — работа, которая у него возникла.

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

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

У JTBD несколько направлений, и они спорят между собой. Энтони Ульвик с 2002 года развивает Outcome-Driven Innovation: работу раскладывают на шаги, для каждого выписывают желаемые результаты и в количественном опросе измеряют, насколько результат важен и насколько люди довольны текущими решениями. Важное и плохо закрытое считается возможностью. Боб Моэста, участвовавший в истории с коктейлем, делает упор на момент переключения: в интервью восстанавливают, как человек пришёл к покупке, что толкало его прочь от старого решения, что притягивало к новому и какие тревоги и привычки удерживали. Для аналитика различие практическое: школа Ульвика даёт опросные числа, школа Моэсты — хронологию решения.

Job story: формат и пример

Job story — запись работы одной фразой из трёх частей. Формат описал Алан Клемент в 2013 году в статье о замене пользовательских историй; саму идею он приписывает команде Intercom. В user story главное — роль («как менеджер, я хочу…»). В job story роли нет, вместо неё ситуация: она объясняет, почему потребность возникла именно сейчас.

Плохая job story выглядит так: «Когда я работаю с отчётами, я хочу экспорт в Excel, чтобы выгружать данные». Ситуация годится для любого дня, во второй части стоит готовая функция, а третья её пересказывает. Из такой записи нельзя понять, что произойдёт, если экспорта не будет, и чем человек пользуется сейчас.

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

Простая проверка: уберите из фразы название функции. Если смысл пропал — это была не работа, а пожелание к интерфейсу.

JTBD и персоны: в чём разница

Персона отвечает на вопрос «кто этот человек», сегмент по демографии — «к какой группе он относится», работа — «что он пытается сделать и почему сейчас». Это разные инструменты, и ломаются они по-разному.

Персона удобна дизайнеру и маркетологу: понятно, каким языком писать и где показывать рекламу. Но придуманная за столом «Мария, 29 лет, маркетолог, любит йогу» не объясняет ни одного решения о покупке. Демографический сегмент легко посчитать, и он часто хорошо коррелирует с выручкой, только корреляция не говорит, что менять в продукте. Работа объясняет мотив, зато сама по себе не сообщает, сколько таких людей и как до них дотянуться.

В реальной команде эти инструменты используют вместе: работы задают, что строить и чем мерить успех, сегменты показывают размер и экономику, персоны помогают с тоном и каналами. Подробно о том, как делить аудиторию по признакам и где такое деление обманывает, — в статье о сегментации пользователей; о сегментах по давности, частоте и сумме покупок — в разборе RFM-анализа.

JTBD: примеры работ для учебного продукта

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

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

Вторая: «Когда результаты нужно показать человеку без доступа к сервису, я хочу получить файл, чтобы отправить его письмом». Её след — export_completed.

Третья: «Когда над одними цифрами работает несколько человек, я хочу, чтобы коллеги видели ту же версию отчёта, и нам не приходилось сверять файлы». Её след — invite_sent.

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

Из 4613 зарегистрированных пространство создали 2750 человек (59,6%), отчёт — 1775 (38,5%), приглашение отправили 1135 (24,6%), экспорт завершили 988 (21,4%). Уже это меняет разговор на планировании: работа «отнести цифры наружу», вокруг которой строился слайд из вступления, касается каждого пятого.

select
  event_name,
  count(distinct user_id) as users,
  round(100.0 * count(distinct user_id) / (select count(*) from users), 1) as share_pct
from events
group by event_name
order by users desc, event_name;

Как проверить работы на данных: сценарии и оплата

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

Картина такая. Самая большая группа — 1407 человек, 30,5%, — только открывает приложение. С командой работают 1135 (24,6%), собирают отчёт для себя 847 (18,4%), выносят наружу 742 (16,1%), ещё 482 (10,4%) остановились на пустом пространстве.

Теперь оплата. Первую оплату сделали 15,5% тех, кто только открывал приложение, и от 19,4 до 23,9% в остальных сценариях. Если объединить четыре активных сценария, получится 21,6% (694 из 3206) против 15,5% (218 из 1407). Между собой активные сценарии различаются на несколько пунктов, а погрешность каждой доли на группах такого размера — примерно ±2,5–4 п. п. Утверждать, что «командный» сценарий платит лучше «личного», по этим числам нельзя.

В таблице смешаны зрелые и свежие когорты: до первой оплаты в этой базе проходит от 3 до 20 дней, и августовские регистрации ещё не успели заплатить. Если оставить только тех, кто зарегистрировался по 9 августа, уровни вырастут (18,4% у открывающих, 21,7–28,8% у остальных), а порядок сохранится.

with flags as (
  select
    u.user_id,
    max(case when e.event_name = 'workspace_created' then 1 else 0 end) as has_workspace,
    max(case when e.event_name = 'report_created' then 1 else 0 end) as has_report,
    max(case when e.event_name = 'invite_sent' then 1 else 0 end) as has_invite,
    max(case when e.event_name = 'export_completed' then 1 else 0 end) as has_export
  from users as u
  left join events as e
    on e.user_id = u.user_id
  group by u.user_id
),
scenarios as (
  select
    user_id,
    case
      when has_invite = 1 then '1. работает с командой'
      when has_export = 1 then '2. выносит отчёт наружу'
      when has_report = 1 then '3. собирает отчёт для себя'
      when has_workspace = 1 then '4. создал пространство и остановился'
      else '5. только открывает'
    end as scenario
  from flags
)
select
  s.scenario,
  count(*) as users,
  round(100.0 * count(*) / sum(count(*)) over (), 1) as share_pct,
  count(p.user_id) as payers,
  round(100.0 * count(p.user_id) / count(*), 1) as paid_pct
from scenarios as s
left join payments as p
  on p.user_id = s.user_id
 and p.payment_type = 'first'
group by s.scenario
order by s.scenario;

Почему разрыв в оплате ещё не доказывает работу

Напрашивается вывод: кто не нашёл в продукте свою работу, тот не платит, значит, надо вести всех к первому отчёту. Прежде чем нести его команде, стоит проверить состав групп. В платном поиске только открывают приложение 491 из 1015 пришедших, то есть 48,4%, а в рекомендациях — 187 из 1037, 18,0%. Платный поиск при этом платит хуже всех каналов независимо от поведения.

Внутри каналов разрыв выглядит иначе. В органике «только открывающие» платят в 21,5% случаев против 24,1% у остальных — разница в пределах шума. В рекомендациях они платят даже чаще: 29,9% против 26,1%. Заметный разрыв остаётся в платном поиске (5,9% против 10,9%) и у партнёров (13,2% против 19,0%). Если пересчитать обе группы с одинаковым составом каналов — таким, как у всей базы, — получится 18,5% против 20,8%: разрыв сокращается с 6,1 до 2,2 п. п. Почти две трети исходной разницы собраны из того, что в «пассивной» группе больше трафика из слабого канала. Это тот же эффект состава, который разобран в статье о том, почему метрика обманывает.

Вторая проверка касается гипотезы о командной работе. Если приглашение коллег — след работы «смотреть в одни цифры вместе», логично ждать, что такие люди чаще берут командный тариф. Среди первых оплат у приглашавших тариф team выбрали 27 из 248 — 10,9%, у остальных 75 из 664 — 11,3%. Разницы нет. Либо приглашение не связано с командной работой так, как мы решили, либо тариф выбирают по другим причинам. Данные опровергли удобную гипотезу, и это полезный результат.

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

with active as (
  select distinct user_id
  from events
  where event_name <> 'app_open'
)
select
  u.channel,
  case when a.user_id is null then 'только открывает' else 'есть действия' end as behaviour,
  count(*) as users,
  count(p.user_id) as payers,
  round(100.0 * count(p.user_id) / count(*), 1) as paid_pct
from users as u
left join active as a
  on a.user_id = u.user_id
left join payments as p
  on p.user_id = u.user_id
 and p.payment_type = 'first'
group by u.channel, behaviour
order by u.channel, behaviour;

Что данные не покажут: зачем нужны интервью

Всё посчитанное выше отвечает на вопрос «что делают» и «сколько их». На вопрос «зачем» события не отвечают. По логам не видно, что человек делал до регистрации, от чего отказался, кто попросил у него отчёт и что случится, если он его не принесёт. Самая большая группа — 30,5% открывающих приложение без единого действия — в данных выглядит как пустота. Это могут быть люди, которые не поняли, с чего начать, люди, пришедшие посмотреть чужой отчёт, и люди, которым продукт не подошёл. У трёх причин три разных решения, и различить их можно только разговором.

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

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

Как из работы получить метрику успеха и активацию

Третья часть job story — «чтобы …» — и есть заготовка метрики. Вопрос к каждой работе один: по какому наблюдаемому признаку видно, что она выполнена, и как быстро.

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

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

Дальше метрики работ встраиваются в общую систему: главная метрика продукта отражает ценность для пользователя, а доли выполненных работ становятся её входными показателями. Как собрать такую систему — в материале про North Star и дерево метрик. Для нового продукта работа задаёт ещё и границы первой версии: в MVP входит ровно то, без чего одну выбранную работу не выполнить.

Типичные ошибки в JTBD

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

• Работа сформулирована как функция продукта. «Хочу экспорт в Excel» — решение. Работа описывает ситуацию и результат и остаётся верной, даже если экспорт заменить ссылкой.
• Слишком общая работа. «Хочу принимать решения на основе данных» подходит любому продукту и ничего не запрещает. Рабочая формулировка позволяет сказать, какую функцию делать не надо.
• Слишком мелкая работа. «Хочу нажать кнопку и скачать файл» — шаг сценария. У работы есть причина и последствия за пределами интерфейса.
• JTBD без интервью. Работы, придуманные командой на воркшопе, — это гипотезы о себе. Пока нет разговоров о реальных случаях, называть их работами пользователей рано.
• Подмена сегментов работами и наоборот. «Работа малого бизнеса» — сегмент с новой вывеской. А поведенческий сценарий из логов — ещё не работа: у одного и того же следа бывают разные мотивы.
• Один человек — одна работа. Тот же пользователь утром собирает отчёт для себя, а в пятницу выгружает сводку директору. Сценарии в расчёте взаимоисключающие только потому, что так удобнее считать.
• Разрыв в метрике между сценариями прочитан как причина. Сначала проверьте состав групп по каналам и зрелость когорт, затем — эксперимент.
• Работы записаны один раз и забыты. Конкуренты и привычки меняются: работа остаётся, а «нанимают» на неё уже другое решение.

Частые вопросы о JTBD

Итог

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

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