How to Talk to Users to Validate Product Feature Requests
Why user conversations matter
When building products, you’ll constantly hear feature requests from customers, colleagues, or executives.
But not every request deserves to be built and asking the wrong questions can lead you astray.
The best way to separate signal from noise is to talk directly with users. Done right, this validates whether a request maps to a real problem, or if it’s just a “nice to have.”
Common mistakes to avoid
- Leading questions: Asking “Would you use this feature?” puts users on the spot and biases them to say “yes.”
- Over-indexing on one voice: A single loud customer doesn’t equal the entire market.
- Solution-first conversations: Jumping straight to “Would you like Feature X?” instead of understanding the underlying problem.
A better approach
-
Focus on problems, not solutions
- Ask about the last time they faced the problem.
- Get them to walk through the steps, frustrations, and workarounds.
-
Quantify frequency and impact
- How often does this problem occur?
- What’s the cost (time, money, frustration) of not solving it?
-
Look for patterns across users
- If multiple interviews surface the same theme, you’re onto something worth exploring.
Tips for productive conversations
- Record or take detailed notes so insights aren’t lost.
- Keep the conversation natural it’s about listening, not interrogating.
- Summarize what you heard at the end and confirm accuracy with the user.
Five questions to ask during your user interview
“What’s the hardest part about doing the thing that you’re trying to solve?”
The first question helps you validate whether the problem that you’re working on is actually one that real users feel is a pain point. You are searching for problems that your users face on a regular basis, or problems that are painful enough to warrant solving.
“Tell me about the last time that you encountered this problem.”
The second question is about trying to get to specifics rather than hypotheticals. The goal of asking this question is to extract more context around the problem and better understand the different circumstances the user has encountered that problem.
“Why was this hard?”
The third question is may seem redundant, but it’s key because we narrowing down to a specific circumstance when the user felt the problem. Their answers can reveal what is really causing the problem to occur, and you’ll hear many different answers from different people.
“What, if anything, have you done to try to solve this problem?”
If users haven’t attempted very much to find potential solutions to their problem, it could be a sign that that the problem isn’t painful enough. If the problem isn’t painful enough, then it may not be the best use of your resources to find product market fit.
This question is one way of validating the problem and how severe it is. It tries to get to the root of the issue, is this problem painful enough that this user is already trying to solve it? What tools did they experiment with? Are other users saying the same thing?
“What don’t you love about the solutions that you’ve already tried?”
The fifth question can be the very beginning of your potential new feature set. Here you can start to understand what specific features you’ll want to consider building to better your solution and solve the users problem.
Takeaway: Don’t take feature requests at face value. Instead, use conversations to uncover the why behind them. That’s how you validate what’s worth building.
