Потом когда с командой обсуждается что, как и сколько будет стоить

Как быстрее всего проверить что в историю нужно идти (mvp/или просто хак на фронте, бэке, ручками)

Это до прода быстро сделали, собрали метрики, фидбек клиентов, дальше смотрим нужно ли полноценный функционал делать и в какую сторону

Или я не правильно понял вас?

Однозначных критериев плохой фичи не бывает. Не попробуешь, не узнаешь. Поэтому есть скрамы аб тестирование и та

Когда-то говорили, что однозначных критериев плохого кода ее существует. Но потом появились )
Почему для постановок не так.

Но вообще есть куча критериев плохих постановок, вполне формальных.
Не учёт части имеющихся сценариев, увеличение числа кликов на критических сценариях, не учёт разных расширений и т.п.

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

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

Но это тоже долго

Про это есть много практик, выше озвучили. Я так понимаю вам постановки приходят вида "сделать это, вот так вот, вот тут вот"?

Эээ, я вообще не про это. И, кстати, практик так и не озвучили, Scrum не покрывает подготовку постановок.

Просто я хорошо понимаю, что 'продукт приходит с проблемой юзеров' - это уже результат анализа (возможно плохой и требующий контроля). И что качество продукта начинается ещё до 'продукт приходит'.
И хочется посмотреть на отрефлексированный процесс обеспечения качества продукта. Без слов 'скрам', так как это все по другие скоупы и других акторов.

Я пытаюсь понять где мы расходимся в понимании. Пока не очень получается. Что в твоем понимании постановка? В каком виде?

А не важно даже. Документ, пришедший в разработку. Это может быть user story, может быть идея продакта, а может быть детализированный набор изменений на 100 листах.
Меня интересует, а что происходит до появления постановки, так как на качество продукта это отказывает большее влияние, нежели качество кода.

И как можно увеличить качество постановок (и что такое вообще 'качество постановки'), как ускорить отсев плохих постановок (на всех этапах).

Понятно, что в разных процессах это будут разные практики, от 'согласования ТЗ с заказчиком' (почти не работает) до 'обсуждения постановки с разработкой' (работает только в процессе разработки инструментов разработки, да и то плохо).

AB тестирование, например,  - это техническая практика, а не процессная

NB#1. Формально, продакт не может быть внутри SCRUM, так как он формирует и приоретизирует бэклог.
UX может быть внутри, но это уже в рамках какой-то своей команды (внутри команды разработки он быть не может, так как его работа - это вход на разработку), что обычно только замедляет тестирование гипотез (да и вообще если скрам, значит скорость проверки гипотез не является приоритетом, просто по факту выбора методологии).

NB#2. Вообще-то, проверять надо не "что продакт прав", а "что продакт неправ". Иначе много шансов на логическую ошибку при постановке эксперемента. Но это значит, что у вас какая-то специфическая методология, к scrum/xp отношения не имеющая. Дальше надо смотреть, как она реально у вас работает, только фразы "продакт приходит с проблемой юзеров" недостаточно.