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 — это дисциплина проверки, кому и зачем нужен продукт, через разговоры с реальными людьми. Хорошее интервью реконструирует прошлое поведение, а не собирает мнения о будущем.
- Ищите истории, а не оценки. «Расскажите, как вы решали это в последний раз» лучше, чем «нравится ли вам идея».
- Идите по таймлайну. Что случилось до того, как человек начал искать решение? Какой триггер заставил действовать именно тогда?
- Фиксируйте обходные пути. Таблицы, заметки, костыли — это карта неудовлетворённых работ и готовность платить усилием.
- Не продавайте. Как только вы начали презентовать решение, собеседник переходит в режим вежливости, и данные портятся.
- Спрашивайте про деньги и время прошедшим временем. «Сколько вы потратили на это в прошлом квартале» честнее, чем «сколько бы вы заплатили».
Частые ошибки
- Наводящие вопросы. «Вам ведь было бы удобно, если…» — это подтверждение гипотезы, а не проверка.
- Интервью не с теми. Разговор с лояльными фанатами не покажет, почему уходят остальные.
- Спрос на будущее. Люди плохо предсказывают своё поведение; верьте действиям из прошлого.
- Нет следующего шага. Десятки интервью без синтеза в гипотезы — это потраченное время.
Как превратить инсайты в план
После серии интервью соберите повторяющиеся работы, ранжируйте их по важности и неудовлетворённости, и сформулируйте 2–3 проверяемые продуктовые гипотезы. Дальше — приоритизация и самый дешёвый эксперимент, который способен опровергнуть гипотезу. Именно переход «инсайт → гипотеза → проверка» отличает результативный кастдев от коллекции интересных цитат.
Разберите свою задачу по этой логике — бесплатно
ProductHub Deep Dive за ~7 минут превращает вашу продуктовую задачу в план с обоснованием, опираясь на методологию и 200+ реальных проектов агентства. Без воды и коммерческих звонков.
Пройти разбор бесплатноЧастые вопросы
Сколько customer-development интервью нужно провести?
Жёсткого числа нет: ориентируйтесь на насыщение, когда новые интервью перестают приносить новые работы и паттерны. На узком сегменте это часто 8–15 разговоров.
JTBD заменяет персоны?
Нет. JTBD и персоны отвечают на разные вопросы — «зачем в этой ситуации» и «кто». Их удобно использовать вместе, но приоритет лучше отдавать ситуации и работе.
