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 developed.
As an example, hard tech products in data infrastructure often have this property. Famously, there are no incremental product outputs to show customers (or investors) as a matter of fundamental engineering; the product has to be almost fully baked before it can demonstrate anything of value at all. Customers have a difficult time understanding the implications of fundamentally new capabilities until they have time to play with them; they provide no useful feedback until the product has already reached a stage where this is possible (read: almost fully baked). And of course, there is no "iterate quickly" because the product value follows from architecture; if the architecture isn't correct the first time then iterating on the product means starting over from scratch. Consequently, the only people that can successfully build these products are people with serious expertise in the product and its use case. Even if you try to do customer development, there is nothing for the customer to engage with until you are well past the point where their feedback can materially change the product.
In these cases, no amounts of customer development will make up for a lack of deep domain and market expertise. The lean startup/MVP/customer development etc literature tacitly assumes that every product is an "app" of some type. If you work on software products that are not "apps" then you may find some of the advice to be misguided or useless.
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” and Vagrant was already a thing. But when talking to customers, they would have described ample problems with the existing approach - if you carefully listened, you could surmise that something like basic Linux containers would help, and you could provide a basic prototype of that to start. When they complain it lacks features, that’s okay, if and only if they still want to use it - THAT is the sign of PMF.
Want to build a new data warehouse? That’s hard, I agree - but the important part isn’t that it’s hard but why it’s better which is going to come from customer development. If listening to customers isn’t driving your product roadmap, you are literally guessing at what they need, and unless you’re Steve Jobs and your next product is the iPhone, you’re in for a rough time.
(And even the iPhone had plenty of customer dev; they interviewed thousands of people about their cell phones and surmised the solution wasn’t simply to build a better keyboard for a Palm Pilot, but to build a brand new device entirely, because people loved their phones but they had limited use. The Newton, on the other hand, had no market because people weren’t ready for it and it was built in a lab with no customers to talk to.)
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.
I think you’re missing mine. You don’t listen to the users’ feature requests; you listen to their problems and then devise solutions that solve a significant cross section of user issues.
As an example, hard tech products in data infrastructure often have this property. Famously, there are no incremental product outputs to show customers (or investors) as a matter of fundamental engineering; the product has to be almost fully baked before it can demonstrate anything of value at all. Customers have a difficult time understanding the implications of fundamentally new capabilities until they have time to play with them; they provide no useful feedback until the product has already reached a stage where this is possible (read: almost fully baked). And of course, there is no "iterate quickly" because the product value follows from architecture; if the architecture isn't correct the first time then iterating on the product means starting over from scratch. Consequently, the only people that can successfully build these products are people with serious expertise in the product and its use case. Even if you try to do customer development, there is nothing for the customer to engage with until you are well past the point where their feedback can materially change the product.
In these cases, no amounts of customer development will make up for a lack of deep domain and market expertise. The lean startup/MVP/customer development etc literature tacitly assumes that every product is an "app" of some type. If you work on software products that are not "apps" then you may find some of the advice to be misguided or useless.