If you’re building a real product there’s frequently not even an existing customer and certainly none to “give you requirements”. You need to understand problems to solve and turn those into requirements for a product and if you can do that then you’re not working at a customer giving requirements to a vendor.
One subtly for me is that what you said is 100% true of the parts of the organization which interact with customers, or even design partners who want to become customers. But since not every member of engineering is in that role, the requirements which come back from those meetings still need to be "MVP accurate" and (IMHO) need to specify just as much what it *won't* do as what it needs to do
For example, "customer wants to query for names" is a shitty requirement. Of course they do, we all want search engines for everything, but that's not how software works. Do they want it case sensitive, case insensitive, the ability to indicate by using special search syntax (like "quoted"), do they want "starts with" or "contains" searches, wildcard characters?
Getting to MVP means not building the wrong or extraneous things just as much as building the right things, and only a handful of people bear responsibility for distinguishing between those sets
I think the problem begins before the 'leader.' The product itself dictates all the downstream consequences, including whether 'requirements' are a problem.
Assuming no fatal management dysfunction, when you're working on a product that has substantial value, enough that the customer is eager to pay for what you're capable of delivering, requirements are straightforward. When you're working on things of low value and the customer won't pay unless they get an ever more improbable gymnastics routine and every tier of stake holder is lying to the other then you starting hearing about 'requirements' problems. The 'requirements' problem severity is a function of where you are on on the continuum between these two products.