Иногда бывает, что компания идеально продумала продукт, потратила много денег на разработку и маркетинг, а в итоге столкнулась с низким спросом и плохими отзывами. Главная причина — не плохой продукт, а несоответствие между тем, что создает бизнес, и тем, что действительно нужно пользователям.
Все потому, что традиционные методы исследования рынка и сегментации не отражают аудиторию полностью. Не решают конкретных «болей» клиента и не учитывают контекст использования.
Чтобы делать востребованный и удобный продукт — стоит пользоваться методом Jobs To Be Done (JTBD). Что это за метод и как его использовать — рассказываем в статье.
Что такое Jobs To Be Done
Jobs To Be Done — это методология, которая помогает понять истинные причины покупки продуктов или услуг.
Суть JTBD проста: человек покупает продукт не ради самого продукта, а чтобы выполнить определенную «работу». Эта «работа» — задача, которую потребитель пытается решить в своей жизни. Иногда эта задача очевидна, например, «мне нужно быстро перекусить», а иногда не осознается самим человеком. Например, «я хочу чувствовать себя частью определенной социальной группы».
Подход JTBD отлично иллюстрирует цитата Теодора Левитта: «Людям не нужна дрель, им нужно отверстие в стене». Это значит, что производители дрелей конкурируют не только с другими производителями дрелей, но и с любыми альтернативными способами создания отверстий. А если копнуть глубже, то и с другими способами крепления предметов. Ведь людям нужна не сама дырка в стене, а возможность что-то повесить на эту стену.
И каждая из этих «работ» имеет свой контекст, свои критерии успеха и свои альтернативные решения.
Структура модели JTBD
Модель JTBD состоит из нескольких взаимосвязанных элементов:
- «Работа» — задача, которую пользователь хочет выполнить.
- Контекст, в котором возникает необходимость выполнить работу.
- Мотивация пользователя — почему он хочет выполнить работу.
- Ожидаемый результат — что пользователь стремится достичь.
- Ограничения и препятствия, которые мешают выполнению работы.
- Критерии оценки успешности выполнения работы.
Каждый элемент дополняет друг друга и помогает лучше продумать продукт, который действительно решает проблему человека.
В модели JTBD «работа» существует в трех измерениях, которые влияют на выбор продукта:
- Функциональное измерение — практическая задача, которую нужно выполнить. Например, «перевезти вещи из точки А в точку Б» или «получить информацию о погоде на завтра».
- Социальное измерение — как продукт влияет на восприятие человека другими людьми. Например, «выглядеть профессионально на деловой встрече» или «показать друзьям, что я разбираюсь в современных технологиях».
- Эмоциональное измерение — как человек хочет себя чувствовать при использовании продукта. Например, «чувствовать уверенность при публичном выступлении» или «испытывать спокойствие, потому что файлы надежно защищены».
Для наглядности рассмотрим модель JTBD на примере покупки кофе в кофейне. Кажется, что «работа» здесь простая — человек хочет выпить кофе. Но на самом деле товар выполняет больше «работ».
Функциональная работа:
- Получить заряд энергии и бодрости на утро.
- Утолить жажду напитком определенного вкуса.
Социальная работа:
- Найти место для деловой встречи в неформальной обстановке.
- Быть частью сообщества кофеманов.
Эмоциональная работа:
- Порадовать себя приятным ритуалом.
- Создать себе уютную атмосферу вне дома или офиса.
Одна и та же кофейня может выполнять разные «работы» для разных людей. Понимание этих различий помогает создать более точное позиционирование и улучшить клиентский опыт.
При этом один и тот же человек может нанимать разные продукты для одной и той же работы в зависимости от ситуации.
Например при желании попить кофе, человек может:
- В будни, когда он спешит на работу, использовать ближайшую кофейню с удобной функцией предзаказа через приложение.
- В выходные, когда у него есть время, посидеть в кофейне и поговорить с друзьями.
- Во время путешествия выбрать местную кофейню, чтобы попробовать что-то новое.
Такая сегментация помогает определить, когда и почему пользователи предпочитают ваш продукт альтернативам. И как сделать ваше предложение более привлекательным в конкретных ситуациях.
Допустим, вы разрабатываете приложение для управления задачами и понимаете, что основная «работа» ваших пользователей — быстро записать идеи и задачи и ничего не забыть. Тогда ваш приоритет — создать максимально быстрый и удобный интерфейс ввода задач и не распыляться на расширенные функции для организации и категоризации этих задач.
Шаблоны Job Story и User Story
Чтобы перейти от абстрактной модели JTBD к конкретным требованиям продукта, удобно использовать два формата — Job Story и User Story. Оба помогают определить «работу», которую пользователь хочет выполнить, в каком контексте и зачем.
Job Story. Фиксирует момент возникновения потребности, мотивацию пользователя и ожидаемый от продукта результат. Формат выглядит так:
Когда я [ситуация], я хочу [мотивация], чтобы [ожидаемый результат].
- «Когда я…» — описывает точный контекст или триггер: время, место, предшествующие событию.
- «я хочу…» — формулирует саму мотивацию, то, какую работу пользователь намерен выполнить.
- «чтобы…» — указывает на критерии успеха: каким должен быть итог, чтобы пользователь остался доволен.
Например, у кофейни может быть такой Job Story: «Когда я спешу на работу утром, хочу быстро оформить предзаказ через приложение и не опоздать на встречу».
User Story. Делает акцент на роли пользователя, его желаемом действии и бизнес-ценности. Формат выглядит так:
Как [роль пользователя], я хочу [действие], чтобы [цель/выгода].
- «Как…» — указывает на персону или сегмент, для которого вы создаете решение.
- «я хочу…» — конкретное действие или функцию, которую пользователь хочет совершить.
- «чтобы…» — выгода или польза, которую пользователь получит от выполнения действия.
Пример для таск-менеджера: «Как проектный менеджер, я хочу мгновенно добавлять новые задачи голосом, не отвлекаться от текущей работы и фиксировать идеи на ходу».
Job Story нужно использовать для понимания реального контекста, в котором у человека появляется потребность использовать продукт.
| Формат | Что помогает сделать | Когда использовать |
| Job Story | Зафиксировать контекст, триггер и мотивацию пользователя
Выявить боли и ограничения Определить критерии успешного результата |
– Когда и почему у пользователя возникает «работа»?
– Какие боли и ограничения нужно снять? – Как должен выглядеть идеальный результат? |
| User Story | Четко сформулировать, какую функцию или элемент интерфейса создаем и для кого
Показать ценность фичи и обосновать ее реализацию Оценить трудозатраты и приоритизировать бэклог |
– Перевести их в конкретные задачи для разработки
– Уточнить детали функции – Связать ее с бизнес‑выгодой |
Чем JTBD отличается от других методов
JTBD vs Персоны. JTBD помогает понять поведение пользователей намного лучше, чем традиционные демографические данные.
Вот в чем дело: персоны основаны на предположении, что люди с похожими демографическими характеристиками имеют похожие потребности. Но это не всегда так. Например, 35-летний программист из Москвы и 35-летний программист из Санкт-Петербурга могут использовать одно и то же приложение для совершенно разных целей.
JTBD фокусируется не на том, кто эти люди, а на том, чего они пытаются достичь. Это позволяет выявить глубинные мотивации, которые часто скрыты за демографическими показателями. Вместо подхода «наш продукт предназначен для женщин 25–34 лет с высшим образованием и доходом выше среднего», JTBD позволяет сказать «наш продукт помогает людям, которые хотят быстро приготовить здоровый ужин после долгого рабочего дня для семьи».
Такой подход показывает, что два совершенно разных по демографическим показателям человека могут покупать один и тот же товар или услугу для выполнения одной и той же «работы». И наоборот, два очень похожих по демографии человека могут использовать один продукт для совершенно разных целей.
JTBD vs. Customer Development. Customer Development (CustDev) — методология, которая помогает проверять гипотезы о пользователях и рынке через непосредственное общение с потенциальными клиентами. CustDev отвечает на вопрос «есть ли проблема, которую мы пытаемся решить, и готовы ли люди платить за ее решение?».
JTBD углубляется в контекст: «какую именно работу человек пытается выполнить и при каких обстоятельствах?» То есть JTBD исследует мотивацию и контекст использования продукта. А кастдев помогает найти проблему.
JTBD vs. feature-based approach. При разработке продукта команды часто начинают с вопроса: «Какие функции нам нужно добавить в продукт?» В итоге функции в приложение добавляют, но необходимости в них изначально не было.
Анализ по JTBD начинается с вопроса: «Какую работу пользователь пытается выполнить?» И только после ответа на вопрос команда определяет, какие функции действительно нужны для выполнения работы.
Например, вместо «давайте добавим интеграцию с календарем в наше приложение для заметок», подход JTBD предлагает сначала понять: «пользователи хотят организовать свои задачи по времени» и только потом решать, какая функция лучше всего поможет в этом.
| Сравнение | Фокус альтернативного метода | Фокус JTBD | Главное отличие |
| Персоны | Демографические характеристики (возраст, пол, локация и т. д.) | Цели и задачи, которые пользователь пытается решить | Выявление глубинных мотиваций вместо демографии |
| Customer Development | Есть ли проблема и готовы ли платить за ее решение | Контекст и мотивация выполнения конкретной «работы» | JTBD погружается в обстоятельства и триггеры выбора |
| Feature‑based approach | Какие функции добавить в продукт | Какая «работа» стоит за потребностью пользователя | Сначала понимание работы → потом подбор необходимых функций |
Подходы к методу JTBD
В методологии Jobs To Be Done есть 2 подхода, которые по-разному интерпретируют концепцию «работы». Jobs As Progress и Jobs As Activities.
Jobs As Progress
Подход фокусируется на том, что люди нанимают продукты для выполнения определенных функций в своей жизни. Ключевое внимание здесь уделяется конкретному результату, который человек хочет получить. Подход объясняет, почему потребители выбирают один продукт вместо другого.
Здесь важно понять:
- Текущее состояние человека, его проблемы и ограничения.
- Желаемое состояние, к которому он стремится.
- Препятствия, которые мешают ему достичь желаемого состояния.
Например, покупатель образовательных курсов стремится перейти из состояния «я недостаточно компетентен в своей области» в состояние «я уверенный профессионал с востребованными навыками».
Jobs As Activities
Подход концентрируется на том, как продукты помогают людям достигать прогресса в жизни — переходить из текущего состояния в желаемое, лучшее состояние.
Здесь внимание уделяется:
- Конкретным действиям, которые человек хочет выполнить.
- Шагам и процессам, через которые он проходит.
- Критериям успешного выполнения задачи.
Если вернуться к примеру с образовательными курсами, то с точки зрения Jobs As Activities человек хочет «быстро найти релевантную информацию по теме» или «эффективно практиковать новые навыки».
Дополнительно можно выделить еще одну модель — четырех сил. Эта модель включает:
- Толкающие силы — проблемы и боли, которые «выталкивают» человека из текущей ситуации и заставляют искать новое решение. Например, существующий продукт стал неудобным, дорогим или устаревшим.
- Притягивающие силы — преимущества и возможности, которые «притягивают» человека к новому решению. Например, новый продукт обещает сэкономить время или гарантирует лучший результат.
- Тревога от нового — опасения и риски, связанные с переходом на новое решение.
- Сила привычки — комфорт и безопасность, связанные с привычкой использовать старый продукт.
Чтобы человек сменил продукт, сумма толкающих и притягивающих сил должна превышать сумму тревоги и привычки.
Конкретный подход стоит выбирать в зависимости от типа продукта и бизнес-задач. Вот несколько рекомендаций:
Jobs As Progress подходит для новых продуктов. Он поможет понять мотивацию и жизненные цели потенциальных пользователей.
Jobs As Activities подходит для улучшения существующих продуктов. Он дает конкретные инсайты о том, как люди используют продукт сейчас и что можно улучшить.
Модель четырех сил стоит выбирать при разработке продуктов для B2B-сегмента и работе с конкурентами — корпоративные и постоянные клиенты особенно чувствительны к рискам и не любят менять привычки.
Для всех подходов дополнительно можно применять Job mapping. Этот фреймворк помогает понять, какую «работу» выполняет пользователь, выявить проблемы места и точки роста на каждом шаге.
Основные этапы Job Mapping:
- Старт. Триггер, запускающий «работу»: внешнее событие или внутреннее желание.
- Подготовка. Сбор информации и ресурсов для начала работы.
- Исполнение. Непосредственное выполнение ключевой задачи.
- Завершение. Достижение результата работы и ее оформление.
- Оценка результата. Субъективная и объективная оценка: насколько «работа» была успешна.
Пример Job Mapping для кофейни с предзаказом:
| Этап | Описание действия | Возможные улучшения |
| Старт | Открыть приложение и решить заказать кофе | Разместить кнопку «Предзаказ» на главном экране |
| Подготовка | Выбрать напиток, объём, добавить сироп или топпинг | Сохранение прошлых заказов, быстрые списки «Любимые» |
| Исполнение (заказ) | Оплатить и подтвердить время и место самовывоза | Интеграция Apple/Google Pay |
| Завершение (получение) | Забрать кофе в указанное время | Отображение статуса в реальном времени, QR‑код для сканирования |
| Оценка результата | Оценить вкус, скорость и удобство заказа | Короткий опрос в 2 клика, система бонусов за отзыв |
Виды конкуренции в контексте JTBD
Модель JTBD показывает, что у компаний есть 3 вида конкуренции:
- Прямая — привычное соперничество с продуктами, которые решают ту же проблему схожим способом. Например, для Spotify прямыми конкурентами являются Яндекс Музыка, YouTube Music и другие музыкальные стриминговые сервисы.
- Вторичная конкуренция — продукты, которые решают ту же проблему, но другим способом. Для Spotify это может быть радио.
- Непрямая конкуренция — все остальные способы выполнить ту же «работу», включая полностью другие категории продуктов. Например, для Spotify непрямыми конкурентами могут быть аудиокниги, видео с белым шумом на YouTube, подкасты или даже открытое окно.
Получается, что конкуренты — не всегда те, о ком думает компания. Люди не мыслят «мне нужен музыкальный стриминговый сервис». Они думают: «мне нужно что-то, что поможет мне сосредоточиться во время работы» или «мне нужно что-то для создания приятной атмосферы на вечеринке».
Выделять конкурентов 3 видов стоит для того, чтобы работать на опережение и заранее разрабатывать продукт, который понадобится целевой аудитории в будущем. Чтобы это продумать, нужно:
- Определить, какие «работы» ваш продукт выполняет для пользователей.
- Выяснить, какие альтернативные решения (включая непрямых конкурентов) они используют.
- Понять, по каким критериям пользователи оценивают успешность выполнения «работы».
- Создать продукт, который превосходит продукт всех конкурентов по ключевым критериям.
Например, мессенджер Telegram таким способом обошел прямых и непрямых конкурентов. Он создал среду, где можно общаться текстом и голосом, делать видеозвонки, принимать платежи и создавать каналы, а еще и создавать мини-приложения. Так мессенджер закрывает потребность использовать разные приложения для всех этих задач и отстраивается от большинства конкурентов.
Как выявлять настоящие потребности аудитории
Проводить интервью с пользователями. JTBD-интервью отличаются от обычных пользовательских интервью. Их главная особенность — фокус на конкретном опыте использования продукта и обстоятельствах принятия решения, а не на общих мнениях или предпочтениях.
JTBD-интервью можно проводить в разных сценариях:
- Интервью о «переключении» (Switch Interview) — исследует, почему пользователь перешел с одного продукта на другой.
- Хронологическое интервью — проводит пользователя через весь процесс принятия решения от первого осознания потребности до финального выбора и использования продукта.
- Контекстное интервью — проводится в той среде, где пользователь обычно взаимодействует с продуктом, чтобы лучше понять контекст использования.
Во время JTBD-интервью важно правильно формулировать вопросы, иначе понять реальную потребность пользователя будет сложно. Вот несколько универсальных вопросов:
- Что привело вас к покупке этого продукта? Опишите ситуацию, в которой вы поняли, что вам нужно именно это решение.
- Чего вы пытались достичь, когда искали этот продукт?
- Какие альтернативы вы рассматривали? Почему выбрали именно этот вариант?
- Какие сомнения у вас были перед покупкой?
- Как вы поняли, что продукт справился с вашей задачей? По каким критериям вы оценивали успех?
- Что бы вы делали, если бы этого продукта не существовало?
Нужно задавать вопросы о конкретных ситуациях и реальном опыте, а не о гипотетических сценариях. Например, вместо «Как бы вы использовали приложение для управления финансами?» лучше спросить «Расскажите о последнем случае, когда вы пытались контролировать свои расходы. Почему вы решили это делать?»
Чтобы лучше понять мотивацию человека, можно использовать технику «5 почему». Суть в том, чтобы последовательно задавать вопрос «почему» несколько раз на каждый новый ответ и углубляться в причины.
На основе собранной информации можно построить карту пути клиента (CJM) и понять, когда пользователь испытывает трудности при выполнении «работы». Например, для финансового приложения это может быть сложность ввода расходов вручную или отсутствие понятной категоризации трат.
Подробнее о CJM читайте в статье: «Сustomer journey map: что это такое, пошаговая инструкция – как составить»
Как приоритизировать работы
Чтобы не распыляться и не тратить время и деньги впустую, задачи нужно приоритизировать. Это ускоряет путь к продукту, который действительно решает проблему пользователей. Помогает не разрабатывать лишних функций и не усложнять карту пути клиента.
Оценивать важность «работ» можно по 3 параметрам (на примере приложения для контроля расходов).
Частота. Как часто пользователи пытаются выполнить «работу»:
- ежедневно — проверить баланс счета;
- еженедельно — планировать бюджет на неделю;
- ежемесячно — анализировать расходы за месяц;
- ситуативно — принять решение о крупной покупке.
Значимость. Насколько важно для пользователя успешное выполнение «работы»:
- Критично важно — не допустить просрочки платежа по кредиту;
- Очень важно — контролировать траты в рамках бюджета;
- Умеренно важно — разбивать расходы по категориям;
- Малозначимо — сравнить свои расходы со средними по стране.
Неудовлетворенность. Насколько существующие решения не справляются с этой «работой»
- Высокая неудовлетворенность — пользователи активно ищут альтернативы;
- Средняя неудовлетворенность — пользователи справляются, но не очень довольны;
- Низкая неудовлетворенность — пользователи в целом удовлетворены существующими решениями.
Самая важная работа — с высокой частотой, высокой значимостью и высокой неудовлетворенностью.
Количественные методы приоритизации JTBD через опросы
Чтобы сделать приоритизацию более объективной, можно использовать количественные методы.
Чтобы приоритизировать задачи через опросы, составьте список выявленных «работ» в формате, понятном респондентам. Для каждой «работы» задайте два вопроса:
Насколько важно для вас [выполнение этой работы]? (шкала от 1 до 10)
Насколько вы удовлетворены тем, как существующие решения помогают вам [выполнять эту работу]? (шкала от 1 до 10)
Рассчитайте индекс возможности (Opportunity Score) по формуле:
Индекс возможности = Важность + (Важность — Удовлетворенность)
Эта формула дает больший вес «работам», которые очень важны, но плохо удовлетворены существующими решениями.
Разбираем на примере: как анализировать бизнес по методу JTBD
Разберемся на примере создания мобильного приложения для сервиса грузоперевозок по Москве и МО.
Этап 1. Формируем гипотезы о «работах» пользователей
Сначала команда приложения изучила поисковые запросы, сайты конкурентов, опросила людей и выяснила, зачем люди используют сервисы грузоперевозок:
- Быстро найти машину подходящего размера, чтобы перевезти новый диван из магазина домой.
- Организовать переезд в новую квартиру без лишней головной боли.
- Безопасно доставить мебель на дачу.
- Отправить товары клиентам из небольшого интернет-магазина.
Этап 2. Готовим структуру интервью и подбираем респондентов
Для глубокого понимания потребностей пользователей команда провела интервью, где задавала такой вопрос:
Расскажите о последнем случае, когда вам понадобилось что-то перевезти. Как все происходило с самого начала?
Для исследования были отобраны три группы респондентов:
- Люди, заказавшие грузоперевозку в последние 3 месяца.
- Владельцы малого бизнеса, регулярно отправляющие товары.
- Предприниматели, которые организуют доставку, но еще не используют специальные приложения.
Такая выборка позволила охватить разные сценарии использования и понять разнообразие потребностей.
Этап 3. Проводим исследование и выявляем ключевые «работы»
После интервью команда создала список «работ», которые пользователи пытаются выполнить.
Обычные люди:
- После покупки большой мебели я хочу доставить ее домой сегодня и не ждать несколько дней доставки от магазина.
- Когда я переезжаю, хочу передать все компании под ключ. Не хочу нанимать отдельно машину, грузчиков и искать упаковку.
Бизнес:
- Я хочу отправлять даже самые большие грузы в день заказа, чтобы клиенты всегда были довольны.
- Когда я отправляю документы или образцы партнерам, хочу отслеживать посылку и не волноваться о сроках.
Этап 4. Приоритезируем «работы» и выбираем главные направления
Не все выявленные «работы» одинаково важны. Чтобы правильно распределить ресурсы, команда оценила каждую «работу» по частоте использования, значимости и неудовлетворенности от существующих решений.
Для количественной оценки команда опросила 300+ респондентов, которые оценивали каждую «работу» по 10-балльной шкале по этим параметрам.
В результате анализа приоритетными оказались две «работы»:
- Для физических лиц: комплексная организация переезда «под ключ».
- Для бизнеса: надежная доставка товаров клиентам в день заказа.
При этом команда учитывала не только потребности пользователей, но и бизнес-цели компании:
- соответствие стратегии выхода на рынок;
- потенциальное влияние на выручку;
- техническую сложность реализации;
- возможность создать устойчивое конкурентное преимущество.
Этап 5. Превращаем «работы» в конкретные решения
В случае команды — в функции приложения.
Для «работы» по организации переезда:
- Пакетное предложение «Переезд под ключ» с возможностью заказать машину, грузчиков и упаковку за один раз.
- Калькулятор стоимости на основе количества комнат и объема вещей.
- Возможность назначить менеджера, который будет координировать весь процесс.
- Чек-лист для подготовки к переезду, чтобы ничего не забыть.
Для «работы» по доставке товаров клиентам:
- API для интеграции с интернет-магазинами и автоматического создания заказов.
- Выбор временных слотов доставки в день заказа.
- Отслеживание курьера на карте в реальном времени.
- Автоматические уведомления о статусе доставки.
Особое внимание было уделено устранению моментов, которые вызывали наибольший стресс у пользователей:
- Неопределенность с точным временем прибытия водителя.
- Сложность оценки подходящего размера машины.
- Отсутствие информации о местонахождении груза в процессе доставки.
- Трудности с коммуникацией между заказчиком, водителем и получателем.
Этап 6. Проверяем, как все работает
После запуска продукта команда отслеживала стандартные метрики (количество установок, активных пользователей) и показатели, связанные с выполнением конкретных «работ»:
- Насколько быстро пользователи проходят путь от возникновения потребности до ее удовлетворения.
- Процент случаев, когда пользователи выбирают приложение вместо альтернативных решений для выполнения «работы».
- Уровень стресса и удовлетворенности в процессе и после выполнения «работы».
- Количество решенных проблем за одно взаимодействие с приложением.
Такой подход помогает сфокусироваться на том, что действительно важно — насколько хорошо продукт решает задачи клиентов.
Что в итоге
- Jobs To Be Done (JTBD) — методология для разработки востребованных продуктов. Она помогает понять истинные причины покупки продуктов и услуг.
- Метод фокусируется на выполнении «работы» потребителем, а не на самом продукте.
- Модель JTBD состоит из «работы», контекста, мотивации, ожидаемого результата, ограничений и критериев оценки успешности.
- JTBD отличается от других методов вроде персон и Customer Development тем, что фокусируется на глубинных мотивациях и контекстах использования продукта.
- Есть несколько подходов использования JTBD: Jobs As Progress, Jobs As Activities и модель четырех сил.
- Для выявления потребностей аудитории используются JTBD-интервью.
- Приоритизировать «работу» можно качественно и количественно. Качественную приоритизацию проводят на основе частоты, значимости и неудовлетворенности пользователей. Количественную — через опросы и общение с аудиторией.
Если хотите внедрить методику Jobs To Be Done в свою компанию, обратитесь за помощью в Neogenda. Просто запишитесь на бесплатную консультацию, и наши эксперты помогут интегрировать модель в ваш бизнес.
