27.07.2026
CustDev: интервью, анализ сигналов и решения по продукту
Интервью само по себе ничего не подтверждает. CustDev становится полезным, когда команда заранее определяет решение, собирает факты о реальном поведении и меняет продукт по понятному критерию.
CustDev — это исследовательский цикл, который помогает команде проверить предположения о клиентах до дорогой разработки или изменения продукта. Сначала формулируют решение, для которого не хватает фактов. Затем выбирают подходящих респондентов, обсуждают их недавнее поведение, отделяют наблюдения от интерпретаций и принимают одно из решений: продолжать, изменить гипотезу, сузить сегмент, провести другой тест или остановиться.
Главный результат CustDev — не расшифровки и не список пожеланий. Это изменение продуктового решения с понятным основанием. Если после интервью команда только лучше «почувствовала аудиторию», но не знает, что делать с продуктом, ценой, сценарием или следующим экспериментом, исследовательский цикл не закончен.
Что такое CustDev
Customer Development, или CustDev, — способ проверять гипотезы о клиенте, проблеме, способе выбора и ценности продукта через контакт с реальными или вероятными пользователями. Интервью — один из методов. Наблюдение, разбор текущего процесса, прототип, предзаказ и анализ фактического поведения могут потребоваться, чтобы проверить то, что человек не способен подтвердить одним разговором.
CustDev отвечает не на общий вопрос «нравится ли людям идея», а на более узкие рабочие вопросы:
- у кого и в какой ситуации возникает проблема;
- как человек решает её сейчас;
- насколько велики частота, стоимость и последствия проблемы;
- кто пользуется решением, кто платит и кто блокирует покупку;
- что должно измениться, чтобы человек попробовал другой способ;
- какой риск нужно снять до следующей инвестиции.
Разговор помогает увидеть контекст и язык клиента. Но намерение, высказанное в интервью, не равно покупке. Чем ближе решение к деньгам, смене процесса или длительному внедрению, тем важнее дополнять слова действием: заявкой, тестом прототипа, передачей данных, выделенным временем, пилотом или оплатой.
С какого решения начинать исследование
Слабая постановка звучит так: «поговорить с клиентами и найти инсайты». Она не задаёт границ, поэтому почти любой ответ кажется полезным. Сильная постановка называет решение и цену ошибки.
Например:
- выбрать первый сегмент для пилота;
- понять, стоит ли добавлять новую функцию;
- решить, кто должен быть покупателем B2B-продукта;
- проверить, почему пользователи не доходят до первого результата;
- определить, какой ручной процесс допустимо автоматизировать;
- остановить направление, если проблема не подтверждается.
Перед рекрутингом полезно заполнить короткий паспорт исследования:
Решение
- Рабочий вопрос: Что команда должна выбрать после исследования?
Гипотеза
- Рабочий вопрос: Что мы сейчас считаем правдой, но ещё не доказали?
Сегмент
- Рабочий вопрос: У кого есть нужный опыт, ситуация или роль?
Сигнал
- Рабочий вопрос: Какое наблюдение поддержит или ослабит гипотезу?
Альтернатива
- Рабочий вопрос: Как человек решает задачу сегодня?
Цена ошибки
- Рабочий вопрос: Что произойдёт, если мы продолжим без проверки?
Следующий тест
- Рабочий вопрос: Какое действие проверит вывод после интервью?
Эта таблица — фильтр. Если вопрос интервью не помогает заполнить ни одно поле, его можно убрать.
Гипотеза должна допускать опровержение
Фраза «клиентам важен удобный сервис» почти бесполезна: с ней трудно не согласиться и невозможно понять, что менять. Проверяемая гипотеза связывает ситуацию, поведение и последствие.
Рабочий каркас:
В ситуации X люди из сегмента Y сталкиваются с Z, поэтому уже делают A и несут B. Если предложить C, они будут готовы совершить D.
Не все части нужно подтверждать одним интервью. Разговор хорошо раскрывает ситуацию, текущий способ, ограничения и критерии выбора. Готовность совершить действие лучше проверять действием.
Для существующего продукта гипотеза может начинаться с данных. Например: пользователи создают проект, но не приглашают команду. Интервью должно выяснить, что происходит вокруг этого момента: кто принимает решение, чего не хватает, какую работу пользователь продолжает делать в другом инструменте. Оно не должно подменять вопрос формулировкой «почему вам не нравится приглашение коллег».
Кого приглашать на интервью
Респондент подходит не потому, что похож на усреднённый портрет аудитории, а потому, что пережил нужную ситуацию и принимал связанное с ней решение.
Критерии рекрутинга лучше строить вокруг опыта:
- делал нужное действие за конкретный недавний период;
- выбирал между релевантными альтернативами;
- участвовал в покупке или использовании;
- сталкивался с ограничением, которое исследует команда;
- способен восстановить конкретный случай.
В B2B часто нужны разные роли. Пользователь, руководитель, закупщик, служба безопасности и собственник могут видеть один продукт по-разному. Нельзя взять интервью только у пользователя и объявить подтверждённой гипотезу о покупке. Полезно заранее разделить:
- кто сталкивается с проблемой;
- кто выполняет работу;
- кто оценивает результат;
- кто выделяет бюджет;
- кто согласует внедрение;
- кто несёт риск.
GOV.UK приводит ориентир в 4–8 участников на один исследовательский раунд для интервью и ряда других качественных методов. Это не универсальная «достаточная выборка». Раунд нужен, чтобы получить сигналы, изменить вопросы и провести следующую итерацию, если решение остаётся неопределённым.
Какие интервью нужны
Название метода менее важно, чем исследовательская задача.
Проблемное интервью
Нужно, когда команда проверяет ситуацию, текущий способ решения, частоту и последствия проблемы. Здесь рано показывать продукт: демонстрация направит разговор к вашей идее.
Интервью о процессе выбора
Помогает восстановить путь от первого сигнала до покупки: где человек искал варианты, кого привлекал, с чем сравнивал, чему доверял и почему отложил решение.
Интервью по существующему продукту
Разбирает конкретный опыт использования: что человек пытался сделать, где остановился, чем заменил функцию и что произошло дальше. Его полезно связывать с продуктовой аналитикой и обращениями поддержки.
Проверка концепции или прототипа
Проводится после того, как проблема и сценарий получили достаточное основание. Здесь исследуют понимание предложения и прохождение сценария, а не просят оценить красоту идеи.
Один разговор может включать несколько частей, но нельзя незаметно переходить от исследования проблемы к продаже решения. Респондент начинает быть вежливым, угадывать ожидаемый ответ и обсуждать воображаемое будущее.
Как составить гайд интервью
Гайд — опора, а не анкета. Он помогает нескольким интервьюерам пройти одинаковые темы, но оставляет место для уточнений.
Рабочая последовательность:
- Объяснить цель разговора, формат, хранение данных и получить согласие на запись.
- Уточнить роль и контекст человека.
- Попросить восстановить последний конкретный случай.
- Разобрать триггер, действия, альтернативы и участников.
- Выяснить затраты, риски и критерии выбора.
- Проверить противоречия и непонятные места.
- Только при необходимости показать концепцию или прототип.
- Объяснить, что будет с материалами после разговора.
Нейтральные вопросы опираются на прошлое поведение:
Вам нужна автоматизация отчёта?
- Спросить: Как вы собирали последний отчёт?
Вы бы купили такой сервис?
- Спросить: Когда вы в последний раз платили за похожее решение?
Вам важна скорость?
- Спросить: Что произошло, когда результат задержался?
Эта функция удобная?
- Спросить: Покажите, как вы решаете эту задачу сейчас.
Сколько вы готовы платить?
- Спросить: Как сейчас формируется бюджет на эту работу?
Вам мешает ручной процесс?
- Спросить: Какие действия приходится повторять и кто их выполняет?
Вопрос «почему?» иногда заставляет человека рационализировать поведение задним числом. Конкретнее работают уточнения: «Что произошло перед этим?», «Кто участвовал?», «Что вы сделали дальше?», «На что потратили время или деньги?».
Как проводить разговор
Интервьюер должен слышать больше, чем говорить. Полезный темп создают короткие вопросы и паузы. Если человек отвечает общими словами, его возвращают к случаю: «Вспомните последний раз», «Покажите документ», «Каким был первый шаг?».
Во время разговора важно фиксировать разные уровни:
- точное наблюдение или высказывание;
- контекст, в котором оно возникло;
- предположение исследователя;
- вопрос, который осталось проверить.
Эти уровни нельзя смешивать в одной заметке. Фраза «пользователь не доверяет отчёту» — уже интерпретация. Наблюдение может звучать так: «перед отправкой руководителю выгрузил данные и пересчитал три показателя в своей таблице».
Если присутствуют наблюдатели, им заранее объясняют правила. Они не отвечают за респондента, не спорят и не превращают разговор в демонстрацию продукта. После встречи наблюдения собирают до общего обсуждения, чтобы мнение самого старшего участника не стало единственным выводом.
Как разобрать интервью
Расшифровка — сырьё. Анализ начинается с отделения фактов от объяснений и заканчивается решением.
Практический порядок:
- Сразу после разговора зафиксировать контекст и неожиданные сигналы.
- Разложить заметки на атомарные наблюдения: одно действие, факт или точная реплика на карточку.
- Сгруппировать наблюдения по ситуациям, этапам, альтернативам и ограничениям.
- Отметить повторения и важные исключения.
- Сформулировать вывод как проверяемое объяснение.
- Связать вывод с решением команды.
- Назначить следующий тест, владельца и срок.
GOV.UK рекомендует анализировать исследовательский раунд вместе с наблюдавшими участниками и делать это как можно скорее, пока детали свежи. Такой разбор уменьшает зависимость от личной интерпретации одного исследователя.
Матрица «гипотеза — сигнал — решение»
Рабочий артефакт CustDev должен показывать не количество цитат, а логику решения.
У сегмента есть повторяемая проблема
- Наблюдаемые сигналы: Конкретные недавние случаи, затраты, обходные способы
- Что противоречит: Только общие рассуждения
- Уверенность: Низкая / средняя / высокая
- Решение: Продолжить, сузить или остановить
- Следующий тест: Наблюдение, прототип, пилот
Покупатель и пользователь различаются
- Наблюдаемые сигналы: Разные роли, бюджет и критерии
- Что противоречит: Решение принимает один человек
- Уверенность: …
- Решение: Изменить сегментацию и сообщение
- Следующий тест: Интервью с ЛПР
Ценность возникает в одном сценарии
- Наблюдаемые сигналы: Повторяющееся действие и принятый результат
- Что противоречит: Нужны разные несвязанные сценарии
- Уверенность: …
- Решение: Сузить MVP или разделить продукт
- Следующий тест: Прототип полного цикла
Клиент готов менять процесс
- Наблюдаемые сигналы: Уже выделяет время, данные или деньги
- Что противоречит: Хвалит идею, но ничего не меняет
- Уверенность: …
- Решение: Проверить обязательство
- Следующий тест: Предзаказ или пилот
Уверенность не нужно превращать в псевдоточную формулу. Достаточно назвать силу доказательства и пробел. Один яркий рассказ может открыть важную гипотезу, но не доказывает её распространённость.
Как принимать решение после раунда
У команды должно быть ограниченное меню действий:
- продолжать — сигналы достаточно сильны для следующего теста;
- сузить сегмент — проблема подтверждается только в конкретной ситуации;
- изменить гипотезу — факты показывают другой механизм;
- разделить роли — пользователь, покупатель и владелец риска требуют разных исследований;
- сменить метод — разговор больше не снимает неопределённость;
- остановить — проблема слаба или решение не стоит следующей инвестиции.
Решение «провести ещё интервью» допустимо только с объяснением, какой пробел они закроют. Иначе исследование становится способом отложить неприятный выбор.
Пример применения
Представим B2B-сервис, который должен ускорить согласование коммерческих предложений. Команда считает, что менеджерам мешает отсутствие общего шаблона.
Интервью восстанавливают последние согласования. Выясняется, что шаблон уже есть, но финальную цену каждый раз подтверждают финансы, юридические условия — юрист, а нестандартный объём — руководитель направления. Менеджер копирует данные между письмами и таблицей не из-за плохого шаблона, а потому что правила исключений нигде не закреплены.
Такой результат не доказывает, что продукт не нужен. Он меняет предмет следующего теста. Вместо редактора шаблонов команда проверяет схему правил, ролей и статусов на одном типе предложения. Если цикл действительно сокращается и участники принимают результат, появляется основание для автоматизации.
Это гипотетический пример механизма, а не опубликованный кейс Vitaly.team.
Ошибки, которые делают CustDev бесполезным
Спрашивать о будущем. Люди вежливо обещают пользоваться тем, чего ещё нет.
Показывать решение слишком рано. Разговор начинает проверять презентацию, а не проблему.
Рекрутировать знакомых без нужного опыта. Получается обратная связь, но не данные о целевой ситуации.
Собирать пожелания функций. Респондент предлагает знакомую форму решения, не зная ограничений продукта.
Считать повторение доказательством рынка. Качественное исследование объясняет механизм; масштаб проверяется другими данными.
Игнорировать исключения. Неудобный случай может показать новый сегмент или критичный риск.
Не подключать команду к анализу. Выводы остаются презентацией исследователя и не меняют бэклог.
Проводить интервью без решения. Объём материалов растёт, критерий остановки отсутствует.
Когда CustDev не подходит
Интервью не заменяют:
- проверку удобства конкретного интерфейса;
- количественную оценку размера сегмента;
- анализ причин технической ошибки;
- юридическую, финансовую или медицинскую экспертизу;
- эксперимент с ценой и фактической покупкой;
- наблюдение за процессом, который человек плохо помнит;
- анализ продуктового поведения, если событие уже измеряется.
Если вопрос звучит «могут ли пользователи найти кнопку», нужен usability-тест. Если «сколько клиентов уйдёт после повышения цены» — поведенческий или коммерческий эксперимент. Если «почему сотрудники обходят новый процесс» — интервью полезно сочетать с наблюдением, данными и разбором правил работы.
Согласие и исследовательские данные
До записи нужно объяснить цель исследования, кто получит доступ к материалам, как долго они хранятся и может ли участник отозвать согласие. Личные данные собирают в минимальном объёме. Цитаты для внутреннего решения и публичная публикация — разные способы использования, для них могут потребоваться разные согласия.
Запись не стоит отправлять широкой группе «на всякий случай». Для командного разбора достаточно ограниченного доступа, обезличенных наблюдений и понятного срока удаления. Конкретные требования зависят от типа данных и юрисдикции; исследовательский гайд не заменяет правовую проверку.
Вопросы о CustDev
Сколько интервью нужно провести
Фиксированного числа, которое подтверждает гипотезу, нет. Планируйте короткие раунды с конкретным вопросом, проверяйте качество рекрутинга и смотрите, снимается ли неопределённость. Если новые интервью повторяют известное, но команда всё ещё не может принять решение, возможно, нужен другой метод.
Какие вопросы задавать на CustDev
Просите восстановить недавний случай: что произошло, кто участвовал, как человек действовал, какие альтернативы использовал, что потерял и чем завершилась ситуация. Избегайте вопросов о желаемых функциях и обещаниях будущей покупки.
Чем CustDev отличается от опроса
Интервью раскрывает контекст, последовательность действий и причины выбора. Опрос проверяет заранее сформулированные варианты на большей выборке. Опрос трудно составить качественно, если команда ещё не знает языка проблемы и возможных ответов.
Можно ли проводить CustDev с текущими клиентами
Да, если исследуется использование существующего продукта или следующий сценарий. Но текущие клиенты уже прошли фильтр покупки и могут не представлять тех, кто отказался, ушёл или выбирает альтернативу. Состав респондентов должен соответствовать решению.
Что должно остаться после исследования
Зрелый цикл CustDev оставляет команде:
- паспорт решения и гипотезы;
- критерии рекрутинга;
- гайд и правила согласия;
- атомарные наблюдения;
- карту повторяющихся ситуаций и исключений;
- матрицу «гипотеза — сигнал — решение»;
- список отвергнутых объяснений;
- следующее действие, владельца и срок проверки.
Исследование пользователей полезно не количеством разговоров, а качеством следующего решения. Если команда может показать, какой факт изменил выбор и как это будет проверено в продукте, CustDev выполнил работу.
Связанные материалы: UX-исследования под конкретный продуктовый вопрос, product-market fit и сигналы повторяемого спроса, разработка SaaS-продукта до MVP.
Разобрать продуктовую гипотезу полезно, когда интервью уже проведены, а решение всё ещё зависит от интерпретаций, или когда дорого начинать разработку без проверяемого вопроса.