a feature request from a user is not a specification. it's a hypothesis. "i believe that if this feature existed, my problem would be solved." the user is often right about the problem and wrong about the solution.
when someone says "i need an export-to-CSV button," the hypothesis might be "i need to get this data into a spreadsheet for analysis." the real solution might be better in-app analytics, or an API, or a different default view. the CSV button solves the stated need. understanding the hypothesis solves the actual need.
treating requests as data
if you track feature requests as a list of things to build, you'll build a Frankenstein product shaped by the loudest users. if you track them as hypotheses about unmet needs, you'll find patterns that point toward coherent product improvements.
ten users requesting ten different features might all be expressing the same underlying frustration. the ten features are ten proposed solutions. the frustration is the actual problem worth solving.
the danger of literalism
the worst product teams i've seen are the ones that build feature requests literally. a customer says "add a dropdown." they add a dropdown. the customer is satisfied for a week, then comes back with another request, because the dropdown was a patch on a deeper design problem.
the best product teams translate. they hear the request, extract the hypothesis, validate it against data and other users, and then solve the underlying problem. it might look nothing like the original request.
status: fairly stable note. occasionally add examples from work but the core idea hasn't changed.