Возьмём большой продукт, где заказчик сам выступает владельцем продукта. Работа ведется долго, мы итеративно развиваем решение. Большинство идей по улучшению идёт от него, он же приоритизирует бэклог. Мы тоже можем что-то предложить, но без глубокой проработки. Если идея кажется стоящей, выходим на аналитику за счёт клиента и дальше по стандартному процессу. Но чаще наши предложения уезжают в бэклог: у клиента свой текущий приоритет, и распыляться он не хочет. Мы иногда напоминаем, чтобы он про них не забыл.
Это в основном про крупные фичи. С мелкими правками проще: часть делаем сразу, когда понятно, что дешевле потратить время сейчас, чем переделывать потом. Но и это согласуем. Убедили клиента, берём; не убедили, откладываем. Клиент платит деньги, у него сроки ещё с этапа планирования, и чтобы что-то поменять, нужно объяснить, почему это стоит времени.
А есть другой случай, когда у нас сжатый по срокам проект. Например, MVP какого-то продукта, где мы еще не знаем получит он дальнейшее развитие или нет. Тут чаще уже мы приходим и просим отложить фичу, чтобы успеть к запуску. Аргумент простой: для MVP это некритично, без этого релиз спокойно выйдет. Заказчик соглашается — фича в бэклог. Не соглашается — стараемся упростить задачу до минимального варианта исполнения, согласовать его и взять в работу. Всё остальное опять же в бэклог.
Как видите, в обоих случаях всё держится на диалоге. Либо ты просишь клиента что-то добавить, либо что-то убрать. Что именно и когда, зависит от проекта, сроков, этапа и самого клиента. Никакого тайного правила, что отправлять в бэклог, а что в топку, не существует. Есть только разговор и аргументы. Ну, и умение быть в живом контексте работы и разрабатываемого решения.