Почти каждая продуктовая команда согласна, что исследовать пользователей важно. И почти каждая пропускает discovery, когда горят сроки. Разберёмся, почему так происходит и что с этим делать.
В чём разница
Delivery — это выпуск: разработка, тестирование, релиз. Discovery — это понимание, что стоит выпускать и зачем. Подробнее — в статье «Что такое product discovery».
Почему команды пропускают discovery
- Delivery видно, discovery — нет. Релиз можно показать, а «мы поговорили с людьми и не стали делать фичу» звучит как потраченное время.
- Роадмап уже утверждён, и исследование воспринимается как угроза плану.
- Кажется, что команда и так знает пользователя.
- Исследование представляют как долгий проект, а не как несколько разговоров в неделю.
Во что это обходится
Самая дорогая работа — идеально сделанная фича, которой никто не пользуется. Она съедает спринты, усложняет продукт и требует поддержки. Discovery стоит дешевле всего именно тогда, когда кажется, что на него нет времени.
Как совмещать
- Вести discovery и delivery параллельно: пока одна часть команды строит проверенное, исследуется следующее.
- Делать исследования маленькими: несколько интервью, прототип, быстрый тест.
- Вовлекать разработчиков и дизайнеров в разговоры с пользователями, а не пересказывать им выводы.
- Показывать ценность в понятных команде терминах: какие фичи не пришлось делать и сколько времени это сэкономило.
Итог
Discovery — не отдельная фаза перед «настоящей работой», а часть работы. Команды, которые это понимают, выпускают не больше, а точнее.
Хотите выстроить discovery в своём продукте или команде? Первая встреча-знакомство бесплатная — подробнее на странице консультаций или пишите в Telegram: @jd_tools.
Больше заметок про продуктовое мышление — в канале jd_tools_life.