Earlier quoted context omitted.
I've worked on products where customer development was essential and also on products where it was largely useless for product development. You are assuming things about the product development process and customer interactions that are not always true. That doesn't imply that you don't talk to customers or don't understand their problems, just that this can be disconnected, often necessarily, from the product being…
See, I’m not convinced that’s true. Having built hard tech products before, there are plenty of places for iteration. The catch is that you iterate the plan and architecture, before you write any significant code. In this case, it’s even more important to listen carefully to the customer and pay attention to the underlying problem. For example, it may not have made sense to build Docker because “everyone uses VMs” an…
Customers do not have a mental model of the very complex theory that underpins the design of new kinds of data warehouses; they routinely ask for features and capabilities that are mutually exclusive or violate the laws of physics or computer science theorems if you ask them. There have been many attempts to "customer develop" a new kind of data warehouse, and the result is invariably naive architecture with too many deficiencies to be successful (basically the proverbial faster horse instead of a car).
In practice, the person building the product is usually a deep expert on the use cases for the product they are building in cases like new kinds of data warehouses. Indeed, there is the opposite problem that it is too customer and use case driven. Most such products fail due to insufficient expertise in the technical execution because the product was built by an expert user instead of an expert in the theory of building those types of systems, without a good understanding of the many subtle tradeoffs. If someone need to do customer development to understand why a new kind of data warehouse is better then they lack the deep technical expertise required execute ipso facto, since it trivially follows from low-level architecture.