Listening to what customers say does not mean you implement what they say. Extract the problems they're trying to solve, the "job to be done".

What they say and the underlying problem are different things. Way too often, people will suggest solutions (developers will suggest implementations), not the actual problem they're facing.

For example, here's something I posted on Reddit for our machine learning platform[0]. One commenter said:

>Sounds like a great tool. But for me to seriously consider it would have to be OSS.

If you take it at face value, you'll think "Oh, people really want this to be open source". Digging deeper, however, by driving the commenter to talk about the fact they use other tools and services that are not open source, it becomes clear that the commenter wants control over data, peace of mind, and reduce technical risk:

>Adopting a tool that might disappear in the future is too big a risk for our team (and I believe many others) to take. OSS provides a guarantee that even if the company behind the tool disappears, it will still be accessible to us.

It's not that they really wanted OSS. The "OSS" was an implementation or a solution to their underlying problem: what if your company disappears and all the work I've done on your SaaS is gone now, or you leave me scrambling to exfiltrate, and even then, I might be stuck.

This aligned mroe with items we had on our roadmap to address that problem because we felt strongly about this too.

There's a useful concept called the "XY Problem"[1]. I remember someone asking me how to solder a thick wire to a tinier pad. I investigate what they're really trying to do further, and it turns out they had a burnt out fuse and they wanted to put a thicker wire and solder it to avoid it melting again. That's the whole point of a fuse. That's why the fuse gives away its life, so other appliances may live in case of a higher current. Replacing with a thicker wire resolves the apparent problem (fuse burning), but exposes the downstream appliances to a higher risk.

The "solution"/"implementation" to their "problem" is poor, because their problem definition is lacking. They came up with it based on the knowledge they had. Properly identifying the problem helps avoid disasters downstream.

Clearly defining a problem is extremely important. We're a boutique consultancy specialized in machine learning, and a good chunk of what we do upstream is peeling away layers of solutionism, assumptions, implementations from what our clients say when they talk about what they want or what their "problems" are.

Some ways to peel out this way is to ask them what they're doing right now to solve that problem, how frequently they have to do that, the last time they had to do that, or if they're using other tools to do that.

This is similar to when we're in a meeting and talking about our product and someone asks us if we have a feature that does X and I ask them to talk more about the problems they've had trying to do X. More often than not, they'll say they don't really need X. They were just asking. Or if they that "Prouct Y has the feature X". "What has been your experience with product Y?" ... "We're not using Product Y". Why not, it has feature X... This makes you realize that if it were that important, the conversation would be different.

If you don't do that, your "sales person" coming out of the team will say "We definitely need to add X to the product".

"Desirability", "feasibility", "viability".

The links[2][3][4] are replies that address this directly or indirectly.

- [0]: https://www.reddit.com/r/MachineLearning/comments/kolobf/p_c...

- [1]: https://en.wikipedia.org/wiki/XY_problem

- [2]: https://news.ycombinator.com/item?id=24503365

- [3]: https://news.ycombinator.com/item?id=24972611

- [4]: https://news.ycombinator.com/item?id=22827841