ProductHub

JTBD и customer development: как находить настоящие задачи пользователей

Большинство продуктовых ошибок рождаются не в коде, а на уровне постановки задачи: команда строит фичу, которую никто не «нанимает» на работу. Jobs To Be Done (JTBD) и customer development — это два связанных способа вернуться к реальной задаче пользователя до того, как потрачен квартал разработки.

Что такое Jobs To Be Done

JTBD рассматривает продукт как нечто, что человек «нанимает» для выполнения работы (job). Покупают не дрель, а отверстие в стене; не приложение для заметок, а спокойствие от того, что мысль не потеряется. Работа описывается в формате «когда [ситуация], я хочу [мотивация], чтобы [ожидаемый результат]» и почти не меняется годами — в отличие от решений, которые устаревают.

Практическая польза формулировки в том, что она смещает фокус с фич на прогресс, которого человек пытается добиться. Это сразу отсекает часть бэклога: фича, которая не двигает ни одну значимую работу вперёд, не нужна.

Чем JTBD отличается от мышления фичами и персон

Персоны описывают, кто пользователь (возраст, роль, демография). JTBD описывает, зачем он нанимает продукт в конкретной ситуации. Один и тот же человек в разных контекстах «нанимает» разные продукты — поэтому ситуация важнее портрета.

  • Фичевое мышление: «давайте добавим экспорт в PDF».
  • JTBD-мышление: «когда я готовлю отчёт руководителю в пятницу вечером, я хочу отдать результат в привычном ему формате, чтобы не объяснять, как открыть наш файл».

Вторая формулировка подсказывает не только фичу, но и критерий успеха, и конкурентов (включая «нанять» Excel или вообще ничего не делать).

Как проводить customer-development интервью

Customer development — это дисциплина проверки, кому и зачем нужен продукт, через разговоры с реальными людьми. Хорошее интервью реконструирует прошлое поведение, а не собирает мнения о будущем.

  1. Ищите истории, а не оценки. «Расскажите, как вы решали это в последний раз» лучше, чем «нравится ли вам идея».
  2. Идите по таймлайну. Что случилось до того, как человек начал искать решение? Какой триггер заставил действовать именно тогда?
  3. Фиксируйте обходные пути. Таблицы, заметки, костыли — это карта неудовлетворённых работ и готовность платить усилием.
  4. Не продавайте. Как только вы начали презентовать решение, собеседник переходит в режим вежливости, и данные портятся.
  5. Спрашивайте про деньги и время прошедшим временем. «Сколько вы потратили на это в прошлом квартале» честнее, чем «сколько бы вы заплатили».

Частые ошибки

  • Наводящие вопросы. «Вам ведь было бы удобно, если…» — это подтверждение гипотезы, а не проверка.
  • Интервью не с теми. Разговор с лояльными фанатами не покажет, почему уходят остальные.
  • Спрос на будущее. Люди плохо предсказывают своё поведение; верьте действиям из прошлого.
  • Нет следующего шага. Десятки интервью без синтеза в гипотезы — это потраченное время.

Как превратить инсайты в план

После серии интервью соберите повторяющиеся работы, ранжируйте их по важности и неудовлетворённости, и сформулируйте 2–3 проверяемые продуктовые гипотезы. Дальше — приоритизация и самый дешёвый эксперимент, который способен опровергнуть гипотезу. Именно переход «инсайт → гипотеза → проверка» отличает результативный кастдев от коллекции интересных цитат.

Разберите свою задачу по этой логике — бесплатно

ProductHub Deep Dive за ~7 минут превращает вашу продуктовую задачу в план с обоснованием, опираясь на методологию и 200+ реальных проектов агентства. Без воды и коммерческих звонков.

Пройти разбор бесплатно

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

Сколько customer-development интервью нужно провести?

Жёсткого числа нет: ориентируйтесь на насыщение, когда новые интервью перестают приносить новые работы и паттерны. На узком сегменте это часто 8–15 разговоров.

JTBD заменяет персоны?

Нет. JTBD и персоны отвечают на разные вопросы — «зачем в этой ситуации» и «кто». Их удобно использовать вместе, но приоритет лучше отдавать ситуации и работе.