Вернуться на главнуюВсе материалы
Продукты5 минут

Интервью с клиентами перед запуском продукта: что спрашивать

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

01

Определите, кого приглашать

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

Для каждой роли запишите, что хотите узнать. Пользователь расскажет о повседневных неудобствах, руководитель — об ограничениях процесса, покупатель — о согласовании затрат. Не объединяйте их ответы в усреднённого клиента.

Что выясняем в интервью

01СитуацияКогда возникла задача
02ДействияКак её решали
03ЗатратыЧто потеряли или потратили
04РешениеКто выбирал и платил
Вопросы относятся к прошлому опыту. Намерение купить ещё не подтверждает спрос.
02

Восстановите последний реальный случай

Вместо «Вам был бы полезен такой сервис?» попросите: «Вспомните последний раз, когда возникла эта задача. Что произошло дальше?» Затем последовательно уточняйте действия, участников и результат. Исследование существующего опыта, препятствий и способов решения соответствует подходу discovery, описанному в руководстве GOV.UK 1.

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

03

Не превращайте разговор в презентацию

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

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

04

Спросите о последствиях и покупке

Уточните, что происходит, если задачу не решить. Теряется ли время, срывается ли работа, возникают ли ошибки? Затем спросите, кто принимает решение о смене инструмента, из какого бюджета платят и какие согласования нужны. Не просите назвать приемлемую цену раньше, чем поняли контекст.

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

05

Разделите наблюдения и выводы

После разговора сохраняйте конкретные факты отдельно от интерпретаций. «Сотрудник переносит записи между двумя таблицами» — наблюдение. «Нужна единая CRM» — предполагаемое решение, которое ещё предстоит проверить. Для каждого вывода полезно указать основание и альтернативное объяснение.

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

06

Вопросы для первого разговора

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

  • Когда вы в последний раз решали эту задачу?
  • Что стало причиной и что вы сделали сначала?
  • Какие инструменты и люди участвовали?
  • Где возникли задержки или ошибки?
  • Сколько времени или денег потребовало решение?
  • Кто выбирал способ работы и согласовывал расходы?
07

Источники и границы материала

Источники проверены 28 октября 2026. Практические шаблоны и учебные примеры — редакционная методика PODELUM, а не нормативы или результаты клиентских проектов.

1. GOV.UK: User research in discovery — Изучение текущего опыта, задач и препятствий до проектирования сервиса.

Практический итог

Проверьте себя

Обсуждайте прошлый опыт вместо обещаний купить.

Разделяйте пользователя, покупателя и руководителя.

Факты интервью не заменяют оценку размера рынка.

Продолжить по теме

Что подготовить перед разработкой MVP ↗︎Как проверить прототип до разработки: сценарий и критерии ↗︎Прототипы и MVP ↗︎