Почему в 2026 JTBD проигрывает, если вы «опрашиваете ради карты»
Я всё чаще вижу, как продуктовые команды берут JTBD как артефакт: провели 8–12 интервью, получили формулировки “задачи”, расписали этапы, разложили по сегментам — и на этом всё. Дальше эти “карты” используют как ТЗ контенту или как аргумент для продуктовых решений. И закономерно получают: понимания больше, а эффектов меньше.
Моя позиция простая: JTBD в 2026 нужно строить не как карту, а как механизм принятия решений. Иначе вы попадаете в ловушку “доказательства вместо выбора”.
Что именно ломается
1) Ошибка формата: интервью ради формулировки. Ваша цель должна быть прояснение выбора клиента: что он сравнивает, какие критерии “перевешивают”, почему именно сейчас.
2) Ошибка использования: выводы кладут в презентацию. В эпоху AI-оверёвью и нулевого клика аудитория не платит вниманием за “хорошую теорию”. Она платит за снятую неопределённость в конкретном решении.
3) Ошибка метрики: вы измеряете качество исследования (сколько цитат, сколько схем), а не изменение в воронке решений (что стало проще выбрать/купить/принять).
Одна практическая проверка, которая меняет всё
Я ввожу правило: после JTBD-сессии команда обязана собрать “дерево компромиссов” для одного ключевого use case (сценария). Не просто “задача пользователя”, а ответы на три вопроса:
— Что человек хочет получить (job-to-be-done) и что он готов отдать за это?
— Какие варианты он рассматривает до “вас” и по каким критериям отсекает?
— Где ломается доверие: цена, риск ошибки, сложность внедрения, отсутствие контроля, сроки, юридические моменты?
Дальше я даю один количественный ориентир из практики: если JTBD не содержит явных компромиссов (что считается приемлемой “ценой” за результат), то в тестах сообщений конверсия в целевое действие обычно “гуляет” без устойчивого роста. У нас это повторялось в форматах B2B (презентации продукта, страницы кейсов, страницы onboarding): выигрывает не формулировка задачи, а ответ на скрытое “а что, если…”.
Как это связано с 2026
— По SEO уходит “чистый информационный запрос”: люди всё чаще получают обобщение от агрегаторов и систем. Поэтому в коммуникации остаётся ценность автора: конкретика выбора и рисков.
— В B2B MQL/SQL слабее держатся, и маркетинг с RevOps (сквозной ответственностью за выручку) требует причинно-следственных гипотез: “какое решение клиента мы ускоряем и чем подтверждаем”.
— В e-com средний чек снижается: выигрывает тот, кто уменьшает ощущение потерь при покупке. Это тоже JTBD, только выраженный через страхи и компромиссы, а не через “желания”.
Мой вывод
JTBD в 2026 — это не документ. Это дисциплина формулировки решения: вы берёте задачу клиента и переводите её в набор критериев выбора, чтобы продукт и маркетинг перестали угадывать. Если после исследования вы не можете объяснить, почему клиент выберет именно вас среди вариантов — значит, вы описали “что”, а не “почему сейчас” и “по какой цене”.
Если хотите — скажите ваш продукт и основной use case (кратко). Я предложу шаблон “дерева компромиссов” под ваш JTBD так, чтобы его можно было сразу превратить в гипотезы для тестов.
— @JTBDroomPro
Jobs To Be Done
@JTBDroomPro
Почему в 2026 JTBD проигрывает, если вы «опрашиваете ради карты»
Этот пост опубликован в Telegram-канале Jobs To Be Done. Подписаться можно по ссылке: @JTBDroomPro.