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.
12 comments
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.
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.
We are developing mobile application. The problem we stuck in with is the GUI: what was initially considered as best usablity for one group of users appeared to be totaly unacceptable for another. We were trying to solve this controversity by making every thing configurable. But again we came close to the point where the number of different settings and options is beyond of understanding even a very experienced user :-). I understand that we have to rethink all the concept of the GUI, but I don't see any decent ideas :(. Perhaps we need some fresh look on this from someone outside.
Throw me a mail if you like, I'll be glad to have a look. My mail is in my profile. I probably won't be able to get back before the weekend though.
It's always fun to see what others are doing, besides maybe as you say it will be easier for someone that hasn't been too involved beforehand. It often is.
It's always fun to see what others are doing, besides maybe as you say it will be easier for someone that hasn't been too involved beforehand. It often is.
If you have exactly two mutually exclusive sets of users, I'd suggest just having two GUI set-ups, with a big ol' toggle switch between them. I'm guessing that's not the case, though--can you be more detailed as to what the differences in the requirements for the different userbases were?
(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.
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.
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
Henry Ford has a great quote on this:
"If I asked users what they wanted they would say a faster horse"
"If I asked users what they wanted they would say a faster horse"
Surveys are a lot more effective. The best part is that you can be very vague about your next steps and find out what the users think of the different aspects. That way, you can modify the feature to what they want and what you want without asking them.
Well, I don't think that social approach for solving usability issues is a good idea. The only you can get applying it is a total misconception. Just take a look on to what "solutions" Nature has came using genetic algorithm :-)