Тренд JTBD (Jobs To Be Done) меняет правила игры: теперь скрытые потребности пользователей ищут не по «портретам ЦА» и опросникам про хотелки, а по реальным ситуациям выбора и переключения — что снижает стоимость продуктовой ошибки для новичка почти вдвое, но требует дисциплины в интервью и нормальной формулировки job story и user story.

Если вы меняете профессию на IT или уже джун с годом опыта, у вас почти неизбежно будет один и тот же сюрприз: «Мы сделали фичу, а ей никто не пользуется». И тут выясняется, что пользователи — не персонажи из презентации, а люди, которые нанимают продукт как дрель: не ради дрели, а чтобы появилась дырка. А иногда — чтобы сосед услышал, что у них “идёт ремонт” и отстал. Вот это «иногда» и есть зона скрытых потребностей, за которую в 2026 платят.

На российском рынке это особенно заметно: конкуренция в привычных нишах (финтех, маркетплейсы, доставка, B2B‑сервисы для учёта) высокая, бюджеты на “пощупать гипотезы годик” у многих сдулись, а спрос на продуктовую вменяемость вырос. Поэтому метод JTBD снова всплыл — не как модное слово, а как способ перестать ставить задачи по принципу «директор видел у конкурентов».

Кстати, похожие разборы с примерами из российских продуктов и практики — на https://itokno.ru (там удобно складывается база, чтобы не искать по чатам “а где было про интервью?”).

Что такое JTBD и чем он отличается от «опросов пользователей»

Тезис

JTBD метод — это способ описывать потребность как «работу», которую пользователь “нанимает” продукт выполнить в конкретной ситуации, с конкретным ожиданием результата и ограничениями.

Обоснование (по факту, без шампуни)

Опросы часто собирают мнения (“хочу темную тему”, “не хватает фильтра”), но мнения плохо предсказывают поведение. JTBD держится на событиях: что произошло до решения, почему человек переключился, что мешало, чем он рисковал. Это переносит фокус с «что добавить» на «почему покупают/пользуются».

Практический вывод

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

Подводный камень

Самая частая ошибка новичка — перепутать JTBD с вежливым переименованием user story. В итоге получается: “Как пользователь, хочу кнопку”. Это не JTBD, это техзадание с притворной эмпатией.

Где в JTBD прячутся «скрытые потребности»

Тезис

Скрытые потребности — это не “секреты”, а неозвученные критерии выбора: страхи, ограничения, социальные риски и компромиссы, которые пользователь не рассказывает в анкете, но учитывает в реальном решении.

Обоснование

В цифровых продуктах (банк, маркетплейс, SaaS для бухгалтерии, сервис доставки) пользователь редко формулирует цель как фичу. Он формулирует её как результат: “не опоздать”, “не получить штраф”, “не выглядеть глупо перед начальником”, “не потерять деньги”, “не потратить вечер на разбор непонятного интерфейса”.

И вот тут появляются «невидимые» драйверы:

• снижение тревоги (например, “чтобы всё было по закону и я не переживал”);
• экономия времени (не “быстрее”, а “успеть до 18:00, пока бухгалтерия на связи”);
• избежание стыда (не “удобно”, а “чтобы не выглядеть чайником”);
• предсказуемость (не “красиво”, а “чтобы работало одинаково каждый раз”);
• страх ошибки (не “меньше кликов”, а “не нажать не туда и не потерять данные”).

Практический вывод

Если вы хотите находить скрытые потребности, перестаньте спрашивать “что вам нужно” и начните разбирать “что было до”, “почему именно тогда”, “какие варианты рассматривали”, “чего боялись”.

Подводный камень

Не превращайте интервью в допрос с пристрастием. Люди закрываются, когда чувствуют, что их сейчас будут “раскалывать на инсайт”. Нормальный тон — как разговор с коллегой, а не кастинг на роль в вашем продукте.

JTBD vs user story: не путайте рецепт с фотографией

Тезис

JTBD описывает причинно‑следственную механику выбора, а user story — потребность к роли в системе. Они дружат, но не заменяют друг друга.

Как связать сущности (и не получить кашу в бэклоге)

Job story (часто в JTBD) звучит примерно так: “Когда [ситуация], я хочу [мотивация/действие], чтобы [ожидаемый результат]”.

User story звучит так: “Как [роль], я хочу [возможность], чтобы [ценность]”.

Практический вывод

Сначала извлекаете job (почему это нужно), затем переводите в user story (что делать в интерфейсе/API), и только потом — в задачи разработке. Если сделать наоборот, вы получите “быстро поставили, долго стыдно”.

Подводный камень

