Создание продуктов для корпоративного рынка — задача, которая отличается от разработки потребительских решений радикально. В B2B-сегменте решение о покупке принимается коллективно, цикл сделки растягивается на месяцы, а требования к надёжности и интеграции зашкаливают. Классические инструменты проектирования, в первую очередь персоны (personas), часто не справляются с этой сложностью. Именно тогда в игру вступает фреймворк jtbd — подход, который меняет фокус с портрета пользователя на задачу, которую он перед продуктом ставит.
Почему персоны теряют силу в корпоративной среде
Представьте типичную ситуацию: менеджер по закупкам инициирует поиск CRM-системы, IT-директор оценивает технические требования, финансовый директор согласовывает бюджет, а менеджеры по продажам ежедневно работают в выбранном решении. Все они — разные люди с разным опытом, возрастом, мотивацией. Создавать подробные персоны для каждой роли можно бесконечно, но в итоге команда получит набор разрозненных портретов, которые не дают целостного понимания, зачем вообще нужен продукт.
Фреймворк jtbd предлагает выйти из этого тупика. Вместо вопроса «кто наш пользователь?» он задаёт вопрос «какую работу пользователь нанимает продукт выполнить?». Этот сдвиг парадигмы объединяет разные роли вокруг единого понимания ценности — и это особенно важно в B2B, где продукт должен удовлетворять интересы множества стейкхолдеров.
Что такое JTBD: корни и развитие
Идея Jobs To Be Done зародилась на стыке инновационного менеджмента и изучения поведения потребителей. Два направления сформировали современное понимание фреймворка.
Первое направление ассоциируется с Клейтоном Кристенсеном, профессором Гарвардской школы бизнеса. Его знаменитый пример с молочными коктейлями в McDonald’s иллюстрирует суть подхода: люди покупают продукт не за его внутренние характеристики, а потому что он решает конкретную задачу в конкретном контексте. Утренние покупатели коктейлей «нанимали» их не ради вкуса, а чтобы скрасить нудную поездку на работу и остаться сытыми до обеда.
Второе направление развивали практики — Алан Клементс, Боб Моэста, Крис Спарк — которые сделали акцент на методологии интервьюирования и анализе механики принятия решений. Они систематизировали подход к изучению «сил», которые толкают человека к изменениям или удерживают его в статусе-кво.
В корпоративном контексте фреймворк jtbd приобретает особую ценность, потому что бизнес-закупки почти никогда не бывают импульсивными. За каждым решением стоит конкретный процесс, метрика или болевая точка, которую нужно устранить.
Ключевые артефакты фреймворка
Работа с jtbd порождает несколько типов артефактов, которые становятся фундаментом для продуктовых решений.
Описание работы (Job Statement)
Это формулировка в строгой структуре: «Когда я [ситуация], я хочу [мотивация], чтобы [ожидаемый результат]». Пример для B2B: «Когда я готовлю квартальный отчёт для совета директоров, я хочу автоматически агрегировать данные из пяти разрозненных источников, чтобы сократить время подготовки с трёх дней до трёх часов и исключить ручные ошибки».
Job Stories
Это расширенные сценарии, которые детализируют контекст, мотивацию и ожидаемый исход. В отличие от классических user stories в agile-разработке, Job Stories глубже погружаются в «почему» и «зачем», что критично для сложных корпоративных сценариев.
Карта выполнения работы (Job Map)
Визуализация всех этапов, которые проходит пользователь: от осознания потребности и поиска решения до интеграции, ежедневного использования и оценки результата. В B2B этот артефакт особенно важен, потому что внедрение может занимать кварталы, и каждый этап требует отдельного внимания.
Модель сил (Progress Forces)
Четыре силы, определяющие решение пользователя:
-
Толкающие силы — проблема, которая заставляет искать выход
-
Притягивающие силы — привлекательность нового решения
-
Тревога — страхи и сомнения перед изменениями
-
Инерция — привычка к текущему способу работы
Понимание баланса этих сил позволяет спроектировать не только продукт, но и процесс его продажи и внедрения.
Практическое применение: пошаговый разбор
Шаг первый: гипотезы
Перед погружением в исследование команда формулирует предположения о «работах» целевой аудитории. В B2B здесь важно не ограничиваться конечными пользователями — нужно включать лиц, принимающих решения, технических специалистов, интеграторов и даже клиентов вашего клиента.
Шаг второй: подбор респондентов
Критическое отличие от массовых исследований: ищите тех, кто недавно столкнулся с проблемой или недавно принял решение о смене инструмента. Со временем люди рационализируют свой выбор, искажая реальные мотивы. Идеальные кандидаты — те, кто прямо сейчас находится в процессе поиска или только что завершил внедрение.
Шаг третий: интервью
Интервью по методологии jtbd строится вокруг истории принятия решения, а не вокруг мнений о продукте. Ключевые вопросы:
-
«Расскажите, как вы работали до того, как задумались о переменах?»
-
«Что конкретно случилось, что стало точкой невозврата?»
-
«Какие варианты рассматривали? Почему отвергли каждый?»
-
«Как выглядел процесс согласования? Кто ещё участвовал?»
-
«Что изменилось после внедрения? Что оказалось сложнее, чем ожидали?»
Интервьюер избегает вопросов «нравится — не нравится» и концентрируется на фактах, событиях и механике выбора.
Шаг четвёртый: анализ
Команда просматривает записи и выделяет:
-
Повторяющиеся паттерны в ситуациях и мотивациях
-
Разрыв между заявленными и реальными причинами выбора
-
Скрытые «работы», о которых респонденты не говорят прямо, но которые определяют успех (например, желание выглядеть компетентным перед руководством)
Шаг пятый: Job Stories
На основе анализа формируются детальные сценарии. Каждый Job Story должен быть привязан к реальной ситуации, мотивационно обоснован и измерим по результату.
Шаг шестой: проектирование
Job Stories транслируются в конкретные решения. Если несколько сценариев требуют одного экрана с разными ожиданиями, команда видит конфликт и может принять взвешенное решение о приоритетах.
Специфика B2B: что нужно учитывать
Множественность «работ»
Один продукт выполняет разные задачи для разных людей. CRM для продавца — инструмент фиксации контактов. Для руководителя отдела — инструмент контроля и прогнозирования. Для CFO — строка в бюджете, требующая обоснования ROI. Для IT-директора — источник головной боли по интеграции. Успешный продукт либо учитывает все эти «работы», либо чётко позиционируется по тем, которые критичны для принятия решения.
Растянутые во времени процессы
В B2B «работа» не выполняется за минуты. Job Map включает этапы, длящиеся месяцами: пилот, аудит безопасности, обучение, миграция данных, настройка интеграций. Понимание этих этапов позволяет спроектировать сопровождающие механики: трекеры внедрения, обучающие программы для разных ролей, инструменты переноса данных.
Коллективное принятие решений
Решение редко принимает один человек. Фреймворк jtbd помогает выявить «работы» каждого участника. Закупщику важны сертификаты и референсы. IT-специалисту — API и документация. Руководителю — кейсы с цифрами. Все эти «работы» должны быть учтены в продукте или коммуникациях.
Типичные ловушки
Поверхностное описание работы. «Пользователь хочет удобный интерфейс» — не Job. Это уже решение. Нужно копать глубже: зачем ему удобство? Что он пытается сделать быстрее?
Игнорирование контекста. Job Statement без ситуации бесполезен. «Хочу быстро обработать заявку» не работает без понимания, когда, при каких обстоятельствах, с какими ограничениями.
Фокус только на текущих пользователях. Те, кто уже использует продукт, уже «нанял» вас. Их мотивация искажена опытом. Изучайте тех, кто только выбирает, или тех, кто недавно ушёл к конкуренту.
Сведение стратегии к тактике. jtbd — не просто формат для записи требований. Это стратегический фреймворк, который должен влиять на позиционирование, приоритизацию функций, ценообразование и бизнес-модель.
Сочетание с другими подходами
Фреймворк jtbd не конкурирует, а дополняет существующие методологии:
-
В Agile Job Stories заменяют или дополняют User Stories, давая команду понимание ценности
-
В Design Thinking JTBD усиливает этап эмпатии, структурируя понимание пользователя
-
В Lean Startup гипотезы о «работах» становятся основой для проверки
-
В Service Blueprint Job Map интегрируется с картой сервиса, связывая пользовательские сценарии с внутренними процессами
Заключение
Применение фреймворка jtbd в B2B требует дисциплины и глубокого погружения в корпоративную реальность. Но результат стоит затрат: продукты, построенные вокруг реальных «работ» пользователей, показывают более высокую вовлечённость, меньший отток и лучшую конверсию.
Главное преимущество подхода — в его универсальности. Неважно, создаёте ли вы SaaS-платформу, корпоративное мобильное приложение или сложную аналитическую систему. Фокус на «работе», которую пользователь нанимает продукт выполнить, позволяет отбросить лишнее и сконцентрироваться на том, что действительно создаёт ценность.
Для начала знакомства с методологией рекомендуется изучить классические работы Кристенсена, материалы по проведению JTBD-интервью и попробовать применить фреймворк на одном небольшом проекте. Со временем jtbd перестанет быть инструментом и станет способом мышления, пронизывающим всю продуктовую культуру команды.
Материал подготовлен на основе доклада «Jobs To Be Done на практике: основы применения фреймворка для разработки B2B-продуктов» с UX-марафона.