You are not your user-base

Jeff Atwood has a writeup about listening to your community.  Its a great article, and worth perusing in its entirety, and broadly boils down to the following

• Most feedback is crap : However, 10% is awesome.  Filter it out, and use it!
• Stick to your mission : If you're building a car, build one.  If its a truck, build that.  But, for heavens sake, don't build a hybrid (Subaru Brat! W00t!)
• Be honest : Tell people what you will - and won't - do.  Feedback is critical, and immensely appreciated even if it is negative
• Listen well : Determine the underlying need in the requests.  Its not what they're asking for thats important, its what they actually need.
• Be there for the community : The very act of listening publicly, and interacting creates a virtuous feedback loop that immeasurably improves goodwill.

That said, I'd add one additional item : You are not your user-base

Seriously, this is one of the easiest traps to fall into - one where you end up designing the product for your own needs, because after all, you know what the user's want, right?

You came up with this earth-shattering idea, its your vision, your baby, so of course you know exactly how it should work, right? 
Well, yes, you do.  Till you actually start building it and everybody, *everybody* starts "contributing". It is the most basic trap of all, and one that we all fall into with astonishing regularity

Aeons ago, we were building out a Queueing feature for our PBX platform. The original requirements were really simple

Incoming calls get queued. Whenever users were free, they could hit the Send button, and the next call in the queue got sent to them.  

This, unsurprisingly enough completely, absolutely, and utterly satisfied a *huge* chunk of our client base.

And then we got involved - the "we" being our sales department, support group, management - basically everyone - and it turned out that "Queueing" would be perfect for internal use by "we", if we just added a few features.

1. Automatic call distribution : Because, our customer support reps sometimes slack off and don't hit the Send button.  And it should be easy, right?
2. Wait time whispered on the call : Because sometimes our hold times get long, people get tired of waiting, and it should be easy to calculate some kind of adjusted mean wait time right?
3. Rollover between queues : Because if our reps get slammed, we'd like to have our sales guys take the calls, and come on, its so simple to just have the calls just roll over to.
4. Hold Music : Oh we have to have customized hold music, so that we can have different marketing messages for the different queues, and it should be simple, right?
5. Weird billing schemes : Because no one ever bills for queueing on a per-user basis, absolutely no one, trust me, I'm the V.P. of Sales, I've sold telecom for ever

and so on.

So we built this Bradley Fighting Vehicle of a product that satisfied all of our internal needs, it took a year longer than expected (really!), was ridiculously complicated to setup, and needed an advanced degree in CRM to manage.  

And our customers?  Well, we had uptake - quite a bit.  But instead of something that everybody would use, it ended up being a really niche product.

The bottom line?  Your requirements are not necessarily (ok, almost certainly not) that of your user-base.  Don't mix the two up! You are not your use-base!