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

Меня зовут Сергей Прощаев, Tech Lead и руководитель направления Java/Kotlin разработки в FinTech & E‑commerce, а также преподаю на курсах разработки и архитектуры в OTUS. Я сам как‑то попал в эту ловушку. Мы делали платформу для управления лояльностью, и один из крупных ритейлеров попросил «а давайте ещё виджет с персонализированными скидками». Сделали — красиво, с алгоритмами, на два спринта больше.

В итоге виджетом никто не пользовался. Клиент сказал: «Ну, я же просил просто кнопку „выгрузить отчёт“„. С тех пор я твёрдо усвоил: сначала проверка гипотез через интервью, потом код. Даже если очень хочется накидать архитектуру на салфетке.“»

Важное уточнение. В этой статье под «кастдевом» я имею в виду problem interviews — пользовательские интервью для проверки проблем и гипотез на раннем этапе discovery. Формально customer development (по Стиву Бланку) шире: он включает customer discovery, validation, creation и company building. Но здесь мы сфокусируемся именно на интервью — самом практичном и доступном инструменте для продуктовых команд.

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

Исходные условия (для кого и когда это работает)

Эта инструкция — для команд от 3 до 50 человек, которые разрабатывают цифровой продукт (b2b или b2c). У вас нет бюджета на дорогие исследования, но есть доступ к клиентам через CRM, чаты или личные контакты. Срок — одна‑две недели на проверку гипотезы. Если у вас госсектор или сверхчувствительные данные — см. раздел ограничений в конце.

Почему опросов недостаточно для discovery

Помню, как один продакт из финтеха рассказывал: «Мы провели опрос среди 500 пользователей, 82% сказали, что им нужен тёмный режим. Сделали — падение метрик в ночное время не изменилось». Классика. Между декларируемым поведением и реальными действиями часто есть разрыв.

Опросы хороши для количественной проверки уже найденных паттернов, но плохо подходят для поиска реальных пользовательских проблем с нуля. В интервью мы не просим пользователя предсказывать своё поведение. Мы просим рассказать конкретный случай из прошлого. Подходы дают принципиально разный тип данных. Вместо «Что вы думаете о новой фиче?» — «Расскажите про последний раз, когда вы искали информацию о своем балансе».

Вот как выглядит типичный провал без качественных интервью — и как его можно избежать (рис. 2).

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

Справа — путь с problem discovery: сначала 5–7 интервью с пользователями (кастдев), затем проверка, есть ли реальная боль. Если боль подтверждена — делается простой прототип за 1 спринт, который идёт в релиз с измеримыми метриками. Если боли нет — команда отказывается от идеи или переформулирует её, экономя ресурсы.

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

Шаг 1. Гипотеза и сегмент: что проверяем и у кого

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

Плохая гипотеза: «Посмотрим, что скажут про интеграцию с CRM».
Хорошая: «Мы предполагаем, что менеджеры по продажам из сегмента малого бизнеса (до 20 сотрудников) тратят более 2 часов в неделю на ручной перенос данных из email‑рассылок в CRM. Если мы сделаем однокнопочный импорт, они согласятся пользоваться им постоянно и продлят подписку».

Как проверить, что вы сделали это правильно:
Выпишите одну гипотезу в формате «Если мы сделаем X, то сегмент Y начнёт делать действие Z, и это измеримо». Покажите её коллеге. Если он может переформулировать её иначе или задаёт уточняющие вопросы — гипотеза ещё сырая. Идеально, когда коллега сразу говорит: «Да, это именно та боль, которую мы видим в логах».

Шаг 2. Рекрутинг: где брать «правильных» людей

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

Мои проверенные каналы (по убыванию эффективности):

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

2. Профессиональные сообщества — Telegram‑чаты по вашей теме (не продавать, а просить помощи в исследовании). Работает, если вы сами активны и уважаемы там.

3. LinkedIn / HH — ищите людей с нужной должностью и отправляйте персонализированный запрос. Шаблон: «Иван, я исследую проблему X (конкретную). Вижу, вы работаете в этой сфере. Могу я задать вам 3 вопроса в чате? Никаких продаж». В моей практике персонализированные сообщения дают примерно 10–30% ответов.

4. Targeted ads — самый дорогой способ. Используйте, если другие не сработали.

Как проверить:
После того как вы нашли 5–8 человек из нужного сегмента, проверьте: хотя бы двое из них должны не знать вас лично (чтобы исключить bias). Записывайте сессии (спросив разрешения) — это поможет вернуться к деталям.

Шаг 3. Скрипт интервью: таблица «плохих» и «хороших» вопросов

Треть больших фейлов — неправильные вопросы. Вы не читаете список, вы ведёте беседу.

Вот таблица, которую я распечатываю перед каждым интервью.

Как проверить:
Возьмите одну из последних записей интервью и найдите 3 вопроса, которые были заданы в «плохой» форме. Переформулируйте их в «хорошие» по таблице. Убедитесь, что новый вопрос не наталкивает на ответ и не содержит предположений.

Главная ловушка кастдева — confirmation bias

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

Самый сильный сигнал реальной боли — существующий workaround

Один из лучших индикаторов того, что проблема действительно влияет на поведение, — уже существующий костыль. Excel‑файл, Telegram‑чат, ручной экспорт, самописный скрипт, дополнительный сотрудник — всё это признаки того, что люди уже потратили время и силы, чтобы обойти ограничение. Если пользователь говорит «да, было бы удобно», но за долгое время никак не изменил своё поведение и не создал workaround, стоит дополнительно проверить, насколько проблема действительно влияет на его работу. Если же он показывает вам свою Google‑таблицу, которую ведёт вторую неделю, — вы нашли золото.

