JTBD и “нулевая” ценность: почему в 2026 выигрывает не тот, кто лучше объясняет, а тот, кто точнее называет ра

JTBD и “нулевая” ценность: почему в 2026 выигрывает не тот, кто лучше объясняет, а тот, кто точнее называет работу

В последние месяцы я всё чаще вижу одну и ту же ошибку в продуктовых исследованиях по JTBD (Jobs To Be Done — “работа, которую человек пытается выполнить”). Команды делают карту сегментов, собирают интервью, формулируют job-statement… и дальше пытаются упаковать это в контент/позиционирование так, будто “понятно” = “полезно”.

Проблема в том, что в JTBD “ценность” появляется только там, где мы уменьшаем трение между реальной задачей пользователя и способом её выполнить. А большинство формулировок остаются слишком общими, потому что автор не проверяет главный вопрос: какой именно дискомфорт человек хочет снять прямо сейчас?

Как мы это диагностируем на практике (и почему я называю это “нулевой ценностью”)
1) Сначала берём 10–15 типовых ситуаций “когда человек приходит”.
2) Для каждой ситуации задаём людям один уточняющий вопрос: **“Что случится, если вы сделаете это не сегодня?”**
Чаще всего ответ звучит не как “я хочу эффективность”, а как страх потерять деньги/время/контроль, или раздражение от повторяющихся шагов, или риск получить некорректный результат.
3) Потом смотрим: в наших job-statement это отражено или оно снова превращено в абстракцию (“хочу оптимизировать процессы”).

Один наблюдаемый эффект из практики
Когда мы прогоняем формулировки через “проверку дискомфорта” и дорабатываем их до конкретной “работы-снятия-трения”, конверсия из верхнего уровня в следующий шаг (например, от просмотра методички/кейс-страницы к демо-диалогу или консультации) обычно растёт, потому что сообщение перестаёт быть рекламой и становится ответом на внутренний вопрос. В одном из B2B-проектов у нас после пересборки message-map под 2 ключевые подзадачи (что именно человек пытается *не допустить* и *какой контроль хочет вернуть*) переходы на этап “запрос” увеличились примерно на 18% за счёт тех же каналов и бюджета. Не потому что мы “лучше писали”, а потому что перестали говорить “о возможностях”.

Как правильно делать JTBD-формулировку в 2026 (короткий шаблон, который я использую)
Для каждой подзадачи фиксируем:
— Контекст: что происходит “в моменте”
— Текущее решение: что человек делает сейчас (и почему оно не устраивает)
— Discomfort / риск: что именно болит (или что будет, если не решить)
— Критерий “успеха”: как человек поймёт, что работа выполнена
— Job-to-be-done statement: одно предложение без маркетинговых слов

И главное: не пытайтесь одним statement покрыть весь путь пользователя. В эпоху AI-overviews “объяснение” быстро усредняется. Побеждает тот, кто называет работу на уровне, который сокращает когнитивную работу пользователя: “мне это подходит, потому что решает конкретную штуку, которая меня сейчас тревожит”.

Если хотите, в следующем посте могу показать, как мы превращаем 3–5 уточнённых job-statement в RevOps-логику: где именно на воронке каждая подзадача должна поддерживаться контентом, продуктовой логикой и sales-скриптом, чтобы выручка была общей ответственностью, а не “делом отдела лидогенерации”.

— @JTBDroom