3 ms·
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 an
by borski 5y ago
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.)
- jandrewrogers 5y agoYou are inadvertently reinforcing my point. 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.
- borski 5y agoI 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.