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