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

Причин было несколько. Одна из них в том, что даже при хорошо описанных требованиях в процессе разработки возникает куча вопросов. Например:
- Как отрабатывать сообщения об ошибках? Допустим, какая-то форма может не работать по каким-то двум причинам. Вы можете вывести в тексте ошибки универсальный текст "не работает из-за причины x или y" или разработать штуку, коротая определяет, какая именно ошибка случилась, и выводит специфический текст (это доп. время разработки)
- Или если есть маловероятная ошибка, обрабатывать ли её? Например, "если новый пользователь является полным однофамильцем существующего, система не может его зарегистрировать". Мы хотим ли мы что-то с этим делать, или забиваем? (если хотим, то это доп. время разработки)
- А какую нужно закладывать гибкость на следующие итерации? Например, вы решили добавить пуш уведомления. А вы захотите потом историю пуш уведомлений, надо их хранить? А вдруг захотите потом кроме пушей сделать уведомления в вацап и смс, нужен какой-то единый центр нотификаций, и возможность добавлять каналы? (+время разработки)
- А вот вы хотите выводить список каких-нибудь сущностей. Надо сделать паджинацию списка на всякий случай? Вдруг сущностей будет больше ста? (+время разработки)

Часть таких вопросов можно продумать заранее, а часть нет - какие-то ограничения не видны до начала разработки, про какие-то технические возможности вы не знаете. Вопросы возникают по ходу.
Если их не отслеживать, можете оказаться в ситуации, когда в продукте закладывается ненужная гибкость, прорабатываются нерелевантные сценарии, и сроки съезжают. Так было у меня.

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

Я сделал из этой истории несколько выводов (мб чуть тривиальных, но прожитых с опытом):
1. Что погружение продуктовой команды в сценарии и потребности пользователей позволяет экономить время в процессе разработки, отсекая неважные направления (раньше думал только с точки зрения ценности, а про сроки - нет).
2. Что погружение это нужно не только на старте (вот юзкейсы, вот сценарии, вот jtbd, поехали) а постоянно в процессе работы, т.к. всё время возникает много маленьких вопросов, о которых на берегу никто не подумал.
3. Что погружение должно быть push, а не pull, т.е. разработчик/дизайнер не всегда приходит с вопросом "не знаю, делать ли тут паджинацию, давайте в аналитике посмотрим, сколько тут может быть сущностей". Надо самому отлавливать такие точки принятия решений и закрывать их данным. Ну и учить команду замечать их, конечно.
4. Что из-за вот этих микровопросов и микроконтекстов очень важен быстрый доступ к знаниям о пользователе. В любом формате: продуктовая аналитика, continuous research, база инсайтов, user board, накопленная за счёт наблюдений экспертиза - нужен способ получить быстрый и относительно верный ответ на точечный вопрос.
5. Я сформулировал для себя идею сценарной/UX устойчивости напишу о ней чуть позже.