3 ms·

> * Taking solutions from customers as opposed to problems to identify jobs-to-be-done and reasons for non consumption isn't something someone who knows how to

> * Taking solutions from customers as opposed to problems to identify jobs-to-be-done and reasons for non consumption isn't something someone who knows how to build products does.* What’s amazing to me is how this concept is either a “you get it or you don’t” thing. Sure, it takes a little practice to learn how to turn feature requests into the underlying business problem, but, like, I work with so many people who still can’t even grasp this basic concept after many, many years.

Jugurtha 5y ago
This is dangerous as well, especially in enterprise deals where the prospects say they like the product but it lacks one feature, and someone on the team goes "Sure, we can add that" with the delusion that they'll close the deal if they just add this one feature. It rarely, if ever, is the case. If the "feature" is not about some specific security or compliance concerns but an actual feature, questions need to be asked during that meeting. One common pattern is "Your product does not have X? Product Y has that feature", and one common pitfall for people who don't "get it", as you said, is "We should definitely add the feature X that Product Y has". One better approach is to ask "How long have you been using Product Y and how is it working out for you?". The answer is invariably "We don't use Product Y". Of course they're not; we probably wouldn't be meeting in the first place if they were. Sometimes people tell me about products of my "competitors", or people from these companies make jabs or passive-aggressive snide remarks about me or the product: I'm building an MLOps platform; my competitors are people's laptops. That pursuit of listening to prospects' features and solutions, or looking at what others are doing and following it is not a good way. Asking people what they are trying to do or accomplish and extracting problems is effective. What's the current state, what's the desired state, how they're trying to bridge the gap between the two, why they're failing to do so. I wrote a bit about this here with the following example: a friend of mine asked me how to solder a thick wire to a thin metal plate. I asked him what he was trying to do. It turns out he wanted to solder a thick wire to a fuse because the fuse couldn't handle a stronger current and melted. I told him the fuse did its job precisely upstream, and gave its life so more important and expensive appliances downstream could live. This is one example of XY Problem: https://en.wikipedia.org/wiki/XY_problem https://en.wikipedia.org/wiki/XY_problem
- nyanpasu64 5y ago
  Why would a company request a feature that wouldn't cause them to use a product?

Jugurtha 5y ago

This is dangerous as well, especially in enterprise deals where the prospects say they like the product but it lacks one feature, and someone on the team goes "Sure, we can add that" with the delusion that they'll close the deal if they just add this one feature. It rarely, if ever, is the case. If the "feature" is not about some specific security or compliance concerns but an actual feature, questions need to be asked during that meeting. One common pattern is "Your product does not have X? Product Y has that feature", and one common pitfall for people who don't "get it", as you said, is "We should definitely add the feature X that Product Y has". One better approach is to ask "How long have you been using Product Y and how is it working out for you?". The answer is invariably "We don't use Product Y". Of course they're not; we probably wouldn't be meeting in the first place if they were. Sometimes people tell me about products of my "competitors", or people from these companies make jabs or passive-aggressive snide remarks about me or the product: I'm building an MLOps platform; my competitors are people's laptops. That pursuit of listening to prospects' features and solutions, or looking at what others are doing and following it is not a good way. Asking people what they are trying to do or accomplish and extracting problems is effective. What's the current state, what's the desired state, how they're trying to bridge the gap between the two, why they're failing to do so. I wrote a bit about this here with the following example: a friend of mine asked me how to solder a thick wire to a thin metal plate. I asked him what he was trying to do. It turns out he wanted to solder a thick wire to a fuse because the fuse couldn't handle a stronger current and melted. I told him the fuse did its job precisely upstream, and gave its life so more important and expensive appliances downstream could live. This is one example of XY Problem: https://en.wikipedia.org/wiki/XY_problem https://en.wikipedia.org/wiki/XY_problem

nyanpasu64 5y ago
Why would a company request a feature that wouldn't cause them to use a product?