Давайте разбираться в этом вашем JTBD

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

JTBD (Jobs to be Done, или «Работа, которую нужно выполнить») — концепция, впервые представленная профессором Гарвардской школы бизнеса Клейтоном Кристенсеном в книге «The Innovator’s Solution». Согласно этой теории, люди приобретают продукты не ради обладания ими, а для решения конкретных задач. Фокус смещается с функций продукта на цели клиента: пользователи «нанимают» продукт для выполнения определенной работы. Это позволяет глубже понять мотивацию клиентов при покупке и ожидания от продукта

Теория отлично раскрывается в классическом кейсе «Job» of McDonald’s Milkshake.

Jobs-as-Activities (работа как процесс), теорию разработал Энтони Ульвик: подход концентрируется на конкретных задачах в процессе взаимодействия пользователей с продуктом. Подход Jobs-as-Activities описывает процесс или последовательность действий, которые предпринимает человек, чтобы достичь цели.

Jobs-as-Progress (работа как прогресс), теорию разработали Клэйтон Кристенсен, Боб Моэста, Алан Клемент: этот подход фокусируется не столько на действиях, сколько на прогрессе пользователя. Подход Jobs-as-Progress описывает изменения или улучшения, которые клиент пытается получить с помощью продукта — тут важен конечный результат или желаемое состояние пользователя.

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

Если присмотреться внимательнее, можно заметить, что уровень программ соответствует формированию работ по подходу Jobs-as-Progress, а уровень последствий — подходу Jobs-as-Activities. Хотя оба подхода связаны, они фокусируются на разных аспектах: один на достижении прогресса (программа), другой — на конкретных действиях (последствия).

Понимание разницы между Jobs-as-Progress и Jobs-as-Activities позволяет балансировать между тактическими улучшениями интерфейса и стратегическими целями пользователей.

В проектах мы чаще используем подход Jobs-as-Progress, так как он лучше объясняет, почему пользователи переходят с одного продукта на другой, а также эффективен для генерации новых идей. Jobs-as-Activities используем реже, поскольку в этом подходе акцент на конкретных действиях или решениях, что увеличивает риск упустить реальную задачу, для которой продукт был «нанят».

Ключевые инструменты JTBD — Job Statement и Job Story — помогают понять, почему пользователь «нанимает» продукт, и какую задачу стремится решить с его помощью. Новички часто путают эти инструменты с User Story, Use Cases и User Flow. Причина проста: все они так или иначе связаны с задачами пользователя. В результате возникает путаница — где, когда и как использовать каждый из инструментов?

Прежде чем углубиться в Job Statement и Job Story, разберёмся в особенностях каждого инструмента и сравним их между собой для наглядности.

Job Statement — это изменение к лучшему (мотивация), на которое рассчитывает пользователь в определенных обстоятельствах (контекст).

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

Job Statement и Job Story используют продуктовые команды на этапе Discovery для выявления задач пользователей и генерации идей. На этапе Delivery они помогают сопоставить фичи из бэклога с пользовательскими задачами и триггерами их возникновения. Так команда разработки понимает, почему фича появилась в бэклоге.

Job Statement лучше применять, когда важно быстро зафиксировать задачу, которую пользователь хочет решить (мотивация), и понять триггер её возникновения (контекст), без углубления в детали о конечной цели пользователя (ожидаемый результат/прогресс)

Job Story целесообразнее использовать, когда нужно глубже разобраться в мотивации пользователя и ответить на вопрос — почему клиенту важно решить эту задачу (ожидаемый результат/прогресс).

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

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

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

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

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

📎 Шаблон гайда и сборник вопросов для интервью по JTBD

Мы будем рассматривать формулировки в рамках подхода Jobs-as-Progress и инструмента Job Story, так как чаще используем их в проектах.

Хорошая Job Story в подходе Jobs-as-Progress не должна содержать конкретного решения.

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

Job Story будет сформулирована корректно, если для неё можно «нанять» разные продукты или решения. В примере справа такими решениями могут быть кредит, займ у друзей или продажа активов.

Небольшой лайфхак от нашей команды: для проверки корректности формулировок можно трансформировать Job Story в вопрос HMW (How Might We — «как мы можем помочь»).

Не все работы требуют немедленно выделять внимание или ресурсы. Чтобы определить, какие задачи взять в детальную проработку, нужно расставить приоритеты. Одним из действенных методов будет опрос с использованием шкалы Лайкерта.

Пользователям демонстрируют Job Story и просят оценить её по двум критериям: важность и удовлетворённость.

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

Затем пользователи оценивают утверждение по следующим параметрам:

Полученные результаты необходимо наложить на канвас

📎 Канвас «Приоритизация JTBD»

Недообслуженные работы (Under-served Jobs) – это основной фокус в стратегии роста. Они предоставляют возможности для улучшения существующих решений, чтобы в полной мере удовлетворять потребности клиентов.

Переобслуженные работы (Over-served Jobs) используются для подрывной стратегии. Компании предлагают более простые и доступные решения, которые могут привлечь новую аудиторию, не удовлетворенную сложными или избыточными функциями продуктов.

Обслуженные работы (Well-served Jobs) — здесь существующие решения уже эффективно удовлетворяют потребности клиентов. Дополнительные улучшения или изменения не приведут к мощному росту или привлечению новой аудитории, так как рынок уже насыщен.

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

Теория JTBD может показаться простой, а её инструменты — лёгкими для понимания. Но чтобы они действительно приносили пользу, важно разобраться в тонкостях их применения. В статье мы рассмотрели два классических подхода: Jobs-as-Activities и Jobs-as-Progress, и показали, как каждый из них решает разные задачи. Мы объяснили, почему Jobs-as-Progress помогает лучше понять глубинные цели пользователей и создавать решения, которые клиенты действительно будут «нанимать» для выполнения своих задач

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

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

Над материалом работали:

Чтобы ничего не пропустить, следи за развитием цифры вместе с нами: