CustDev и JTBD: два взгляда на одну проблему — как выбрать подход и не запутаться

Разговор о том, как понять клиента и построить продукт, никогда не устареет. С одной стороны — Customer Development, практичный и системный метод поиска проблем и рынков. С другой — Jobs to Be Done, концепция, меняющая взгляд на мотивации пользователей. Эта статья подробно сравнит оба подхода, покажет, где они пересекаются, где расходятся, и даст практические рецепты, которые можно сразу применить в интервью, приоритизации и тестировании гипотез.

Откуда пришёл CustDev и почему он важен

Customer Development зародился вместе со стартап-методологией Эрика Риса и идеями Стива Бланка. Это не столько набор техник, сколько рамка работы над гипотезами о клиентах и рынке.

Суть в последовательном поиске: сначала найти проблему и первых клиентов, затем проверить решение и только потом масштабировать бизнес. Главное требование — быстро и дешево валидировать теории, прежде чем вкладывать большие ресурсы.

Ключевые принципы Customer Development

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

Второй — интервью ради знаний, а не ради подтверждения. Хорошая CustDev-интервью направлена на выявление реальной боли, а не на то, чтобы услышать то, что хочется услышать.

Типичный процесс CustDev

Процесс делится на четыре этапа: Customer Discovery, Customer Validation, Customer Creation и Company Building. В стартапе первые два — самые активные: вы ищете клиенты, тестируете гипотезы и собираете доказательства спроса.

Инструменты: открытые интервью, наблюдение за поведением, конструкторы гипотез, ранние MVP и простые эксперименты с ценой и каналами.

Что такое JTBD и как он мыслит продукт

Jobs to Be Done — это способ смотреть на потребности не через призму продукта или сегмента, а через «работу», которую человек пытается выполнить. Люди «нанимают» продукты, чтобы решить задачу в конкретном контексте.

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

Ключевые элементы JTBD

В JTBD выделяют функциональные, эмоциональные и социальные «работы». Функциональная задача — то, что нужно сделать; эмоциональная — как человек хочет себя чувствовать; социальная — как он хочет выглядеть в глазах других.

Также используется понятие «desired outcomes» — точные критерии успеха для клиента. Они превращают расплывчатые пожелания в измеримые требования.

Методы JTBD: карты работы, интервью и outcome-driven innovation

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

Методология Outcome-Driven Innovation (ODI) трансформирует собранные желания в ранжированные список метрик, которые можно целенаправленно улучшать.

Главные отличия подходов: взгляд сверху

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

В CustDev вы спрашиваете: «Какие у вас проблемы?» В JTBD вы выясняете: «Какой результат вы пытались получить в конкретной ситуации?» Оба вопроса полезны, но дают разные выводы.

Таблица сравнения основных характеристик

Как выглядят интервью в реальности: примеры вопросов

Ниже — практические примеры, которые вы можете взять в работу. Они разделены на CustDev и JTBD для ясности.

CustDev: вопросы для поиска проблемы

Расскажите, как вы сейчас решаете [область X]. Какие неудобства при этом возникают? Как часто это происходит?

Когда в последний раз у вас возникала эта проблема? Что вы тогда сделали? Какие альтернативы рассматривали?

JTBD: вопросы о последнем разе

Вспомните последний раз, когда вы пытались [выполнить работу]. Что привело к тому, что вы решили заняться этим? Как вы готовились?

Опишите последовательность действий от начала до конца. Что в процессе вы считали самым важным результатом? Какие компромиссы пришлось принять?

Практический шаблон JTBD: формула, которая работает

Удобная и простая структура для записи job-statement выглядит так: «Когда [ситуация], я хочу [мотивация/задача], чтобы [ожидаемый результат].»

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

Как протестировать гипотезы по каждому подходу

Для CustDev гипотеза формулируется как «существует сегмент, у которого есть проблема X и готовность платить Y». Тестируют через интервью, лендинги и pre-orders.

В JTBD гипотеза звучит как «при выполнении работы Z пользователи ценят улучшение в метрике M на N%». Тестируют через A/B, прототипы и измерение конкретных outcome.

Когда выбирать CustDev, а когда — JTBD

Если вы на самом старте — ищете, запустить ли вообще продукт, — CustDev даст структуру и дисциплину. Он помогает не строить замков в облаках, а шаг за шагом проверить рынок.

Если же у вас уже есть продукт и нужно понимать, почему люди выбирают один путь, а не другой, или как увеличить ценность — JTBD даст более точную картину мотиваций и критериев успеха.

Как объединить оба подхода — практическая стратегия

Используйте CustDev, чтобы найти сегменты и выявить сильные боли. Затем применяйте JTBD для глубокого анализа мотивов и формулировки outcome для продуктовых эксперимент.

В интервью можно комбинировать: начать с вопросов по CustDev, чтобы выявить проблему, затем перейти в JTBD-режим и разбирать последний конкретный случай. Такой микс даёт и ширину, и глубину.

Метрики и KPIs: что измерять

В рамках CustDev ключевые метрики — конверсия интервью в заинтересованных пользователей, количество предзаказов, retention первого цикла. Это практические индикаторы спроса.

В JTBD важно фиксировать outcome-метрики: время выполнения работы, количество шагов, уровень неудовлетворённости, процент успешных попыток. Они помогают увидеть, насколько вы действительно улучшаете «работу».

Ошибки, которые часто совершают команды

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

Вторая — смешивать персон и Jobs. Демография не всегда объясняет поведение. Фокус на сегментах по транзакциям и ситуациям часто эффективнее.

Типичные ловушки при применении JTBD

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

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

Типичные ловушки при применении CustDev

Иногда команды останавливаются на этапе discovery, собирают инсайты, но не переходят к валидным экспериментам. Результат — много знаний, но нет действий и продукта.

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

Практический кейс: как я использовал оба подхода

Однажды в проекте для фрилансеров мы сначала проводили CustDev-интервью, чтобы понять болезненные точки: неопределённость в сроках оплаты и трудности с поиском клиентов.

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

На основе этого мы приоритизировали фичи, которые ускоряли согласование условий и давали четкий статус сделки. Эксперименты показали рост conversion-to-paid на 17% в течение месяца.

Как структурировать интервью: чек-лист и шаблон

Чек-лист для CustDev: 1) Представиться и объяснить цель; 2) Попросить рассказать о текущих практиках; 3) Выяснить частоту и последствия проблемы; 4) Узнать альтернативы и готовность платить.

Шаблон JTBD-интервью: 1) Найдите и зафиксируйте конкретный последний случай; 2) Пройдите по хронологии событий; 3) Выделите ключевые боли и мотивации; 4) Попросите описать желаемый результат в деталях.

Шаблоны для записи инсайтов

Для CustDev используйте блоки: «Проблема», «Частота», «Текущие решения», «Готовность платить». Это помогает быстро агрегировать ответы и сравнивать сегменты.

Для JTBD фиксируйте: «Ситуация», «Шаги действия», «Ключевые триггеры», «Желаемые результаты». Так вы получите набор измеримых outcome, которые можно использовать в приоритизации.

Как приоритизировать фичи по результатам JTBD

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

Этот подход помогает уходить от «списка фич» и фокусироваться на реальной ценности для клиента.

Инструменты, которые помогают собирать и анализировать данные

Для CustDev полезны CRM и простые таблицы, в которых фиксируются интервью, гипотезы и статусы кандидатов на клиента. Для JTBD удобны матрицы outcome и визуальные карты работы.

Также полезно подключать аналитические события продукта к outcome-метрикам — так вы слышите и качественные, и количественные сигналы одновременно.

Как масштабировать процессы интервью в компании

Начните с обучения небольшого числа сотрудников технике интервью. Сделайте шаблоны и обязательную запись аудио для последующего анализа. Чем больше команд умеют правильно слушать, тем быстрее вы получите качественные инсайты.

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

Юридические и этические моменты

Записывайте интервью только с согласия респондента и объясняйте цель использования данных. Бережное отношение к приватности укрепляет доверие и повышает качество разговоров.

Не собирайте лишние личные данные и не используйте инсайты для манипуляций — длительный успех продукта строится на честных отношениях с пользователями.

Чек-лист перед запуском эксперимента

• Чётко сформулированы гипотезы и критерии успеха.
• Есть план сбора данных и ответственные люди.
• Подготовлены шаблоны для интервью и записи инсайтов.
• Запланирован временной интервал теста и минимальная выборка.

Когда подходы не помогут

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

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

Краткая памятка: что спрашивать первым делом

Начните с «Расскажите о последнем разе, когда вы…». Это работает и для CustDev, и для JTBD — такой вопрос переводит собеседника в конкретный кейс, а не в абстрактные рассуждения.

Избегайте вопросов вроде «Что вы думаете о…», если только вы не готовите тест на восприятие концепта. В большинстве случаев важнее реальные действия и решения.

Как объяснить команде ценность обоих подходов

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

Организуйте воркшопы, где команда проводит несколько быстрых интервью и сразу анализирует результаты — опыт перевешивает слова.

Резюме действий на ближайший месяц

Неделя 1: сформулируйте 3–5 ключевых гипотез о проблемах и однажды проверьте их через CustDev-интервью.

Неделя 2: выберите 5 реальных кейсов и проведите JTBD-интервью, чтобы задокументировать desired outcomes.

Неделя 3: приоритизируйте фичи по важности и неудовлетворённости outcomes, запустите минимум один эксперимент.

Неделя 4: соберите данные, оцените метрики и скорректируйте дорожную карту.

Заключительные практические рекомендации

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

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

ПОЛУЧИТЬ БЕСПЛАТНУЮ КОНСУЛЬТАЦИЮ