One easy way to limit the size of the backlog is to let the community itself vote on which bugs and features you should be working on, then add a little editorial selection and take the top (n) to work on. That's what we do at Stack Exchange, anyway:
I find that the community appreciates being involved in these decisions, and often (but not always†) has good ideas of what you should be prioritizing and what issues are true pain points.
True, although software can never be 100% user/customer/community driven. Something Henry Ford something something “faster horses.” Or within my lifetime, if we had take a survey in 1983, how many personal computer users would have voted for “mouse and bitmapped screen” as their top priority?
For a completely community-driven site like SO, that might work.
For anything else, you will never be a leader in the market with that attitude. The reason why it seems to work early on on a company is that you are resting on the laurels of the original vision of the software. That will get washed away in a sea of tweaks to existing features by the community.
Customer feedback is an important consideration, but should not be the only. Believe it or not, product management is a valuable skill.
The problem here is that the propensity to add bugs and features is disproportionate across the user base. Some people get a kick out of adding feature requests and being 'noisy'. Some people have an important or good idea but will never take the trouble to post it.
The problem, then, is being able to sort between this and not only (a) keep the active community members on-side and (b) find a way to flesh out those hidden requirements from less-engaged people.
Of course the other issue is when community requests are not necessarily profitable for the company that provides them.
http://meta.stackoverflow.com/?tab=bugs http://meta.stackoverflow.com/?tab=requests
I find that the community appreciates being involved in these decisions, and often (but not always†) has good ideas of what you should be prioritizing and what issues are true pain points.
† http://www.codinghorror.com/blog/2012/02/listen-to-your-comm...