Шаг 4. Техника контекстных вопросов (адаптированные «пять почему»)

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

Я использую последовательные уточняющие вопросы — адаптацию техники «пять почему» (5 Whys) под product discovery. Важно: это не строгая root cause analysis, а способ вытянуть контекст и мотивацию. Не пытайтесь любой ценой дойти до «единственной истинной причины» — ищите сценарии и границы.

Диалог из реального интервью (логистическая компания):

— Мне нужен дашборд с графиками статусов доставки.
— Зачем вам именно графики?
— Чтобы быстро видеть узкие места.
— А что вы делаете, когда видите узкое место в списке или таблице?
— Ну, звоню водителю или диспетчеру.
— А если бы система сама звонила водителю при превышении времени ожидания? (это уже ближе к решению, но на этом этапе допустимо для уточнения)
— О, это было бы круто. Но мне нужно ещё видеть историю.

В итоге мы поняли, что настоящая потребность — не графики, а алерт‑система с простым логом действий. Сделали не дашборд, а Telegram‑бота с кнопками «Позвонить» и «Отложить». Дешевле и быстрее.

Как проверить:
На каждом вопросе, который начинается с «мы могли бы», сделайте паузу и переспросите: «А что конкретно произошло в последний раз?». Если человек не может вспомнить ни одного конкретного сценария или workaround, стоит дополнительно проверить, насколько проблема действительно влияет на поведение.

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

Шаг 5. Анализ и решение: матрица приоритетов

Несколько интервью позади (для узкого однородного сегмента первые повторяющиеся паттерны обычно начинают проявляться после 5–7, но насыщение может потребовать 5–15 интервью в зависимости от гетерогенности аудитории). Вы наговорили десятки страниц расшифровок. Что дальше? Для небольших discovery‑сессий мне чаще хватает простой таблицы вместо тяжёлого качественного кодирования.

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

Где problem interviews не сработают (честные ограничения)

• B2G (государственные контракты) — требования спускаются сверху, интервью с реальными пользователями часто бесполезны.

• Совсем новые рынки (например, квантовые вычисления для ритейла) — у клиентов нет опыта, чтобы рассказать о боли. Тут подходит product discovery через эксперименты.

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

Реальная история из практики: как мы чуть не запилили «убийцу Slack»

Как‑то ко мне пришёл знакомый CEO стартапа. Они хотели сделать корпоративный мессенджер с ИИ‑расшифровкой встреч. Инвесторы горели новой идеей, команда наняла 5 разработчиков. Я предложил сначала провести 3–4 интервью с потенциальными клиентами. CEO не хотел («мы и так всё знаем»), но согласился.

Первое интервью с HR‑директором: «Как вы сейчас ищете информацию по прошедшим встречам?» — «Открываю Google Drive, ищу по дате, открываю PDF и жму Ctrl+F». Второе — IT‑директор: «У нас запрещены любые мессенджеры, кроме email. Slack не пускаем». Третье — операционный менеджер: «Я бы не хотел, чтобы ИИ слушал наши совещания про зарплаты».

Конечно, трёх интервью недостаточно для статистических выводов. Но они показали, что исходная гипотеза была слишком общей и требует пересегментации. Стартап переориентировался на нишевый продукт — расшифровку звонков в поддержке (где запись уже ведётся по регламенту). По оценке команды, это сэкономило сотни тысяч долларов на разработке и go‑to‑market.

Problem interviews — это не только про то, что делать, но и про то, чего НЕ делать. Отказ от идеи — тоже результат.

Что в итоге: мой личный чек‑лист перед стартом любой фичи

• Сформулирована гипотеза в формате «Если мы сделаем X, то сегмент Y начнёт делать действие Z, и это измеримо».

• Проведено достаточно интервью для появления повторяющихся паттернов (для узкого сегмента — обычно 5–15, пока не наступит насыщение). Респонденты — не друзья и не коллеги.

• В интервью не было вопросов «вы бы купили?», только ретроспективные факты и конкретные ситуации.

• Зафиксированы 3 прямые цитаты, которые подтверждают или опровергают гипотезу.

• Определён минимальный вариант решения (MVP), который можно проверить за 2 спринта.

• Есть понимание, какую метрику мы улучшим и как замерим результат после релиза.

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

Приглашение на реальную практику

Если хотите не просто читать про кастдев, а системно прокачать продуктовый подход, присмотритесь к курсу «Менеджер продукта в ИТ». На курсе разбирают discovery, проверку гипотез, работу с пользователями, метриками и AI‑инструментами, которые помогают быстрее переходить от идеи к проверенному продуктовому решению.

Перед стартом курса можно прийти на открытые вебинары и познакомиться с преподавателями‑практиками:

• 3 июня в 19:00 — «Кастдевы с интерактивом / исследование потребителей в теории и на практике». Записаться
  _{Покажем, как задавать вопросы, которые раскрывают реальные боли клиентов и помогают не тратить бюджет на фичи, которые никому не нужны.}

• 17 июня в 19:00 — «Как продакту проверять гипотезы быстрее с помощью AI». Записаться
  _{Объясним, как AI сокращает путь от идеи до вывода: меньше ручной работы, быстрее проверка, больше времени на сильные продуктовые решения.}

Участие бесплатное, регистрация открыта.

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