[rtikulit]

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.

[TameAntelope]

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.

[rtikulit]

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?

[tomnipotent]

> we can invent stuff they haven't thought of

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.

[rtikulit]

Are you asserting there's no scope for invention in software development?

[tomnipotent]

Only that an invention isn't something you can just put on your calendar.