On one hand, I always knew it is really important to ask customers about their pain points and how my product can solve it.
But I also get carried away by making a lot of assumptions on the behalf of my customers and sometimes it has paid off.
So in short, the process of listening to customers is a bit vague in my mind. I was wondering if anybody has a system in their head about how to approach this?
I think this is a yes. This gives you some insight into what is desired.
Should you listen to that feedback?
I think this depends. You may get some customers that have unreasonable expectations. I have recieved some enhancemnet requests that make sense, so I implemented them. I've also recieved requests for functions that were beyond the intended scope of the product and would be better met with other products. In those cases, I would be honest and tell them those thoughts. Granted this is FOSS.
> An innovator should have understanding of one’s customers and their problems via empirical, observational, anecdotal methods or even intuition. They should also feel free to ignore customers’ inputs. Because by now it should be clear that Ford’s adherence to his vision of the mass-market car and how to materialize that vision was instrumental in both his early success in growing Ford Motor Company as well as his later failure to respond in a timely and effective manner to rapid innovation in the marketplace.
The real lesson learned was not that that Ford’s failure was one of not listening to his customers, but of his refusal to continuously test his vision against reality, which led to the Ford Motor Company’s failure of continuous innovation, resulting in a catastrophic loss of market share from which it never recovered.
You should not take their input at face value though (try to figure out what problem they are attempting to solve since they'll usually propose tooling that solves their problem), and focus on things affecting your customers most heavily (however you define that: highest paying customers, largest numbers, most influential to get word-of-mouth recs...).
But sometimes you should take their input at face value too ;)
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