JTBD не нужно «рисовать сценарии» — сначала подтвердите задачу, а не драму

JTBD не нужно «рисовать сценарии» — сначала подтвердите задачу, а не драму

Миф: продуктовый маркетолог должен начинать JTBD с красивых историй пользователя — «как он мучается, как выбирает, как приходит к покупке». Если вы можете описать путь как мини-сериал, значит JTBD найден.

Откуда миф: так проще продавать работу внутри команды. В эпоху, когда контент оценивают по ощущаемой глубине, сценарии выглядят экспертно. Плюс многие шаблоны JTBD встраиваются в привычный процесс discovery: «собрали интервью → оформили персонажей → сделали карту пути».

Почему это неправда: сюжет подменяет проверку. История может быть правдоподобной, но JTBD — это не драматургия и не «стадии до покупки». Задача в JTBD — устойчивый прогресс, который человек нанимает продукт/решение выполнить, чтобы достигнуть конкретного результата в конкретном контексте. Если вы начинаете с повествования, вы почти неизбежно фиксируете неверные опорные точки: воспоминания смешиваются с рационализациями, причины «потому что так удобно» выдаются за функциональные причины, а реальный триггер (что заставило действовать именно сейчас) теряется. В 2026 это усиливается AI-overviews: пользователи сравнивают варианты за секунды, и «эмоциональная оправдательная карта» не отвечает на вопрос, почему решение вообще было выбрано.

Что вместо: начните с гипотезы прогресса в форме «когда X в контексте Y, человек пытается получить Z, преодолевая барьер W». Затем подтверждайте это данными: интервью должны добывать формулировки барьеров и условий «когда приходит срочность», а не пересказ того, как человек «должен был бы» поступить. Проводите быструю проверку через измеримые действия: какие шаги предшествуют выбору, какие моменты запускают поиск, где человек готов менять решение. И только после этого формируйте сценарий — как иллюстрацию подтверждённой задачи, а не как источник истины.

— @JTBDroomPro