If you work at a software company, then you know how hard it is to avoid feature bloat. You obviously want to listen to feedback from your users, but if you implement every feature requested, your software will end up complicated and uninspired. So how do know where listening to user feedback ends, and succumbing to feature bloat begins?
I recently came up with a new trick to help me make tough decisions about feature requests from users. Imagine the following situation. Someone signs up for LAS and starts using it. A couple months later they send me an email saying, "I really like your software, but it would be way better if it could (yada yada yada)." It's a small feature that I could build pretty easily, but how do I know if it would actually make the product better, or if I'm just tempted to do it to keep this one customer happy?
My new trick is that I imagine that I build the feature as the client requested, but then the next day, the client cancels their account. How do I feel about that? Am I annoyed that I just built a useless feature and the one person that wanted it isn't around to use it? Or am I pleased that all the other users will benefit from a great new feature? This question is much easier to answer than the much more vague "should I build this feature" question.
Here's how I realized that this approach works: A few months ago a new user (on their free trial) asked for a way to enter contacts quickly without logging into the full site. Based on that idea, I built an "Add a contact" bookmarklet which users can install in their browsers. A couple weeks later it was time for the user that requested that feature to pay, and she decided not to. Generally when you build a feature like that for someone, you do it in the hopes that they'll pay so I felt like I should be disappointed, but I wasn't. I knew that it was a good feature idea and I thought that LAS as a whole was better off for having it. If I didn't actually believe the feature should have been added, I would have been pretty frustrated. That's when I realized that I could probably use the same scenario to evaluate ideas in the future.
Note: That user ended up coming back and paying, but I already had my realization before that happened.
So point of all this is: if you build software and a customer requests a feature, consider if you would build that feature assuming the person requesting it was no longer a customer. Sometimes you'll think, "yeah, that's still a great idea." Most of the time you'll think, "I have a million other ideas that are more important. There's no way I'd work on this one unless I had a specific customer asking for it." You should interpret that second thought to mean that the feature just isn't right.
Saying "no" to your customers right now is hard, but it's a lot easier than having to explaining to your customers why your software sucks a year or two from now.