This may be true if you have no aspirations for your software beyond what your customer can imagine in the present. Almost seems like a methodology that has internalized learned helplessness.
If you think the process I'm describing here is, "Ask customer what they want, do exactly what they say." then I'm not being very clear.
"Don't assume that your team should build what it's told to build. Instead assume the opposite: nobody really knows what you should build, not even the people asking for it. Your team's job is to take those ideas, test them, and learn what you should really build." [0]
That's your team's job. Not to make guesses by assuming you know what's best, not to do what they're told by customers, but to run tests and use results to inform next steps. That's the entire purpose of a development team, and you simply cannot do this without a quick iterative cycle.
Actually, "my" team's job is 1/2 asking the customer, and 1/2 not asking the customer so we can invent stuff they haven't thought of and ideally can't/won't think of.
I think the reason people aren't fully agreeing with you is that there's a lot of important stuff where a quick iterative cycle in front of a customer eliminates the possibility of high-value outcomes.
That's only true if you're interacting with your customer in some weird, subservient way that has nothing to do with anything I've said at all.
The point you're trying to make isn't the novel insight I think you're trying to present it as. Of course you don't just build what your customer asks for blindly, of course you design with the future in mind, none of that is precluded whatsoever by iterating quickly to provide value and test what your customer needs.
The point I'm trying to make is a corollary to “A committee is a life form with six or more legs and no brain". It's an acknowledgement that sometimes the customer is bikeshedding from start to finish. It's the recognition that rapid iteration can mean a short planning horizon that traps an architecture in a local maximum that won't deliver on business aspirations.
In a past life I had developed 3 generations of tooling to support a certain complex and information-dense task that was essential to the business. Generational change was not incremental and required months/years exploring the problem domain and prototyping and backtracking and intentionally not consulting anyone. If I came out of stealth too early I'd be directed back to a gen 1 approach that was functionally and architecturally exhausted and could not meet the business needs at a reasonable cost. By the time I was done I understood the problem domain better than the business did. (I will stipulate that most of the time this is a bad approach--but sometimes it's absolutely necessary.)
My (aspirational) purpose at work is to surprise my customer with valuable and insightful solutions that they could not have arrived at incrementally, or with their methods, or with their team. Surely you can see how this is in direct conflict with rapid iteration in collaboration with them?
Except you're not inventing things, you're discovering things. That's a big difference. The best way to discover if something works, is to put it into the hands of customers as fast as possible while minimizing your expense at doing so.
"Don't assume that your team should build what it's told to build. Instead assume the opposite: nobody really knows what you should build, not even the people asking for it. Your team's job is to take those ideas, test them, and learn what you should really build." [0]
That's your team's job. Not to make guesses by assuming you know what's best, not to do what they're told by customers, but to run tests and use results to inform next steps. That's the entire purpose of a development team, and you simply cannot do this without a quick iterative cycle.
[0] The Art of Agile Development, pp. 453