Вы когда‑нибудь запускали фичу, которая никому не нужна? Многие продуктовые команды регулярно сталкиваются с тем, что значительная часть новых функций почти не используется после релиза. Знакомая ситуация?
Меня зовут Сергей Прощаев, 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. Рекрутинг: где брать «правильных» людей
Вторая ошибка новичков: интервьюируют друзей, коллег или платят условным «респондентам с Авито». Не работает. Друг скажет то, что вы хотите услышать. А без хорошего скрининга платные панели часто дают низкое качество интервью.
Мои проверенные каналы (по убыванию эффективности):
Ваша CRM / база пользователей — если продукт уже есть. Пишите лично тем, кто активно пользуется, но не ограничивайтесь только супердовольными пользователями — их сценарии могут отличаться от основной аудитории. Обязательно включайте тех, кто отвалился. Отвалившиеся — золотая жила.
Профессиональные сообщества — Telegram‑чаты по вашей теме (не продавать, а просить помощи в исследовании). Работает, если вы сами активны и уважаемы там.
LinkedIn / HH — ищите людей с нужной должностью и отправляйте персонализированный запрос. Шаблон: «Иван, я исследую проблему X (конкретную). Вижу, вы работаете в этой сфере. Могу я задать вам 3 вопроса в чате? Никаких продаж». В моей практике персонализированные сообщения дают примерно 10–30% ответов.
Targeted ads — самый дорогой способ. Используйте, если другие не сработали.
Как проверить:
После того как вы нашли 5–8 человек из нужного сегмента, проверьте: хотя бы двое из них должны не знать вас лично (чтобы исключить bias). Записывайте сессии (спросив разрешения) — это поможет вернуться к деталям.
Шаг 3. Скрипт интервью: таблица «плохих» и «хороших» вопросов
Треть больших фейлов — неправильные вопросы. Вы не читаете список, вы ведёте беседу.
Вот таблица, которую я распечатываю перед каждым интервью.
Тип вопроса | Плохо (не задавайте) | Почему плохо | Хорошо (вот это работает) |
Оценка будущего поведения | «Вы бы стали пользоваться функцией X?» | Люди переоценивают свою активность | «Расскажите, как вы решали задачу Y на прошлой неделе» |
Гипотетические предпочтения | «Вам нравится дизайн А или Б?» | Нет связи с реальным действием | «Покажите экран, который вы обычно открываете первым» |
Общие боли | «Что вас раздражает в работе?» | Слишком абстрактно | «Назовите последний случай, когда вы потратили >30 минут на рутинную операцию» |
Социальное одобрение | «Как вы следите за безопасностью данных?» | Все считают себя молодцами | «Расскажите о случае, когда вы случайно слили данные не тому человеку» |
Как проверить:
Возьмите одну из последних записей интервью и найдите 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‑сессий мне чаще хватает простой таблицы вместо тяжёлого качественного кодирования.
Прямая цитата / факт | Боль | Проверяемая гипотеза |
«Я дважды в неделю трачу час на сверку накладных в Excel» | Ручная сверка отнимает время | Автоматическая сверка снизит время до 5 минут → гипотеза подтверждена |
«Мне бы настройки уведомлений, но я всё равно читаю всё в одном канале» | Противоречие: хочет настройки, но поведение говорит об обратном | Гипотеза о необходимости сложных фильтров не подтверждена → делать минимально |
Как проверить:Возьмите три ключевые боли из таблицы. Для каждой напишите простейшее решение, которое можно реализовать за 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‑направлениям, чтобы было проще выбрать интересную тему и заранее зарегистрироваться.