Jobs to Be Done: как диагностировать продукт, выбрать сегмент и объяснить ценность пользователю

Продуктовые команды нередко начинают работу с другого конца: обсуждают новую категорию продукта, технологию, экран, список задач или набор функций. Затем пытаются объяснить рынку, зачем всё это нужно. В обсуждении Ивана Замесина и Ильи Красинского эта последовательность названа источником дорогих ошибок: продукт может оказаться сложным в продаже, иметь низкую конверсию или не сходиться по экономике — не потому, что команда плохо реализовала функцию, а потому, что изначально не определила, чью работу и в какой ситуации она улучшает.

Подход Jobs to Be Done (JTBD, работы, которые человек стремится выполнить) участники разговора рассматривают не как отдельный шаблон для интервью. Это способ связать бизнес-задачу, сегмент, контекст клиента, ценность, коммуникацию и конкретное продуктовое решение. Центральный вопрос в такой логике звучит не «что нам сделать?», а «какую работу, для какого сегмента, в каком контексте и с какими критериями результата мы можем выполнить лучше существующих альтернатив?».

Причинная цепочка: от работы клиента к бизнес-результату

Иван Замесин описывает базовую последовательность так: у человека есть задачи, которые возникают из потребностей; продукт создаёт ценность, если помогает выполнять эти задачи эффективнее; компания объясняет эту ценность; клиент получает результат, продолжает покупать, может рекомендовать продукт — и только тогда возникает бизнес-ценность.

В этой модели нельзя считать стартовой точкой код, интерфейс, бренд или сам факт запуска продукта. Они могут быть средствами доставки ценности, но не доказывают её наличие. Если пользователь платит за продукт или регулярно им пользуется, продукт, по позиции Ивана, выполняет некоторую его работу. Задача команды — понять эту работу до выбора формы решения.

Илья Красинский связывает проблему с повседневной практикой: компании из сферы образовательных технологий, банков, SaaS, электронной коммерции, B2B- и B2C-сервисов продолжают «пилить функции», не выяснив, кому и в какой ситуации они нужны. Это не означает, что функции или автоматизация не важны. Ошибка возникает, когда технический артефакт принимают за клиентский результат.

Работа, ценность и функция — три разных уровня

Различие между этими понятиями участники разбирают на примере Rick.ai. Одна из возможных работ директора по маркетингу — получить аргументированный ответ, почему потенциальные клиенты не конвертируются, почему привлечение выглядит дорогим или что именно происходит в воронке перед важной встречей.

Работа в этом случае — не «посмотреть CRM-график» и не «использовать нейросеть». Это необходимость подготовить аргументацию и объяснить происходящее в рабочей ситуации.

Ценность — возможность получить наглядную аргументацию и применить её тогда, когда она нужна. Например, до совещания, на котором нужно отвечать на вопросы о качестве потенциальных клиентов или результатах кампании.

Функция — способ, благодаря которому эта ценность доставляется. В широком определении Ивана функцией может быть не только код: это любая особенность продукта или сервиса, которая помогает выполнить работу эффективнее. Для Rick.ai такими механизмами могут быть анализ данных CRM, отчёт, выявление потерянных UTM-меток, автоматизированная интерпретация или работа команды заботы, знающей типичные ошибки.

Илья уточняет важный нюанс: даже реализованный алгоритм не становится ценностью автоматически. Система может построить граф всех путей сделок и пользователей, но клиент не получит результата, если не увидит его в нужный момент, не поймёт вывод или не сможет использовать его в своей ситуации. Поэтому большая часть работы над ростом метрик, по его наблюдению, лежит не только в коде, но и в коммуникации полезности, выборе канала, текста, времени доставки и проверке пограничных сценариев.

Контекст и триггер: почему ценность нужна не всегда

Один и тот же пользователь не нуждается в продуктовой ценности непрерывно. Маркетологу может быть не нужен аналитический отчёт ночью, но он становится критически важным за час до совещания. Триггером выступает ситуация, в которой человеку нужно принять решение, защитить позицию, объяснить результат или снизить риск ошибки.

Этот принцип меняет продуктовую постановку. Вместо задачи «сделать кабинет с отчётами» команда может поставить задачу «обеспечить пользователю аргументацию до встречи». Тогда появляются более прикладные вопросы:

• как распознать актуальную ситуацию пользователя;

• какие данные и объяснение нужны именно в ней;

• где пользователь должен получить результат — в интерфейсе, почте или Telegram;

• какое действие он сможет сделать после получения информации.

По редакционной интерпретации, контекст превращает абстрактную полезность в проверяемый сценарий доставки ценности. Техническая возможность без момента применения может остаться невидимой для клиента.

Сегментация начинается с работ, а не с портрета

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

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

Илья приводит похожую логику для обучения английскому. Английский для сдачи IELTS, карьерного перехода, общения или просмотра сериалов — это разные продукты в смысле сценариев, преподавания и предложения ценности. Сегментировать, по его словам, нужно на всём пути: в рекламных каналах, на посадочной странице, после заявки, в продажах и в продукте.

