JTBD (Jobs To Be Done)

Определение

JTBD (Jobs To Be Done) – подход, в котором клиент не покупает продукт, а нанимает его на работу. Задача описывается формулой job story: когда возникает ситуация, я хочу сделать действие, чтобы получить результат.

3 мин 44 Обновлено 14 сентября

JTBD, Jobs To Be Done – взгляд на покупку как на найм. Человек не покупает продукт, а нанимает его, чтобы выполнить свою работу: закрыть въезд так, чтобы зимой не разгребать снег у ворот, или сдать объект в срок без замечаний. Подход связывают с Клейтоном Кристенсеном, и его главная ценность – смена вопроса. Вместо "кто наш клиент" вы спрашиваете "на какую работу нас нанимают и кого нанимают вместо нас".

Как это работает

Работу описывают короткой формулой – job story. Она состоит из трёх частей: ситуация, желаемое действие и результат.

Когда происходит ситуация, я хочу сделать что-то, чтобы получить результат.

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

У любой работы три составляющие, и продукт нанимают на все три сразу.

Три составляющие работы клиента
СоставляющаяО чём онаКак проявляется на сайте
ФункциональнаяЧто физически нужно сделатьХарактеристики, комплектации, расчёт, сроки монтажа
ЭмоциональнаяЧто человек хочет чувствовать или перестать боятьсяГарантия, открытая команда, описание контроля работ
СоциальнаяКак он хочет выглядеть в глазах другихПортфолио объектов, эстетика решений, отзывы

Формулировки работ берут не из головы, а из разговоров с клиентами по методике CustDev: в рассказе о реальной покупке работа всегда звучит, её нужно только услышать и записать словами человека.

Работы бывают разного размера, и путать их не стоит. Большая работа звучит как "обустроить въезд на участок и забыть о нём надолго", маленькая – как "понять бюджет до разговора с менеджером". Большая определяет продукт и позиционирование, маленькая – конкретный элемент сайта: калькулятор, фильтр, форму записи в шоурум. В работе полезно держать обе.

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

JTBD и портреты-персоны: разные основания
ПризнакJTBDПерсоны
Единица описанияРабота, на которую нанимают продуктТипичный представитель аудитории
Что берётся за основуСитуация и желаемый результатДемография, должность, привычки
Кто конкурентЛюбой способ сделать ту же работуКомпании из той же отрасли
Что даёт для сайтаАргументы под конкретный момент выбораТон и общее представление о клиенте

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

Зачем это нужно

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

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

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

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

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

Пример

В проекте для дилера ALUTECH – кейс "Колибри" – разбор задач по логике JTBD шёл вместе с CJM и CustDev-инсайтами, после деления аудитории на B2C и B2B.

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

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

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

Если нужно понять, на какую работу нанимают ваш продукт, и перестроить под это сайт – напишите мне.

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

Что такое JTBD простыми словами?

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

Как правильно сформулировать job story?

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

Чем JTBD отличается от персон и портретов аудитории?

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

Кто считается конкурентом в логике JTBD?

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

Откуда брать формулировки работ?

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

Три составляющие работы – зачем они нужны?

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

Как понять, что работа выполняется не до конца?

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

44

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

Материалы по теме

Что почитать дальше по этой теме

Инструкция Уведомления о заявках с сайта в MAX: что нужно для подключения Что нужно, чтобы заявки с сайта приходили в MAX: верифицированная организация, модерация бота, токен из веб-версии и группа для заявок. Плюс разбор для разработчика. 7 мин 219 4 октября 2026 Статья Что боты находят на сайте, а вы – нет Боты ходят по изнанке сайта, куда живой человек не забредёт, и фиксируют в логах то, чего не видно ни в Метрике, ни на витрине: падающие с ошибкой 500 страницы каталога, битый файл с 747 обращениями, поток сканеров секретов. Разбираю на реальных логах, что искать и как чинить. 7 мин 436 22 июля 2026 Инструкция Как выгрузить и читать access-логи, если хостинг хранит их три дня Access-лог (журнал обращений к серверу) – единственное место, где виден весь трафик сайта, включая ИИ-ботов, которых не замечают счётчики. Разбираю на практике: где взять логи, как не потерять их из-за ротации, какие команды показывают ботов, ошибки и подозрительную активность. 7 мин 431 21 июля 2026 Флагманский гайд ИИ-анализ email-обращений: методика на стыке Яндекс.Метрики и Claude Code Классический email-трекинг отвечает на вопрос "откуда пришло обращение". ИИ-слой отвечает на вопросы, которые раньше требовали ручного аналитика: значим ли email на фоне звонков, форм и мессенджеров, почему один источник даёт качественные обращения, а другой – пустые, какие сегменты визитов предшествуют письму, что написать в ответ с учётом пути пользователя. Здесь – как я собираю это на уже имеющемся стеке: Logs API Метрики, PostgreSQL и Claude Code, без новых платных сервисов. 11 мин 458 26 мая 2026 Флагманский гайд Майкор: ИИ-аудит проекта по 4 точкам контакта Майкор – это перекрёстный ИИ-аудит проекта в 4 точках контакта: сайт, контекстная реклама, ИИ-поиск и Яндекс.Карты. Я анализирую каждую систему и смотрю связки между ними – где маркетинг рассказывает одно, реклама ведёт на другое, а ИИ-системы цитируют третий номер телефона. В одном из моих аудитов медицинской клиники в Москве у организации в индексе ИИ-сервисов оказалось 6 разных номеров и всего 7 упоминаний на 64 проверочных запроса – при том, что в обычной выдаче Яндекса клиника была в топ-1. Майкор закрывает такие разрывы за один аудит вместо четырёх раздельных. 16 мин 744 13 мая 2026