Don't give in to feature demands! The more successful the product or service is, the stronger the pressure to give in to user requests. The more users you have, the more diverse the requests. One user's must-have-or-else feature is another user's deal-killer. And the more popular your product or service is, the more those requests start turning into demands and ultimatums, and finally very harsh criticisms. The worst thing we can do is give in. But as the requests/demands and criticisms become louder and angrier, the harder it is to resist the siren call-- "But if we just added this one thing... these guys would ease up." But when we've blended all the colors into one muddy blob, then nobody hates us, and nobody is delighted, excited, or turned on by what we do. We become mediocre. Usually the worst place to be. But we can't just ignore the suggestions, requests, and criticism. So how do we filter the useful feedback from the crap? How do we know who we should listen to? Let's say that most of the people who might make feature requests or demands fall into one of these categories: 1) The Active Haters Those who hate you no matter what you do. The more popular you become, the louder they become. 2) The Extreme Critic Those for whom "hate" is too strong a word, but they have a mile-long list of things you're doing wrong. 3) The Against-My-Will User Those who are forced to use your product or service, but aren't happy about it. Maybe you're the only one in your category, or their employer or client made the decision--whatever the reason, they don't like it. 4) The Previously Satisfied, Now Overwhelmed User Those who were satisfied once, but have now become unhappy because of updates and changes in the product. They just want to go back to the way things were! They could not care less how much more productive/creative/stimulated they could be if they embraced the changes. They worked hard to cross the "suck threshold", and they don't want to go back. 5) The Previously Satisfied, Now Impatient User These folks are unhappy for the opposite reason as the Now Overwhelmed User. They're pissed off that your updates and changes haven't kept up with their requests which have recently turned into demands. They're the most likely to go elsewhere without much warning, because they feel they've outgrown you or that you just don't care. [Or just don't care about them.] 6) The Previously Passionate, Now Pissed Off User Ahhhh... the most interesting users of all. They were your biggest fans, but You Just Wouldn't Listen to them and now they're threatening to go elsewhere, passionately, but they're giving you plenty of notice. They want to regain that spark they once felt, but the original bond only goes so far. 7) The Still Satisfied User Whether they're too new to know what else they might want, or you've simply met all their expectations and requirements, these users are humming along without problems. 8) The Still Passionate User Our favorites. They're thrilled with what your product or service lets them do. But... this doesn't mean they don't have requests. They can be passionate without necessarily being satisfied, but they'll do everything they can to help you improve. The trouble is, we're back to the same problem... one passionate user's idea of Useful Improvement is another's Worst Mistake You Could Make Ever. 9) The Uncaring User They just don't think about your product or service. They use it, but if something else came along that did the same thing, they might not even notice the difference. 10) Marketing (and sales) They ask for things based on research (often dubious), or their own feeling/judgement about what people want, or perhaps based on feedback from sales people, etc. 11) Engineers/Developers/Producers with little or no user contact They may want to put in "this really cool thing we could do", regardless of whether anyone has asked for it. This could be the classic "solution in search of a problem." 12) Engineers/Developers/Producers in close contact with users These are the folks that interact with the customer/clients/users on a regular basis, usually prior to and during development, with less contact after the thing is done. 13) Customer Service / Tech Support Those on the front line! The ones who are in the closest contact with users. [I've probably left out some crucial category, so help me out here.] Now the big question is, who do we listen to? I'd love for you to add your advice, but here's a rough cut of one way to think about it: COMPLETELY IGNORE: * The Haters The Haters are too irrational about you to offer any criticism you can trust. They might have valid feedback, but if it's valid you'll hear the same feedback from other less-hateful users. * The Uncaring * Marketing (couldn't resist) KEEP ONE EAR OPEN: But only for new ideas, not for specific requests and criticisms (again, if a criticism or request is really valid -- you'll hear about it from many others) * The Extreme Critic * The Against-My-Will user * Engineers/developers with little or no user contact Just because you can do something "really cool", doesn't mean you should. LISTEN... ...but resist the pressure to give in until you've considered all the long-term implications to all the OTHER user groups: * Previously Satisfied, Now Overwhelmed I think we're often better off trying to train them -- to help them get up to speed on the new stuff without having to suck again. * Still Satisfied Their suggestions aren't coming from real motivation, but they might have a good idea... * Marketing (Unless you really REALLY know and trust that your marketing people deeply understand both the product and the users. Too often, they just want to make something more "sellable", regardless of the big picture.) * Still Passionate These are often the most difficult to resist! But they may ask for things that nobody needs, just because--like engineering--it would be cool. PAY ATTENTION: That still doesn't mean you'll give in, but feedback from these users should be given a lot of weight. * Previously Satisfied, Now Impatient These are the people who are on the verge of becoming passionate users, if you can keep up with them! One problem is that they may want to push you into territory that is out of your niche, and if you please them by adding advanced features, you have to make sure you don't create new "Now Overwhelmed" users as a result. But anytime we can add advanced features without hurting the low-lever users (who may stay that way forever once they have the basics down), we should consider it. If we want users to be passionate, we have to give them new challenges--new ways to learn and grow and apply their new skills and knowledge. Another option is to create a separate more advanced product -- like Apple's three different music apps (when you outgrow GarageBand you go to Logic Express. When you outgrow Logic Express, you go to Logic, etc.) * The Previously Passionate, Now Pissed Off User It took a LOT to piss them off, because they've been extra forgiving and willing to overlook your faults, but only to a point. They know your product better than anyone else. One problem with these guys is that they tend to be so advanced that they don't necessarily reflect your average user. If you can find a way to work with them (and they desperately WANT you to succeed and win them back), and perhaps compromise, they'll be your biggest champions again. At the very least, we should tell them that we've listened carefully, and here's why we're having trouble adding or changing this thing... they might even have an answer we hadn't thought of. And at least we've given them the respect they deserve. * Engineering/Developers in close contact with users They're close to the product, they understand how it's being used. Best of all, they might know the best 80/20 way (most bang for the development buck?) to do the smallest thing that'll have a positive impact. They are the best source of ideas for compromise without hurting existing capabilities. (But I've spent enough time as a member of this group to know that we can't help ourselves from "adding this one cool thing" that we know "will take no time at all." So challenge our assumptions.) PAY THEM FOR THEIR FEEDBACK: * Customer service / tech support Nobody knows where the pain is the way the front line does, and they can probably get very specific about the exact source of that pain, which lets you do a more surgical fix rather than a sweeping change. But one question... why--in so many companies--are these the people who often get the least amount of respect and voice about this? * You The one user category I didn't mention. In the end, we have to trust ourselves. This is a controversial position--we're not supposed to be building things for us... it's not about us. But that doesn't mean we aren't the ones who can make the best overall decisions. We're the ONLY ones who get all the feedback and can think through the long-term implications, and can see how pleasing one user group might piss off another group, so which group do we choose? If you have a product or service or cause where you "eat your own dog food", then you're in at least as good a position as any user to know what's broken and what will break if you listen to this request. So, we have to listen but resist. The overwhelming pull of that right (hate) side slides you closer and closer to the middle. Those who hate it will hate it until you've neutered it into submission and taken away the magic some once loved. Be brave ; ) source: http://headrush.typepad.com/creating_passionate_users/2006/05/dont_give_in_t o.html