Jobs To Be Done часто объясняют через метафору «нанимания продукта», но ключевая идея лежит глубже. JTBD предлагает смотреть на продукт не глазами команды и не глазами абстрактного пользователя, а глазами прогресса, который человек пытается совершить в конкретный момент жизни. Это смещает фокус с характеристик и сценариев использования на движение вперед и внутренние причины выбора.
Большинство продуктовых ошибок возникает не из-за плохой реализации или недостатка функций. Они появляются потому, что команда неверно понимает, какой именно прогресс для клиента является значимым. Продукт может быть удобным, быстрым и красивым, но при этом не помогать человеку продвинуться туда, куда ему действительно нужно.
В этой статье мы разберем Jobs To Be Done как способ мышления о прогрессе клиента. Мы покажем, как этот взгляд меняет продуктовые решения, маркетинг и стратегию, и почему без него Product Manager почти неизбежно оказывается в роли «плохого», даже если он делает все старательно и по правилам.
Главный когнитивный перекос в оценке плохого продакта
Когда продукт не растет или не удерживает пользователей, часто делают вывод, что Product Manager неправильно понял аудиторию. Его обвиняют в плохой сегментации, неверных гипотезах или слабом видении. Такая оценка кажется логичной, но она упускает фундаментальный слой проблемы.
На практике PM принимает решения в рамках того мышления, которое принято в команде. Если продукт обсуждается через «кто пользователь» и «какие у него боли», то фокус смещается на характеристики людей, а не на причины действий. В этой системе координат сложно увидеть реальный прогресс клиента.
Jobs To Be Done показывает, что проблема не в ошибках PM, а в неверной оптике. Пока команда не смотрит на продукт через призму движения человека из текущего состояния в желаемое, любые решения будут выглядеть случайными и спорными.
Когда PM «плохой», значит сломалась система
Контур управления продуктом ломается там, где теряется связь между решениями команды и реальным поведением клиентов. Стратегия говорит о росте, продукт о фичах, маркетинг о каналах, но никто не отвечает за вопрос, какой прогресс клиент совершает с помощью продукта.
В такой системе Product Manager вынужден соединять несоединимое. Он балансирует между запросами бизнеса, ожиданиями команды и абстрактными инсайтами исследований. При этом у него нет четкого ориентира, который позволял бы сказать, какое решение действительно продвигает клиента вперед.
JTBD восстанавливает этот контур, потому что вводит единый ориентир - прогресс клиента. Стратегия, продукт и маркетинг начинают оцениваться по одному критерию. Если этого не происходит, роль PM неизбежно деградирует.
Нормальность ошибок: где проходит граница допустимого
JTBD-мышление не делает продуктовую работу безошибочной. Ошибки неизбежны, потому что прогресс клиента нельзя «угадать» теоретически. Его можно только постепенно прояснять через наблюдение и анализ реальных историй выбора.
Допустимой является ошибка в интерпретации прогресса. Команда может неверно определить, что именно клиент хочет изменить в своей ситуации. Это нормально, если ошибка выявляется через реальное поведение, а не остается гипотезой.
Важно, что в JTBD логике ошибка становится источником обучения. Она позволяет уточнить, какой прогресс действительно важен, а какой был переоценен. Без этого цикла продукт остается в иллюзии понимания.
Момент, когда промах превращается в некомпетентность
Ошибка превращается в некомпетентность тогда, когда команда продолжает игнорировать фактический прогресс клиента. Если пользователи ведут себя иначе, чем ожидалось, но решения не пересматриваются, проблема становится системной.
Еще один признак - подмена прогресса метриками. Когда рост показателей используется как единственный аргумент, без понимания, что именно изменилось в жизни клиента, команда теряет ориентир. Метрики начинают жить своей жизнью.
Некомпетентность проявляется и тогда, когда JTBD используется формально. Прогресс клиента упоминается в презентациях, но не влияет на roadmap и коммуникацию. В этом случае мышление не меняется.
Как это выглядит в повседневной работе
Симптомы в discovery
В discovery без JTBD команда задает вопросы о предпочтениях и желаниях. Пользователи рассказывают, что им нравится или не нравится, но эти ответы плохо объясняют поведение. Инсайты получаются поверхностными.
С JTBD фокус смещается на момент изменения. Важно понять, что подтолкнуло человека искать новое решение и что он пытался улучшить. Discovery начинает выявлять реальный прогресс.
Симптом отсутствия JTBD - множество интервью и отсутствие ясного ответа, зачем продукт вообще выбирают.
Симптомы в delivery
В delivery без JTBD приоритизация строится вокруг полезности фич. Каждая задача кажется логичной, но продукт не становится сильнее в одном направлении. Развитие расползается.
JTBD позволяет оценивать задачи по тому, усиливают ли они способность продукта помогать клиенту продвигаться вперед. Это делает приоритеты более жесткими и понятными.
Если delivery не усиливает один тип прогресса, продукт теряет фокус.
Симптомы в коммуникации
В коммуникации без JTBD маркетинг говорит о возможностях. Сообщения перегружены описаниями и преимуществами, но не попадают в ситуацию клиента.
JTBD переводит коммуникацию в язык изменений. Продукт объясняется через то, что станет проще, быстрее или спокойнее в конкретный момент. Это повышает релевантность.
Если коммуникация постоянно меняется, но не становится яснее, скорее всего прогресс клиента не определен.
Инструменты как индикаторы зрелости команды
JTBD-мышление всегда проявляется в конкретных рабочих артефактах. Это не абстрактные фреймворки и не красивые слайды для презентаций. Зрелая команда оставляет после себя документы, которые помогают принимать решения, а не просто объяснять прошлое.
Один из ключевых артефактов - описание прогресса клиента в виде последовательности состояний. В нем зафиксировано, из какой ситуации человек стартует, что его фрустрирует, какое изменение он ищет и как выглядит желаемый результат. Такой артефакт используется при обсуждении стратегии, приоритизации и запусков.
Второй важный артефакт - карта сил, влияющих на выбор. Она включает в себя толкающие силы, притягивающие силы, тревоги и привычки. Этот инструмент помогает понять, почему прогресс не всегда происходит, даже если продукт объективно хорош.
Незрелость проявляется тогда, когда эти артефакты существуют, но не используются. Если обсуждения roadmap проходят без упоминания прогресса клиента, значит JTBD не встроен в управление. В этом случае продукт развивается по инерции.
10 причин, почему PM не справляется с ролью
Провал 1. Подмена прогресса удобством.
Команда считает, что удобство само по себе равно ценности.
Провал 2. Игнорирование стартовой точки клиента.
Не учитывается, откуда человек начинает движение.
Провал 3. Фокус на продукте, а не на изменении.
Обсуждаются функции вместо результатов.
Провал 4. Отсутствие анализа отказов.
Команда не знает, почему прогресс не произошел.
Провал 5. Размытый образ желаемого состояния.
Непонятно, к чему клиент хочет прийти.
Провал 6. Попытка закрыть все прогрессы сразу.
Продукт теряет ясность.
Провал 7. Формальное использование JTBD.
Методология не влияет на решения.
Провал 8. Игнорирование эмоционального контекста.
Прогресс рассматривается только рационально.
Провал 9. Отрыв маркетинга от продукта.
Коммуникация не отражает реальный прогресс.
Провал 10. Страх неприятных выводов.
Команда избегает признания, что продукт не помогает.
Речь, выдающая некомпетентного PM
«Наш пользователь просто хочет больше функций».
«Им важно, чтобы было быстрее и дешевле».
«JTBD у нас есть, но это не для стратегии».
«Давайте сначала сделаем, потом посмотрим, какой прогресс».
«Все пользователи разные, нельзя их обобщать».
Эти фразы показывают, что прогресс клиента не является рабочей категорией. В них нет движения, нет изменения состояния и нет ориентира для решений.
Короткий кейс: исходная точка → изменения → эффект
Компания разрабатывала сервис для удаленной работы. Продуктовая команда была уверена, что ценность продукта в наборе инструментов для совместной работы. Roadmap строился вокруг расширения функциональности.
Маркетинг продвигал продукт как универсальное решение для команд. Пользователи приходили, пробовали, но часто возвращались к старым инструментам. Удержание оставалось низким.
JTBD-анализ показал, что продукт нанимали в момент потери контроля над коммуникацией. Люди искали не инструменты, а ощущение порядка и предсказуемости.
Команда пересобрала продуктовый фокус. Приоритет получили функции, которые снижали хаос, а не расширяли возможности. Часть идей была остановлена.
Коммуникация сместилась к описанию прогресса. Продукт стал объясняться через момент «когда все разваливается и нужно вернуть контроль».
В результате удержание выросло, а команда получила четкий ориентир для развития.
Мини-кейс 2: старт → изменения → итоги
В B2B-продукте для финансового планирования команда долго не могла добиться роста. Product Manager считал, что проблема в сложности интерфейса. Разработка шла в сторону упрощения.
Маркетинг говорил о прозрачности и удобстве. Пользователи соглашались, но решения принимались медленно. Сделки затягивались.
JTBD-подход показал, что продукт нанимают в момент тревоги перед важными решениями. Клиенты искали уверенность, а не просто расчеты.
Продуктовая стратегия была пересобрана. Фокус сместился на сценарии поддержки принятия решений. Интерфейс изменился вторично.
Коммуникация стала говорить о снижении рисков и уверенности. Продажи ускорились, а продукт занял более понятную позицию.
Чек-лист оценки
- Понимаем ли мы стартовую точку клиента.
- Знаем ли мы, что запускает поиск решения.
- Можем ли описать прогресс без продукта.
- Есть ли у продукта один основной прогресс.
- Используем ли мы JTBD в стратегии.
- Влияет ли прогресс на roadmap.
- Понимаем ли мы эмоциональный контекст.
- Анализируем ли мы отказы.
- Говорит ли маркетинг о прогрессе.
- Использует ли команда общий язык.
- Учитываем ли мы привычки клиента.
- Есть ли карта сил выбора.
- Проверяем ли мы гипотезы поведения.
- Можем ли мы отказаться от лишнего.
- Ясно ли желаемое состояние клиента.
- Видим ли мы, что происходит после найма.
- Используем ли реальные истории.
- Меняются ли решения после инсайтов.
- Помогает ли это фокусу команды.
- Улучшается ли понимание рынка.
FAQ
Что значит смотреть на продукт глазами прогресса?
Это значит оценивать продукт по тому, какое изменение он помогает совершить.
Чем это отличается от пользовательского опыта?
UX описывает взаимодействие, JTBD описывает движение.
Можно ли применять JTBD без интервью?
Сложно, потому что прогресс проявляется в историях.
Это подходит только для новых продуктов?
Нет, особенно полезно для зрелых продуктов.
Как JTBD влияет на стратегию?
Он задает фокус и критерии выбора.
Заменяет ли JTBD метрики?
Нет, но помогает их правильно интерпретировать.
Можно ли иметь несколько прогрессов?
Можно, но стратегически лучше выбрать один.
Почему команды сопротивляются JTBD?
Он требует отказаться от привычных объяснений.
Это больше про маркетинг или продукт?
Про связь между ними.
Когда JTBD не помогает?
Когда команда не готова менять решения.
Jobs To Be Done позволяет смотреть на продукт глазами прогресса клиента, а не через призму функций или сегментов. Этот сдвиг меняет стратегию, продуктовые решения и маркетинг одновременно. Когда команда понимает, какой прогресс действительно важен, продукт становится осмысленным, коммуникация точной, а рост - устойчивым. Без этого взгляда даже хорошие продукты рискуют остаться полезными, но ненужными.