JTBD framework: как применять на практике

Зачем JTBD вообще существует

Классический сюжет: команда смотрит на демографию пользователей и видит «женщины 25–34 из крупных городов». Делает фичу для них, фича не взлетает. Потому что в реальности эта женщина пользуется продуктом не потому, что ей 28, а потому что она в 7 утра ищет, чем заняться в метро по дороге на работу.

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

Главная польза JTBD — формулировать продуктовые решения через задачу пользователя, а не через демографию или фичи.

Job-stories: формат записи

Канонический формат, который придумали в Intercom:

Когда [ситуация],
я хочу [мотивация],
чтобы [ожидаемый результат].

Пример:

Что важно:

• Ситуация — конкретный триггер, не «когда я хочу учиться».
• Мотивация — что именно человек делает, не «использует ваш продукт».
• Результат — то состояние, к которому он стремится, не фича.

Если из job-story можно убрать упоминание продукта и она останется осмысленной — она написана правильно. Если без продукта она разваливается — это user-story, замаскированная под JTBD.

Чем JTBD отличается от персон

Персоны: «Аня, 27, дата-аналитик, любит подкасты, работает в стартапе». На основе персон сложно принимать решения — что именно делать, если у Ани плохое настроение?

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

Не «персоны плохие». Скорее, JTBD и персоны решают разные задачи:

• Персоны — про эмпатию, про дизайн, про коммуникацию.
• JTBD — про функциональные решения, про сегментацию метрик, про приоритизацию.

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

Как добывать джобы

Никакая job-story не пишется в кабинете. Чтобы получить настоящие джобы, нужно говорить с пользователями. Базовая методология — switch-интервью.

Идея: расспрашивать тех, кто недавно перешёл на ваш продукт (или с него ушёл). Восстанавливать таймлайн:

1. Когда впервые задумались, что нужно решение?
2. Что попробовали раньше? Почему не подошло?
3. Что стало последней каплей, чтобы попробовать новое?
4. Что изменилось после перехода?

Из 6–8 интервью обычно вылезают 2–3 повторяющиеся джобы. Их и закрепляем как основные.

Альтернативные источники: разборы поддержки, отзывы в сторах, интервью с теми, кто отвалился. Только не опросы со шкалой 1–5 — там джобы не достают.

Пример для Telegram-приложения

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

1. Срочное повторение перед собесом. Когда у меня собес через 3 дня и я последний раз писал SQL месяц назад, я хочу за вечер прорешать ключевые задачи, чтобы освежить синтаксис.
2. Поддержание формы между поиском работы. Когда я работаю и не активно ищу, я хочу 10 минут в день держать форму, чтобы не растерять навык за полгода.
3. Системная подготовка с нуля. Когда я только перехожу в аналитику, я хочу пройти от базы до сложных задач за пару месяцев, чтобы пройти первый собес.

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

Частые ошибки

• JTBD как переименование user-story. «Как пользователь, я хочу чёрную тему, чтобы было удобно ночью». Это user-story с косметикой. Настоящая джоба — про результат, не про фичу.
• Слишком абстрактно. «Я хочу быть успешным» — это не джоба, это жизненная цель. Джоба — конкретная ситуация и конкретный результат.
• Слишком узко. «Когда я нажал на кнопку X, я хочу видеть Y». Это сценарий внутри продукта, не джоба.
• Один продукт — одна джоба. Почти всегда у продукта 2–4 джобы. Если у вас одна — вы их недокопали.
• JTBD без интервью. Сидя в кабинете нельзя угадать, в какой ситуации нанимают продукт. Это всегда полевая работа.

Связанные темы

• Kano-модель в продукте
• HEART framework Google
• RICE приоритизация
• AARRR пиратские метрики

FAQ

Сколько джоб должно быть у продукта?

Обычно 2–4 основные. Если меньше — скорее всего, не докопали. Если больше — продукт распыляется или вы смешиваете джобы и сценарии.

JTBD заменяет персоны?

Нет. JTBD про функциональную задачу, персоны про эмоции и контекст. В зрелых командах используют обе модели.

Можно ли получить джобы из аналитики?

Частично. Аналитика покажет паттерны поведения и сегменты, но не объяснит «зачем». Без интервью не обойтись.

Что такое switch-интервью?

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

JTBD подходит для B2B?

Да. В B2B джобы часто относятся к роли, а не к человеку: джоба руководителя продаж — закрыть план месяца, джоба специалиста — быстрее обрабатывать заявки.

Как использовать джобы в приоритизации?

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

---

Готовитесь к собесу на продакта или аналитика? Откройте Карьерник — 1500+ вопросов по продуктовой аналитике, метрикам и фреймворкам.