Customers are great at describing problems. Not always solutions.
A customer asks for an export button.
Sounds simple enough. You add it to the backlog, estimate the work, and move on.
But what if they don't actually need an export button?
Maybe they're copying data into another tool every Friday. Maybe their manager needs a report. Or maybe they just don't trust that the data will still be there next week.
Same request, three completely different problems.
This is something I find tricky about customer feedback, especially in B2B products. The more specific a feature request sounds, the easier it is to skip asking why.
And sometimes the customer has already spent so much time working around the problem that their suggested solution feels like the only possible one.
I don't think we should ignore what customers ask for. I just think the request itself is often the beginning of the conversation, not the answer.
How do you usually figure out what's behind a feature request before it ends up on the roadmap?
Replies
My clearest case of this was not a request at all but behaviour. A free trial in my app unlocked downloading the free song. Of the first 15 trials to reach a decision, 8 were cancelled within hours and 1 converted. The trial was being used as a download key: what people wanted was the file, not the plan. Asking why behind a request is great, but for me the honest answer often came from looking at what people did right after getting what they asked for.