JTBD framework: Jobs to Be Done в продуктовой работе

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

Концепция оформилась в работах Клейтона Кристенсена в начале 2000-х, затем была развита Тони Ульвиком в методологию Outcome-Driven Innovation. Сегодня JTBD используется крупными технологическими компаниями для исследования рынка, позиционирования, проектирования продуктов и принятия решений о портфеле. Подход не заменяет другие методы продуктовой работы, но даёт дополнительную линзу, через которую видны вещи, скрытые от классических методов.

Истоки JTBD

Кристенсен в книгах The Innovator’s Dilemma и Competing Against Luck сформулировал базовый принцип: люди не покупают продукт — они нанимают его для выполнения работы в своей жизни. Если продукт перестаёт справляться с этой работой, его «увольняют» в пользу другого, не обязательно конкурирующего напрямую.

Знаменитый пример из исследования Кристенсена — молочный коктейль McDonald’s. Анализ показал, что половина продаж приходится на ранние утренние часы, когда коктейль покупают одиночные посетители навынос. Опросы выявили причину: коктейль «нанимают» как способ скрасить долгую поездку на работу за рулём. Конкурентами оказались не другие напитки, а бананы, бейглы и шоколадные батончики — другие продукты для той же работы.

Этот вывод имел практические последствия: чтобы увеличить продажи, McDonald’s требовалось не делать коктейль вкуснее или дешевле, а сделать его удобнее для потребления одной рукой за рулём, насыщающим, занимающим достаточно времени. Никакие демографические исследования или функциональные требования не привели бы к этим выводам.

Что такое job

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

Структура job statement

Стандартная формулировка работы по Ульвику:

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

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

Эта формулировка независима от конкретного решения. Job существует в жизни пользователя задолго до того, как появился продукт его решающий, и продолжит существовать после того, как продукт исчезнет. Айфон, бумажная карта и личный шофёр — разные решения для одной job «попасть туда, куда нужно, в незнакомом городе».

Уровни и стороны job

Работа имеет несколько слоёв, которые методология называет сторонами.

Functional job

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

Emotional job

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

Social job

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

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

JTBD-интервью

Главный исследовательский метод JTBD — глубинное интервью с пользователями, которое восстанавливает контекст принятия решения о покупке или выборе продукта. Это не общий разговор о продукте, а реконструкция конкретного случая «найма» в недавнем прошлом.

Switch interview

Базовая техника, разработанная Бобом Мьестой и Крисом Споком на основе работ Кристенсена. Цель — восстановить временную линию решения о смене продукта или способа решения задачи.

1. First thought: когда пользователь впервые подумал, что что-то нужно изменить
2. Passive looking: фаза неактивного изучения вариантов
3. Active looking: момент перехода к активному поиску решения
4. Deciding: процесс выбора конкретного решения
5. Consuming: первое использование
6. Satisfied/dissatisfied: оценка результата

Интервью занимает 60–90 минут и идёт глубоко в детали: что вы делали, что чувствовали, кого спрашивали, какие альтернативы рассматривали, что в итоге убедило. Цель — найти push-факторы (что выталкивало из старой ситуации) и pull-факторы (что привлекало к новому решению), а также anxieties и habits, мешавшие переходу.

Силы прогресса

Боб Мьеста сформулировал модель Forces of Progress — четыре силы, действующие на пользователя в момент принятия решения о смене.

Сделка происходит, когда push + pull превышает anxiety + habit. Продакт-менеджеру эта модель даёт чёткую структуру для понимания барьеров и драйверов покупки. Усилить push (через маркетинг проблемы) или pull (через демонстрацию выгод) — одна стратегия. Снизить anxiety (через гарантии, trial, кейсы) — другая. Преодолеть habit (через миграционные инструменты, обучение) — третья.

Outcome-Driven Innovation (ODI)

Тони Ульвик в Strategyn развил JTBD в более формализованную методологию ODI. Ключевая идея — рассматривать job как набор desired outcomes (желаемых результатов), которые можно измерять и приоритизировать.

Структура desired outcome

Каждый outcome формулируется по схеме:

[Минимизировать/Максимизировать]
[Метрика, что измеряется]
[в процессе/состоянии]

Примеры:

• «Минимизировать время на ввод данных карты при оформлении заказа»
• «Минимизировать риск ошибки при выборе размера одежды»
• «Максимизировать вероятность найти подходящего исполнителя в нужный срок»

Полная job состоит обычно из 50–150 outcomes — детальной карты всех аспектов работы, которые важны пользователю. Эта карта стабильна во времени: фундаментальные потребности при выполнении работы меняются медленнее, чем технологии решения.

Opportunity scoring

ODI использует количественный метод приоритизации outcomes. Пользователей опрашивают по каждому outcome о двух параметрах:

• Importance: насколько важен этот результат (по шкале 1–10)
• Satisfaction: насколько удовлетворяет текущее решение (по шкале 1–10)

Opportunity Score рассчитывается по формуле:

Opportunity = Importance + max(Importance - Satisfaction, 0)

Outcome с высокой важностью и низкой удовлетворённостью получает высокий opportunity — это незакрытая возможность для продукта. Outcome с высокой важностью и высокой удовлетворённостью — overserved, его улучшение не даст эффекта. Outcome с низкой важностью — нерелевантен.

Этот количественный подход даёт продуктовой команде объективные данные для приоритизации, защищающие от субъективных предпочтений и моды.

JTBD vs персоны

Персоны и JTBD часто противопоставляют, хотя они отвечают на разные вопросы.

