I hate the title software "engineer" because engineering is a set of practices and processes that software creation doesn't come close to complying with.
The primary problem is the feature backlog. It's always been that, whether it was called the "Requirements" or the "Functional Requirements" or whatever.
Working out what the product of the effort has to do is hard. It involves understanding the actual end users (not the managers of the process/product), the process/product itself, and the context and environment in which it will operate.
The stakeholders are multiple and on multiple levels. There are managers and auditors that need visibility of the ongoing operations, there are users and consumers that need the actual input or output.
I've never met a "Product Owner" that actually understands the product they are building or where and how it is expected to be deployed and operate. They rarely filter out unnecessary or dangerous "features", but just add them into the overall bucket without knowing where to draw the boundaries.
The "solution" is multi-faceted, but it needs to be directed at this area.
Domain Driven Design is one approach, actually engaging with the actual end users is vital.
Sometimes, ignoring a manager's desire (particularly for "dashboards" and "reports") is very important to keeping the feature backlog manageable.
Understanding the context/environment is also vital. Does this product deal with individual's personal information? How does SOC affect it? Is the process required to be auditable? If it is, what evidence is required for the auditors?
None of this is "software" per se or even "programming", or, even worse, "engineering". It's process and product and understanding what is being built.