Кейс Cevy Kids: от абстрактного развития к конкретным задачам

Иван рассказывает о стартапе Cevy Kids как о примере раннего фокуса. Первоначально команда создала дорогой продукт «про развитие ребёнка», но столкнулась с плохими конверсиями и несходящейся экономикой. Затем она сфокусировалась на родителях детей с СДВГ.

Существенным был не только признак сегмента, а конкретные острые работы родителей: понять, что делать во время истерики или приступа, снизить число таких эпизодов, объяснить няне или школе, как взаимодействовать с ребёнком. Вместо абстрактного обучения продукт начал помогать в понятных ситуациях.

По словам Ивана, после фокусировки стоимость продукта снизилась в пять раз, экономика начала сходиться, а клиенты стали давать высокие оценки. В материалах не раскрыт механизм изменения стоимости, поэтому нельзя утверждать, какие именно продуктовые или операционные изменения к нему привели. Но сам кейс прямо подтверждает связь между уточнением сегмента, конкретизацией работ и изменением заявленных показателей.

Локальный и глобальный поиск возможностей роста

Для уже работающего продукта Иван рекомендует начать с локального оптимума — изучить платящих клиентов, которые уже получают ценность. В интервью с ними предлагается выяснять основную работу (Core Job) и большую работу (Big Job), критерии результата, барьеры, моменты озарения и последовательность работ от появления потребности до покупки.

Этот путь не требует сразу менять бизнес-модель, рынок или страну. Его задача — точнее понять существующие сегменты, улучшить привлечение, воронку, активацию, удержание и коммуникацию. Иван оценивает вероятность заметного улучшения метрик от такого исследования в 60–70%, однако это его оценка из выступления, а не независимый результат исследования.

Глобальный поиск связан с более рискованными ставками: выйти в другой сегмент или географию, перейти между B2B и B2C, изменить ценовой уровень, начать выполнять новые работы текущих клиентов. Потенциал роста здесь может быть выше, но выше и риск того, что инвестиция не сработает. Поэтому масштаб исследования должен соответствовать масштабу решения и цене ошибки.

Как не продавать руководителю «ещё одну методологию»

Участники сходятся в том, что не стоит начинать разговор с руководителем с предложения внедрить JTBD или провести исследование. Для руководителя это может звучать как дополнительная нагрузка, задержка текущего плана и риск не выполнить обязательства перед акционерами или вышестоящим менеджментом.

Вместо этого Иван предлагает понять личные работы руководителя: выполнить план, получить признание, защитить решение, не стать крайним при провале, получить бюджет или влияние. Исследование, сегментация и проверка рынка должны быть представлены не как самоценная методология, а как способ повысить вероятность этих результатов.

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

Что меняется на посадочной странице и в электронной коммерции

Коммуникация ценности должна начинаться с точки А пользователя: его ситуации, триггера, барьера и желаемого результата. Затем важно показать точку Б — что изменится после получения ценности, каким образом она будет доставлена и почему стоит сделать первый шаг.

Илья подчёркивает, что призыв к действию (CTA) не должен сразу требовать большого обязательства. Он должен соответствовать первой микрозадаче — действию, которое пользователь готов совершить сейчас, чтобы снизить неопределённость.

В электронной коммерции эта логика особенно важна из-за discovery и гипервыбора. Покупатель может приходить не за SKU, а с ситуацией: выбрать фильм на вечер, подобрать подарок, найти кроссовки, парфюм или технику. Если сервис построен вокруг структуры товарной базы, человек вынужден сам определить критерии, сравнить варианты и снизить риск ошибки. Чем длиннее этот путь, тем выше вероятность, что он откажется не только от конкретного магазина, но и от всей покупки — например, выберет сериал, прогулку или другую альтернативу для более высокой работы «кайфануть».

JTBD и ИИ: структура вопроса важнее скорости ответа

Иван считает, что современные модели могут ускорять генерацию гипотез сегментов, графов работ, посадочных страниц, тарифов и сценариев. Но Илья подчёркивает: общий запрос к ИИ даёт усреднённый результат. Чтобы использовать модель содержательно, нужно заранее описать сегмент, ситуацию, работу, ограничения, триггер и критерии успеха.

Следовательно, ИИ в этой логике не заменяет понимание клиента. Он сокращает стоимость поиска и тестирования возможных решений после того, как команда сформулировала правильную проблему.

С чего начать

Если продукт уже продаётся, практичный первый шаг — не новый список задач, а разговор с платящими клиентами, которые уже получают наибольшую ценность. Нужно выяснить их работы, контексты, критерии, барьеры и путь к покупке. Затем можно проверить, отражает ли коммуникация эту логику и действительно ли продукт доставляет результат в момент активной задачи.

Главный вывод дискуссии прост: продукт не обязан начинаться с CRM, курса, чекапа, нейросети или новой функции. Он должен начинаться с конкретной работы конкретного человека. А функция, интерфейс, команда и технология нужны постольку, поскольку помогают сделать эту работу лучше, быстрее, понятнее или с меньшим риском.