Разработка B2B-продуктов отличается от B2C-сегмента рядом принципиальных особенностей. В корпоративной среде решения о покупке принимаются коллективно, цикл сделки может занимать месяцы, а требования к интеграции и соответствию внутренним процессам клиента выходят на первый план. Именно поэтому традиционные подходы к проектированию, основанные на создании персонажей (user personas), часто оказываются недостаточно эффективными.
Метод персонажей хорошо работает в B2C-сегменте, где потребитель сам принимает решение о покупке и использует продукт для личных целей. Однако в B2B-сфере один и тот же человек может взаимодействовать с продуктом в совершенно разных контекстах: закупщик ищет поставщика, логист отслеживает груз, бухгалтер проверяет документы. Создание детальных персонажей для каждой роли приводит к фрагментации понимания продукта и потере фокуса на главном — на реальной работе, которую продукт должен выполнять для бизнеса клиента.
JTBD: философия, а не просто методология
Ключевым решением этой проблемы становится фреймворк jtbd (Jobs To Be Done — «работы, которые нужно выполнить»). Этот подход переводит фокус с характеристик пользователей на контекст их действий и мотивацию, стоящую за выбором продукта.
Концепция JTBD зародилась в академической среде и имеет два основных направления. Первое, ассоциируемое с Клейтоном Кристенсеном из Harvard Business School, фокусируется на теории прерывания (disruption theory) и изучает, почему клиенты «нанимают» или «увольняют» продукты для выполнения определённых задач. Второе направление, развиваемое практиками вроде Боба Моэсты и Криса Спика, делает акцент на практических техниках интервьюирования и формулирования job stories.
Оба лагеря сходятся в главном: люди не покупают продукты за их характеристики. Они «нанимают» продукты, чтобы продвинуться в жизни или бизнесе — решить конкретную задачу, достичь определённого результата, избежать проблемы или получить желаемое преимущество.
Почему JTBD особенно эффективен в B2B
В корпоративной разработке фреймворк JTBD демонстрирует исключительную ценность по нескольким причинам:
Единый язык для всех стейкхолдеров. Когда продуктовая команда, разработчики, маркетологи и sales-менеджеры говорят о «работах», которые продукт должен выполнять, исчезает необходимость в бесконечных уточнениях «а что имел в виду этот пользователь». Job stories дают конкретный, проверяемый контекст.
Преодоление эффекта «прокси-персоны». В B2B продукт часто используется не тем, кто его купил. JTBD позволяет отследить цепочку ценности через всю организацию клиента, выявляя, какие работы выполняет продукт для разных участников процесса.
Предсказание конкурентной среды. Классический анализ конкурентов сравнивает функции и цены. JTBD помогает понять, что конкурентом может быть не только прямой аналог, но и совершенно другой способ решения той же задачи — например, Excel-таблица вместо CRM-системы или найм дополнительного сотрудника вместо автоматизации.
Основа для приоритизации. В условиях ограниченных ресурсов разработки понимание, какие работы критичны для клиента, а какие второстепенны, позволяет принимать взвешенные решения о roadmap.
Структура фреймворка: от гипотезы до job stories
Применение JTBD в разработке B2B-продуктов следует чёткой структуре, состоящей из нескольких последовательных этапов.
1. Формулирование исследовательских гипотез
Перед началом работы команда определяет, какие предположения о потребностях клиентов нуждаются в проверке. В B2B-контексте гипотезы часто связаны с оптимизацией бизнес-процессов: сокращение времени на рутинные операции, повышение прозрачности для руководства, снижение ошибок при передаче данных между отделами.
2. Подбор респондентов
Критически важно выбирать для интервью людей, недавно столкнувшихся с проблемой, которую решает продукт, или недавно принявших решение о внедрении решения. «Недавность» опыта обеспечивает точность воспоминаний. В B2B это означает поиск специалистов, завершивших проект внедрения системы в последние 3–6 месяцев, или тех, кто прямо сейчас находится в активном поиске решения.
3. Составление опросника и проведение интервью
Интервью по методике JTBD отличается от классических юзабилити-исследований. Вместо вопросов «Что вам нравится в интерфейсе?» используется техника «восстановления хронологии»: респондент шаг за шагом вспоминает, что происходило до момента принятия решения, какие альтернативы рассматривались, что стало «точкой невозврата».
Ключевые вопросы включают:
-
Что произошло, что заставило вас начать искать решение?
-
Что вы пробовали до этого? Почему это не сработало?
-
Как вы узнали о нашем продукте?
-
Что было самым сложным в процессе принятия решения?
-
Если бы наш продукт исчез завтра, что бы вы использовали вместо него?
4. Анализ результатов
На этом этапе команда выделяет «силы прогресса» (forces of progress) — факторы, толкающие клиента к изменениям, и «силы инерции» — барьеры, сдерживающие принятие решения. В B2B-среде к силам инерции часто относятся риски срыва текущих процессов при внедрении нового решения, необходимость согласования с ИТ-отделом или юристом, инвестиции в обучение персонала.
5. Составление Job Stories
Финальный артефакт исследования — job stories, формулируемые по шаблону:
Когда [ситуация], я хочу [мотивация], чтобы [ожидаемый результат].
Пример для B2B-продукта:
Когда мне нужно подготовить ежемесячный отчёт для совета директоров, я хочу автоматически собрать данные из всех филиалов в единый формат, чтобы сократить время подготовки с трёх дней до трёх часов и исключить ошибки ручного копирования.
Job stories отличаются от user stories тем, что не привязаны к конкретному персонажу, но глубоко погружены в контекст и мотивацию.
Практическое применение JTBD в разработке интерфейсов
Полученные job stories становятся основой для проектирования интерфейсных решений. Каждая история проверяется на соответствие трём критериям:
Функциональная ценность. Решение действительно позволяет выполнить работу? Эмоциональная ценность. Пользователь чувствует уверенность и контроль в процессе? Социальная ценность. Решение повышает статус пользователя в организации или помогает избежать потери лица?
В B2B-продуктах социальная ценность часто недооценивается, хотя именно она определяет, будет ли сотрудник рекомендовать продукт руководству или скрывать его недостатки. Продукт, который делает специалиста «героем» в глазах начальства за счёт быстрой и качественной подготовки отчётов, получает невидимую, но мощную поддержку внутри организации-клиента.
Интеграция JTBD с другими методологиями
Фреймворк JTBD не заменяет, а дополняет существующие практики разработки:
-
Agile/Scrum: Job stories становятся входными данными для бэклога, а приоритизация по MoSCoW получает объективную основу через анализ «сил прогресса»
-
Design Thinking: JTBD усиливает этап эмпатии, давая структурированный способ понимания пользователя
-
Lean Startup: Гипотезы о работах, которые продукт должен выполнять, проверяются через MVP быстрее, чем гипотезы о характеристиках пользователей
-
Jobs-to-be-Done Canvas: Визуальный инструмент для стратегических сессий, позволяющий команде на одном листе увидеть все компоненты фреймворка
Рекомендации по внедрению JTBD в B2B-команду
Для успешного применения фреймворка в корпоративной разработке важно учитывать несколько практических аспектов:
Начните с пилотного проекта. Выберите один продукт или модуль, где очевидны проблемы с удержанием клиентов или конверсией, и примените JTBD только там. Полученный опыт станет базой для масштабирования.
Обучите команду технике интервью. Качество исследования определяется навыками интервьюера. Инвестиции в тренинг по проведению JTBD-интервью окупаются многократно.
Создайте репозиторий job stories. Систематизируйте накопленные знания в доступном для всей компании формате. Со временем это позволит выявлять паттерны между разными продуктами и сегментами клиентов.
Используйте JTBD для onboarding. Понимание работ, которые клиент хочет выполнить в первые дни использования продукта, помогает спроектировать эффективный процесс внедрения — критический фактор успеха в B2B.
Заключение
Фреймворк для разработки B2B-продуктов, основанный на концепции jtbd, представляет собой фундаментальный сдвиг от описания пользователей к пониманию контекста их действий. В корпоративной среде, где решения принимаются рационально, но используются людьми с эмоциями, амбициями и страхами, такой подход позволяет создавать продукты, которые клиенты действительно «нанимают» — и не увольняют.
Переход от персонажей к работам требует дисциплины и практики, но результатом становится продуктовая команда, говорящая с клиентами на одном языке, и продукты, органично вписывающиеся в реальные бизнес-процессы. В условиях растущей конкуренции в B2B-сегменте это не просто преимущество — это необходимость для выживания и роста.