JTBD для продуктового маркетолога: как превратить «зачем покупают» в дизайн коммуникаций (а не в красивую през

JTBD для продуктового маркетолога: как превратить «зачем покупают» в дизайн коммуникаций (а не в красивую презентацию)

Продуктовый маркетолог часто попадает в ловушку: он формулирует Jobs To Be Done как «цели пользователя» или «боли» и дальше развешивает это по воронке — как будто причина покупки уже равна решению. Но в 2026-м, когда чистый informational SEO сдувается, а decision-level контент всё чаще съедают Topical Authority и AI-overviews (обобщения), побеждает не тот, кто лучше “описывает”, а тот, кто точнее понимает, *какой выбор пользователь вынужден делать в конкретной ситуации* и *какие барьеры он пытается обойти*.

JTBD можно использовать практично: как метод проектирования коммуникаций под момент выбора, а не как объяснялку для команды.

Раздел 1. Один Job — это не «цель», а цепочка решений в ситуации
Тезис: Job формулируется как «когда… я хочу… чтобы… несмотря на…» — тогда он становится инструментом для написания сообщений, а не лирикой.

Пример: вы маркетолог в B2B SaaS, который помогает командам собирать и использовать данные о клиентах (например, для RevOps — общей ответственности маркетинга, продаж и customer success за выручку). На демо часто звучит: «Нам нужно улучшить аналитику». Это ещё не Job. Это пожелание.

Правильнее развернуть в ситуацию:
— Когда у команды сменился процесс продаж (или поменялись каналы), и старые отчёты перестали объяснять выручку — в какой момент пользователь «теряет управление».
— Я хочу быстро понять, что именно влияет на конверсию и где происходит разрыв — чтобы принять решение, что чинить первым.
— Несмотря на то, что данные разрознены, термины в разных командах не совпадают, а времени на перестройку нет.

Почему это важно для коммуникаций: вы начинаете писать не «про аналитику», а про то, что человек пытается *закрыть прямо сейчас*: разрыв в управляемости, страх ошибок, потребность в быстром порядке в данных. Это сразу влияет на заголовки, структуру кейса, выбор метрик, форму демо.

Раздел 2. Не Job, а «контракт» между пользователем и продуктом: как он снижает риск
Тезис: формулируйте Job через барьеры и ожидания контроля — тогда вы сможете объяснять ценность через снятие рисков.

Пример: в e-com (снижение среднего чека на 5–8% из‑за экономии) retention и LTV становятся центральными. Многие продуктовые маркетологи упираются в «повышение повторных покупок» и делают рассылки “про выгоду”. Но у части пользователей контракт другой: они вроде бы хотят покупать снова, но боятся ошибиться с выбором и переплатить.

Попробуйте описать Job покупателя так:
— Когда я планирую повторную покупку и выбираю между “понравилось раньше” и “может быть, есть лучше по цене”
— Я хочу быстро принять решение, которое не разочарует и не потребует новых поисков
— Чтобы снизить риск сожаления и не тратить время, когда бюджет ограничен
— Несмотря на то, что предложения перегружены, а обещания магазинов похожи друг на друга.

Коммуникация под это будет другой:
— не «скидка на всё», а инструмент выбора (подбор по прошлому опыту, прозрачные критерии совместимости, понятные условия)
— кейс не «у нас X% роста», а сценарий: как клиент выбрал быстро, не сравнивая 20 страниц
— контент “почему это работает” в терминах контроля: что именно система учитывает и как пользователь может проверить логику.

Подход JTBD здесь превращается в проектирование «контракта уверенности»: продукт помогает не “делать покупки”, а завершать важный выбор без лишнего риска.

Раздел 3. Сегментируйте не аудитории, а моменты выбора (Moment of Need)
Тезис: если разные люди делают один Job, но в разной ситуации, им нужны разные сообщения; если один человек делает разные Jobs, ему нужны разные касания.

Пример: вы запускаете контент для продукта B2B. У вас три “типа” клиентов: аналитики, руководители и операционные менеджеры. Часто команда пишет универсальные материалы «для всех». В итоге никто не чувствует, что текст попадает в их момент выбора.

JTBD-подход предлагает другой разрез: моменты, когда нужно принять решение.
…