Персоны полезны для дизайна интерфейса, маркетинговых коммуникаций, выбора tone of voice. JTBD полезны для определения границ рынка, открытия новых ниш, понимания конкуренции. Зрелые команды используют оба подхода в комбинации.

JTBD vs user stories

User story в формате «As a [user], I want [action], so that [benefit]» поверхностно похожа на job statement, но решает другую задачу. User story описывает функциональное требование внутри backlog. Job описывает фундаментальную задачу пользователя на уровне рынка.

User stories живут в спринте и закрываются за дни. Jobs живут в продуктовой стратегии и определяют направление развития продукта на годы. Несколько user stories могут реализовывать одну job; одна user story не описывает job целиком.

Применение JTBD в продуктовом цикле

Discovery новых возможностей

JTBD-интервью с существующими и потенциальными пользователями выявляют underserved outcomes, для которых рынок не предлагает хорошего решения. Это места, где новый продукт или новая функция могут получить traction.

Позиционирование продукта

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

Дизайн интерфейса

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

Принятие решений о портфеле

Какие фичи строить, какие убирать, в какие сегменты идти — на эти вопросы JTBD даёт ответы через анализ underserved/overserved outcomes и identification адъяцентных работ.

Сегментация по работам

Традиционная сегментация делит рынок по демографии, отрасли, размеру компании. JTBD-сегментация делит рынок по выполняемой работе и по тому, как пользователь её выполняет. Это даёт принципиально разные ответы.

Пример: рынок проектного менеджмента. Демографическая сегментация выделяет «малый бизнес», «средний бизнес», «enterprise». JTBD-сегментация может выделить:

• Те, кто нанимает инструмент для «координации задач в команде разработки» (Linear, Jira)
• Те, кто нанимает для «организации работы клиентских проектов» (Asana, ClickUp)
• Те, кто нанимает для «отслеживания личных задач и проектов» (Todoist, Things)
• Те, кто нанимает для «совместной работы над документами и заметками» (Notion, Coda)

Эти сегменты пересекаются по демографии (все могут быть малыми бизнесами), но требуют разных продуктов. Маркетинг по работе точнее, чем маркетинг по размеру компании.

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

Job на уровне фичи

Формулировка вроде «когда я хочу отправить файл, я нажимаю кнопку send» — это не job, а описание интерфейса. Настоящая job существует вне продукта: «когда мне нужно передать большой документ удалённому коллеге так, чтобы он точно получил последнюю версию».

Игнорирование эмоциональной и социальной стороны

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

Поверхностные интервью

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

Применение только в discovery

JTBD часто используется как разовый исследовательский проект. Зрелые команды интегрируют подход в постоянный цикл: каждые несколько кварталов пересматривают карту outcomes, переопрашивают аудиторию, корректируют стратегию.

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

Известные кейсы применения

JTBD используется в крупных компаниях разных отраслей. Часть кейсов публична:

• Bosch — пересмотр продуктовой линейки бытовой техники через карту outcomes
• Intuit — изменение позиционирования TurboTax от налогового софта к «помощнику в финансовом стрессе»
• Pampers — сегментация рынка подгузников по работам, выполняемым родителями
• Microsoft — применение JTBD в Office 365 для понимания, как пользователи нанимают разные приложения
• Basecamp — публично описанная философия дизайна, основанная на JTBD

Часто задаваемые вопросы

Сколько интервью нужно для JTBD-исследования

Качественная фаза — 10–15 глубоких интервью на сегмент. К этому количеству обычно достигается насыщение — новые интервью повторяют уже известные паттерны. Количественная фаза для opportunity scoring требует выборки в 200–400 респондентов для статистической значимости.

Подходит ли JTBD для B2B

Да, и даже лучше, чем для B2C. В B2B покупка обычно осознанная, с явной мотивацией решить рабочую задачу — это идеальная почва для JTBD-анализа. Усложнение в том, что покупатель и пользователь могут быть разными людьми с разными работами: руководитель «нанимает» инструмент для одной задачи, а сотрудники используют для другой.

Можно ли применять JTBD без формального обучения

Базовое применение — формулировка job statements, простые интервью — доступно после прочтения 1–2 книг и пары попыток. Глубокая методология ODI и количественный анализ outcomes требуют обучения. Это нормально: даже базовое мышление в категориях JTBD заметно улучшает продуктовые решения.

Чем JTBD отличается от Design Thinking

Design Thinking — это процесс работы над продуктом (empathize → define → ideate → prototype → test). JTBD — это способ думать о пользователе и задаче. Они совместимы: JTBD можно использовать в empathize и define фазах Design Thinking как способ структурировать понимание пользователя.

Стоит ли отказаться от персон в пользу JTBD

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

Как защитить выводы JTBD от субъективности

Через комбинацию методов: качественные интервью дают понимание, количественные опросы — статистическую значимость. Использование стандартных формулировок outcomes и opportunity scoring снижает интерпретативность. Регулярное переопрос аудитории показывает, как меняются работы со временем.

Заключение

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

JTBD не заменяет другие продуктовые методики, но дополняет их сильной аналитической линзой. Освоение требует практики глубинных интервью, дисциплины формулирования job statements и регулярного применения в продуктовых решениях. Окупаемость наступает через несколько циклов: команда начинает видеть рынок и пользователей точнее, продуктовые решения становятся обоснованными, маркетинг — точнее адресует реальные мотивации. Для зрелых продуктовых команд JTBD становится одним из основных инструментов стратегического мышления.