[tensor]

As an aside, I think companies should take "problem requests" not feature requests. A feature requests implies a solution, and letting your customers be your product designer leads to generally messy and poorly designed products.

So rather than submitting "I'd like the app to do Y", it would be amazing if customers instead submitted "I'm trying to solve problem X and having trouble." Maybe Y is a good solution for X, but maybe Z is too and Z wasn't asked for even though it might be what you need.

[sitkack]

Related, "How to Ask a Question" [0]

Features always need to be put in the context of the problem(s) they are solving. If a product team is implementing customer feature requests in an open-loop they are doing it wrong. The product designer's job is to synthesize multiple requests, find the root causes of the problems and come up with a compact composable design that knocks out multiple FRs at one time. Simply implementing FRs gets one into a wall of buttons.

[0] http://www.catb.org/esr/faqs/smart-questions.html

[erader]

This is exactly how our team likes to operate :)

Taking only 'requests' leads to a whole range of potential problems: - Feature bloat with random one-off buttons and gizmos - Product teams getting in the habit of ignoring requests if they know that most don't quite fit - Really complex products (both for customers and internal teams to understand/troubleshoot) - Unclear roadmaps - Wasted time. For example, I had a request to build a notification-silencer for specific executives at a company. I recommended that the executive set up email filters instead

[mikeleeorg]

Yes!

I once implemented a GetSatisfaction/UserVoice-esque feedback widget. The most useful feedback we received came in when we worded the widget with text like, "What problem would you like us to solve for you?"

It got slightly less responses than a generic, "Feedback form" label, but the quality of responses was much higher.