Ask News.YC: How to fight features?
Well, it's quite obvious when your product gains some popularity users start bombing you with feature requests. The problem I would like to arise here is how do you handle these requests ? Of course you can gather some statistics then start implementing features that are being asked more frequently. But, at some point you start receiving a lot of controversial feature requests: one group of users claim that the feature they request is more important than the feature requested by the other group, sometimes even claiming to remove feature requested by the opposition. How do you rule out such situations ? Please advise.
Features are intricately coupled with usability design - which incidentally looks really easy, but is in reality extremely hard.
What I would do is gather all the feature requests, and see if there is a pattern among them. Often there is. For instance, if you are doing a webforum: One user wants a feature that allows him to change tha background of the app, another user wants to change the border thickness of the forum posts, and yet another want to be able to have his name blink when he posts to the forum.
In this rather contrived example there is a clear pattern: It all has to do with design. And you can implement all the requests by creating a design editor where users can change the look of the site. If you are really clever you can do a javascript app that lets users pick out indivivual elements and apply CSS styling to them, maybe with a nice userinterface that lets him pick colors from a javascript palette, and nice input boxes for border thickness. And you can use javascript to let the user see his changes instantaneously... I'm getting carried away now...
Anyway: If you gather all the feature requests in logical groups, and look at how many requests there are in each group, as opposed to just how many users want to have their name blink when they post to your forum you will get a much clearer idea of where your problems are. Also, you will be able to solve many requests by implementing one feature - which will admittedly be a larger one, and thus more work.
If, on the other hand, you slap features on every now and then in no particular order you will in time end up with an interface that is almost impossible to figure out because there is no consistency. Just look at word ;-)
But as I said: Usability is much harder than it looks.
(Note: This is a little bit of a plug for ideas I'm a big fan of, but it's not for anything I make money on.)
I recommend you setup a project and encourage your users to use a feature voting site like the one we have for startups/hackers to use:
http://featurelist.org http://featurelist.org/projects/add/
There you can have your users upvote features and you can really see which the majority like best (rather than tracking all of them via email).
Once I know what the users want, I rank the features internally using the method I mentioned here for getting a rough notion of ROI for each feature: http://news.ycombinator.com/item?id=122203
The enthusiasm of your users on those features can help you calculate the business value (though other things should factor in). But you shouldn't decide to code them unless you've also calculated the cost (including some factor for long-term costs) of implementing them into your product.
Just pick the ones you're yourself most enthusiastic about first.
Tough one. One option is to use a poll. The best option is to go with your opinion, and that of your fellow founders. If you think a feature would make a good addition to your software, go for it. If the feature takes away from what your project is, don't use it.
http://fevote.com/ has an interesting/digg-like approach to managing features/comments on feature requests, etc