Проблемное интервью: как спрашивать о прошлом опыте клиента

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

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

Зачем в проблемном интервью спрашивать о прошлом опыте

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

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

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

Какие вопросы возвращают к реальному эпизоду

Лучше всего работают вопросы, которые привязывают собеседника ко времени и событию. Вместо «что вам не нравится в отчетах?» спросите: «Вспомните последний раз, когда вам понадобился отчет. Что вы хотели получить и что сделали сначала?» Такой заход помогает не уйти в рассуждения о том, как «в идеале должно быть», и постепенно выводит на конкретные шаги.

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

Учебный пример

Учебный пример. Команда делает сервис учета расходов для небольших студий. На интервью собеседника не спрашивают: «Нужна ли вам гибкая категоризация?» Вместо этого задают цепочку: «Когда вы в последний раз разбирали расходы по проектам?», «С чего начали?», «На каком шаге стало неудобно?», «Что сделали дальше?», «Чем закончили?». Собеседница отвечает, что в конце месяца открыла сервис, не смогла быстро отделить хозяйственные траты от расходов по конкретному заказу, выгрузила операции и вручную разметила их в таблице. Практическая польза такого ответа в том, что команда видит не просто жалобу, а сценарий: задача возникает регулярно, текущего способа недостаточно, а таблица служит обходным решением.

Как не подсказывать ответ

Наводящий вопрос опасен тем, что он подменяет исследование угадыванием. Если спросить: «Вам, наверное, не хватает фильтров по проектам?», собеседник часто соглашается просто потому, что вопрос уже предлагает объяснение. В итоге интервьюер слышит не чистый рассказ участника, а отражение собственной гипотезы.

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

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

Как фиксировать и разбирать ответы

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

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

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

Чего интервью не доказывает и как использовать выводы

Несколько разговоров не доказывают рынок и не устанавливают «главную проблему клиента» раз и навсегда. Они помогают обнаружить язык пользователя, типовые эпизоды, триггеры задачи и обходные решения. Этого достаточно, чтобы уточнить сегмент, переписать вопросы для следующей волны интервью, подготовить прототип или проверить конкретную гипотезу в продукте.

Поэтому формулировать выводы лучше осторожно. Не «мы выяснили, что основная проблема всех пользователей — категоризация», а «в интервью с владельцами небольших студий повторился сценарий ручной разметки расходов вне сервиса; это гипотеза для следующей проверки». Такая запись честнее и полезнее для команды: она сохраняет факты разговора и не обещает больше, чем исследование реально показало.

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

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