Фраза “пользователь просит” — не аргумент. Пользователь просит то, что умеет сформулировать. А скрытые потребности часто как раз там, где формулировать нечем.

Как проводить JTBD-интервью в 2026, чтобы не собрать мусор

Тезис

Работает не “опрос про хотелки”, а интервью про последнее реальное решение: покупку, установку, переход, отказ, возврат, удаление приложения.

Скелет интервью (практика)

1. Выберите событие: “расскажите про последний раз, когда вы…” (оформили доставку, завели карту, подключили СБП, начали вести учёт, перешли на другого провайдера).
2. Восстановите хронологию: что стало триггером, что пробовали до, что не устроило.
3. Разберите альтернативы: “какие варианты рассматривали?” (конкуренты, Excel, “попросил знакомого”, “забил”).
4. Вытащите критерии решения: что было важно прямо тогда (скорость, цена, надёжность, легальность, поддержка).
5. Вытащите компромиссы: чем пришлось пожертвовать (удобством ради надёжности, ценой ради привычки и т.д.).

Практический вывод

Для портфолио (если вы входите в IT) проще всего взять массовый российский продукт и исследовать один сценарий: например, “первый заказ в Ozon/WB”, “жалоба в Госуслугах”, “подключение эквайринга в Тинькофф/Сбере”, “запись к врачу в ЕМИАС/региональном аналоге”. Это даст реальные jobs, а не фантазии.

Подводный камень

Не спрашивайте “что бы вы хотели в идеале”. “В идеале” люди хотят личного менеджера и скидку 90%. Спрашивайте “что было в реальности и почему вы сделали именно так”.

Кейсы из практики: один успех и один “ой”

Кейс 1 (успех): B2B‑сервис для актов и счетов

Команда думала, что их job — “быстро выставлять документы”. В интервью всплыло другое: бухгалтеры “нанимают” сервис, чтобы не ловить панику в конце месяца, когда контрагент внезапно просит “переделайте, у нас не проходит”. Скрытая потребность — предсказуемость и контроль изменений.

После этого приоритет ушёл с “шаблонов” на историю правок, статусы согласования и понятные ошибки. Конверсия в платёж выросла не магией, а потому что продукт стал снижать риск для человека, который отвечает головой.

Кейс 2 (провал): “добавим ещё фильтров в каталог”

В e‑commerce команда месяц пилила фильтры. Пользователи продолжали уходить. JTBD‑разбор показал, что job был не “найти товар”, а “быстро убедиться, что доставка придёт вовремя, иначе подарок не успеет”. Скрытая потребность — доверие к срокам и ясный прогноз.

Фильтры не лечат отсутствие уверенности. Пф. В итоге всё равно делали прозрачный SLA по доставке, и только тогда метрики ожили.

Коммерческие факторы: сколько стоит ошибка и обучение JTBD в России

Тезис

JTBD — дешёвый инструмент по сравнению с ценой разработки “не того”. Дорогая часть — время команды и дисциплина, а не “секретная методичка”.

Что обычно по рынку

Практический вывод

Если вы начинаете, выгоднее собрать 6–10 интервью, один хороший job map и 3 проверенных гипотезы — это в портфолио весит больше, чем “сертификат слушателя”. Если вы уже в IT, JTBD окупается, когда помогает отменить 1–2 лишних эпика.

Подводный камень

Не покупайтесь на “гарантированно научим чувствовать клиента”. Чувствовать клиента — это не навык, а побочный эффект от 20 нормально проведённых интервью.

Экспертный вердикт и инструмент: чек-лист, чтобы JTBD не умер в Notion

JTBD в 2026 — это не религия и не замена продуктового мышления. Это способ разговаривать о ценности продукта языком решений и рисков, а не языком фич. Если вам надо находить скрытые потребности, вот простой инструмент, который можно унести в работу уже сегодня.

• 1) Какое переключение мы изучаем? (с чего на что: конкурент, Excel, “делал руками”, “ничего не делал”).
• 2) Какой триггер запускает поиск решения? (событие, дедлайн, штраф, новый процесс, начальник).
• 3) Какой прогресс человек хочет? Не “удобно”, а измеримо: “успеть”, “не ошибиться”, “сдать вовремя”, “не переплатить”.
• 4) Какие силы удерживают от смены? привычка, страх, цена обучения, недоверие, риск выглядеть глупо.
• 5) Как мы перевели job story в user story? Чтобы разработка делала “то самое”, а не “что-то похожее”.

Если на 4 из 5 вопросов отвечаете “ну… примерно”, значит у вас пока не JTBD, а фанфик по мотивам пользовательских болей.

Частые вопросы