It's almost cliche that entrepreneurs, designers, and engineers should speak with their customers.
And there's truth to this - if you don't speak to your customers, you're far more likely to create something they don't want.
But you can't just ask them what they want. There's a quote attributed to Henry Ford: "If I had asked people what they wanted, they would have said faster horses."
And while it seems Ford didn't actually say this, there's a key truth hidden in this statement:
If you ask people what they want, they'll give you half-baked solutions.
No matter your role or who you're talking to, whether it be a customer or a stakeholder, your job when someone brings you a half-baked solution is to ask questions until you get to the underlying problem.
Why people give half-baked solutions
One of the universal traits of human beings is that we think about the world in relation to where we are.
So when we're feeling a challenge, we think about what we already have and try to figure out what adjustment we could make to improve our situation.
What we don't do is sit back and assess the full range of possibilities, and we rarely are able to consider the trade-offs inherent in our perceived adjustment. We think of a possible solution and immediately start trying to validate "that it would work".
We're also generally bad at creating solutions. Our first idea of the right solution is almost always wrong, or at least suboptimal. This is not unique to "customers" or "stakeholders", it impacts all of us as humans.
To get to better solutions, define the problem
If we invert our process and instead work on digging down into what underlying problem we're attempting to solve, we can short-circuit this process.
Instead of jumping to a solution, we work on carefully defining the problem. What is it that we're trying to solve? What would be the characteristics of a good solution? What would be deal-breakers?
Once we've well defined the problem, we can explore the solution space. We can come at the problem from very different angles. And sometimes we can even simply sidestep the problem by changing something "upstream" that prevents the problem from ever arising.
How to get to problems
The key question is how to get to these problems. When a customer or stakeholder comes to you and says "I wish your product did X", What questions can you ask to uncover the underlying problem?
Here's the approach I use:
First, validate them, so they feel like you value their contribution: "Thanks for the suggestion! That's a super interesting idea..."
Ask for more details in a non-threatening way: "Can you help me understand exactly what you're trying to solve? What is the situation where you'd use this?"
As you start to understand the situation, explore additional options to flesh out the problem: "Ok, so you would like to import data from a CSV. Is that something where you're pulling it from a spreadsheet? Would you like to be able to import from a spreadsheet directly? Or is there another service you're trying to get data in from?"
When in doubt, ask them to show you: "Can you show me exactly where you'd want to use this and how?"
Summarize your understanding of the problem: "Ok, so to make sure I understand - you'd really like to be able to keep this data in sync with the other applications you use. The way you suggested that would work for you is if we created a CSV import functionality, but if there was another way to do this that was easier would you be okay with that?"
The key pieces are: You want to avoid shutting them down by rejecting their solution (which almost certainly is not ideal either in terms of details or your product vision), while digging deeper to understand the problem and what are the characteristics that would make another solution acceptable.
