Сценарий не равно результату: ловушка функционального JTBD

Сценарий не равно результату: ловушка функционального JTBD

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

В B2B-проекте, который мы разбирали в начале года, команда выявила «работу»: «настроить регулярную отчётность по эффективности рекламы». Построили воронку, сделали демо, подсветили функцию автоматических отчётов. Конверсия в пробу оказалась высокой. Retention на второй месяц рухнул — 23%. Клиенты активировались и… уходили. Почему? Потому что реальная «работа» была другой — «снизить тревожность директора перед еженедельным совещанием». А её нельзя закрыть настройкой отчётов раз и навсегда. Там требуется постоянная интерпретация данных, которую пользователь не мог дать.

Привязка только к функциональному сценарию (как сделать) отсекает эмоциональное и социальное измерение «работы». Особенно сейчас, в 2026-м, когда средний чек в e-com падает, а B2B-маркетинг переходит к модели RevOps, где ты отвечаешь за выручку вместе с продажами и клиентским сервисом. Ошибка в определении «работы» бьёт не по лидогенерации, а по удержанию — самому дорогому активу.

Моё правило: если после описания «работы» вы не можете назвать хотя бы один страх или стремление, которое с ней связано — копайте глубже. Спросите себя: «Что плохого случится, если эту работу не сделают вовремя?» В ответе часто будет не потеря денег, а потеря статуса, репутации или контроля. Именно это удерживает клиента, когда функциональные альтернативы уже сравнялись.

Не ищите сценарии использования. Ищите сценарии, после которых клиент не может уйти без потерь.

— @JTBDroomPro