Пять-семь problem interviews до старта разработки могут сэкономить продуктовой команде месяцы работы над функцией, которой никто не будет пользоваться. Именно на этом акцентирует внимание OTUS в материале о кастдеве для IT-продактов: если проверять не идею интерфейса, а реальную пользовательскую боль, шанс выпустить очередной «красивый, но мёртвый» релиз заметно падает.
О подходе сообщает Habr / Карьера со ссылкой на статью Сергея Прощаева, Tech Lead и руководителя направления Java/Kotlin-разработки в FinTech и e-commerce, который также преподаёт в OTUS. Повод предельно прикладной: многие команды по-прежнему запускают фичи, которые выглядят логично внутри компании, но почти не находят применения после релиза. Автор разбирает не «большой customer development» по Стиву Бланку целиком, а его самую прикладную часть для discovery-этапа — интервью, сфокусированные на выявлении проблем пользователя.
В качестве отправной точки Прощаев приводит типичный для продуктовой разработки сюжет. Команда делала платформу для управления лояльностью, клиент попросил добавить виджет с персонализированными скидками, на задачу ушло ещё два спринта, а после запуска почти никто этим виджетом не пользовался. Позже выяснилось, что заказчику вообще-то нужна была куда более прозаичная вещь — кнопка выгрузки отчёта. Мораль здесь без украшений: проблема часто не в качестве кода и не в скорости delivery, а в том, что гипотеза проверялась слишком поздно, когда разработка уже съела время и деньги.
Материал рассчитан на команды от 3 до 50 человек, у которых нет бюджета на дорогие исследования, но есть доступ к клиентам через CRM, чаты или личные контакты. По оценке автора, на первичную проверку гипотезы обычно достаточно одной-двух недель. Это важная оговорка для российского рынка, где у многих B2B- и B2C-продуктов нет отдельного research-штата, а discovery по-прежнему пытаются заменить опросами в духе «нужна ли вам такая функция». Статья как раз спорит с этим соблазном и довольно убедительно объясняет, почему опросы плохо работают на этапе поиска проблемы.
Один из самых показательных примеров в тексте — история о продакте из финтеха, который опросил 500 пользователей, и 82% респондентов заявили, что им нужен тёмный режим. Функцию сделали, но поведенческие метрики не изменились. Причина знакома любому, кто хотя бы раз спрашивал пользователя о будущем: люди неплохо формулируют пожелания, но заметно хуже предсказывают собственные действия. Поэтому problem interviews строятся не вокруг гипотетического «стали бы вы пользоваться функцией X», а вокруг конкретного прошлого опыта: когда в последний раз человек решал нужную задачу, сколько времени потратил, что именно его тормозило, как он выкручивался без продукта.
Дальше автор раскладывает процесс на пять шагов. Первый — сформулировать гипотезу не в расплывчатом виде «хочу понять, нужна ли интеграция», а в формате «если — то» с привязкой к сегменту и измеримому действию. В статье приводится пример: предположение о том, что менеджеры по продажам в малом бизнесе тратят больше двух часов в неделю на ручной перенос данных из email-рассылок в CRM, и потому будут регулярно пользоваться импортом в один клик и с большей вероятностью продлят подписку. Это звучит не так романтично, как «давайте сделаем новую интеграцию», зато сразу видно, что именно проверяется, для кого и какой результат считать успехом.
Второй шаг — рекрутинг респондентов. Здесь Прощаев бьёт по распространённой ошибке: не надо интервьюировать друзей, коллег или случайных «респондентов за деньги» без нормального скрининга. Самыми полезными источниками он называет собственную CRM и базу пользователей, профессиональные сообщества, а также поиск через LinkedIn и HeadHunter с персонализированным запросом. По его опыту, такие сообщения дают примерно 10-30% ответов. При этом автор отдельно советует не ограничиваться активными и довольными клиентами: пользователи, которые отвалились, часто дают более ценную информацию, чем те, кто уже научился жить с вашим продуктом. Минимальный контроль качества выборки тоже вполне земной: собрать 5-8 человек нужного сегмента и проследить, чтобы хотя бы двое не были знакомы интервьюеру лично.
Третий шаг касается скрипта интервью, и здесь статья особенно полезна для начинающих продактов. Автор предлагает буквально распечатывать себе шпаргалку с плохими и хорошими вопросами. Плохие — это всё, что провоцирует респондента фантазировать о будущем, давать socially desirable answers или абстрактно рассуждать о боли. Хорошие — это просьба рассказать о конкретном последнем случае: как решали задачу на прошлой неделе, какой экран открывали первым, где потеряли больше 30 минут на рутине, когда случайно отправили данные не тому человеку. Разница кажется косметической только до первой записи интервью: в одном случае команда получает вежливые мнения, в другом — фактуру, из которой можно собрать реальный сценарий использования или честно признать, что сценария нет.
С практической точки зрения это означает довольно неприятную, но полезную вещь для бизнеса и разработки. Часть идей, которые внутри компании выглядят «очевидными», после серии интервью просто не доживает до бэклога, и это хороший результат, а не провал discovery. В статье прямо противопоставляются два пути: слева месяцы разработки с низким использованием на выходе, справа — 5-7 интервью, затем проверка наличия боли, затем простой прототип за один спринт и релиз с измеримыми метриками. Для IT-директоров и фаундеров здесь сигнал очевидный: дешёвое исследование до старта часто работает лучше, чем дорогая доработка после релиза. Для разработчиков — не менее важный: отказ от ненужной фичи тоже считается продуктовой победой, даже если архитектуру уже очень хотелось «накидать на салфетке».
На российском рынке, где команды нередко живут в режиме сжатых сроков и ограниченного research-бюджета, такой подход вряд ли станет модным ритуалом. Скорее он постепенно превращается в базовую гигиену продуктовой работы: сначала подтвердить, что у пользователя вообще есть проблема, и только потом обсуждать стек, сроки и объём спринта. Вопрос теперь не в том, готовы ли команды делать problem interviews, а в том, сколько из них всё ещё считают, что один опрос на 500 человек может заменить разговор с пятью реальными пользователями.