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:
* 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.
...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...
(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.
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?
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 ; )
Posted by Kathy on May 10, 2006 | Permalink
TrackBack URL for this entry:
Listed below are links to weblogs that reference Don't give in to feature demands!:
Tracked on May 11, 2006 1:08:20 AM
» Application Growth, Feature Creep from GeekMatic
Kathy Sierra raises some good points about not accepting new feature requests. This is basically a long-term version of what analysts and developers call feature creep, although where feature creep is something that happens during the development proce... [Read More]
Tracked on May 11, 2006 3:30:28 AM
Tracked on May 11, 2006 2:34:02 PM
» Managing the Mangement from AiAlone.com
I needed this graphic a few years back.nbsp; I had to open the Pandora's Box of design (Color) while working on a major project and this graphic would have helped.nbsp; EVERYONE has an opinion about color (hell everyone has an opinion about d... [Read More]
Tracked on May 12, 2006 2:53:50 PM
» Hateful and Uncaring Customers from CustomersAreAlways
Kathy Sierra of Creating Passionate Users shares with us some of the pitfalls of listening to all your users (customers) and how to go about filtering the negative feedback. I would think that it would be good to listen to... [Read More]
Tracked on May 14, 2006 11:59:15 PM
» Dont run a mediocre forum from Brian's Business Blog
I know. I love forums. I think they have a more real sense of community than blogs anyday. And in terms of marketing, offer far better potential. Butthe same principles of marketing apply to forums. Creating Passionate Users runs an article... [Read More]
Tracked on May 18, 2006 7:38:38 AM
Tracked on May 22, 2006 6:51:19 AM
Tracked on Jul 24, 2006 7:23:13 PM
Nintendo has grasped two important notions that have eluded its competitors. The first is, Don't listen to your customers. The hard-core gaming community is extremely vocal--they blog a lot--but if Nintendo kept listening to them, hard-core gamers would be the only audience it ever had. "[Wii] was unimaginable for them," Iwata says. "And because it was unimaginable, they could not say that they wanted it. If you are simply listening to requests from the customer, you can satisfy their needs, but you can never surprise them. Sony and Microsoft make daily-necessity kinds of things. They have to listen to the needs of the customers and try to comply with their requests. That kind of approach has been deeply ingrained in their minds."
Stick to satisfying expectations and they'll end up being the limits you're chained to!
Posted by: nick | May 11, 2006 1:23:38 AM
You forgot the previously passionate, now purely habitual ("meh") user. This guy is another one you have to listen to. What made him lose his passion?
Anyone whose attitude has changed for the worse will be worth getting input from. And they might value being given the opportunity to voice their criticisms. Everybody wants to be heard, after all!
Posted by: Karyn Romeis | May 11, 2006 2:56:39 AM
I really like this article, though I wonder about that first statement.
"The more successful the product or service is, the stronger the pressure to give in to user requests."
It seems in my own experience that the less successful a product or service is, the more pressure I feel to try to meet the demands of the user. Just a thought.
Posted by: Paul | May 11, 2006 6:43:56 AM
I think its also important to have a philosophy, or a set a guiding principles behind ones product. To give an example of what I mean, I’m working on a web product that has built in very hierarchical constraints on how information can be accessed. If I was building the same product my guiding principles would be oriented towards facilitating information sharing. Feature creep is the opposite of the guiding principle of simplicity. One has to keep an open mind – we don’t know in advance how our users are going to use our products – but a sense of what the core values are behind the product gives the product continuity. It helps filter out the requests that are not in the right spirit of the product and helps suggestions that are shine through.
Posted by: Marc DeRosa | May 11, 2006 6:51:41 AM
Brilliant...and pertinent to me on a new project that is just spinning up.
However, would dearly love to see a "Print Friendly" version link/button on your posts!
Posted by: Andrzej Taramina | May 11, 2006 7:01:07 AM
Thanks for the great info! I'm getting ready to launch a new niche website that could potentially have tons of users, and this article will help me as I review customer requests.
Posted by: Tim Priebe | May 11, 2006 7:24:33 AM
This post tastes like warmed up leftovers from "Featuritis vs. the Happy User Peak" and one or two others.
Posted by: Daniel Berger | May 11, 2006 8:54:11 AM
Just last week I was having a conversation with a co-worker about technology, and how we wished we had more choices of things that just work, with their default settings, right out of the box. No fuss, no silliness. All too often, we get forced into upgrading to versions with too many bells and whistles, which just get in our way.
But, that need for default simplicity doesn't preclude the product from having an "advanced mode", which would allow expert users to configure things to their heart's desire. You don't like green? Fine, make it orange. Don't like Windows XP's default cartoonish look? Switch it back to the "Classic Start Menu", for the Windows 2000 look. The "emacs" editor in UNIX allows you to select between five different levels of expertise right up front.
My first experience with this kind of flexibility was way back in the 1980's, when I first encountered DBase III and its all-powerful "dot prompt".
In fact, being able to switch painlessly between different modes or "skins" characterizes all of the products I feel most passionate about.
Posted by: Robert Shepard | May 11, 2006 9:11:01 AM
So fun - your talk about Green, Blue, Red, etc. reminds me of this brain study, called the Stroop Effect. It gets you even when you think it's not going to get you. See for yourself how it works on you!
Posted by: Think_n_See | May 11, 2006 9:14:41 AM
Here it is again:
Posted by: Think_n_See | May 11, 2006 9:19:42 AM
The final post: STROOP EFFECT
Posted by: TnS | May 11, 2006 9:22:50 AM
The Event Horizon of feature creep.. after a certain point, you and everyone else just KNOWS that something needs to be implemented.
So good design skills would be recognizing critical features before you cross the event horizon and you look like you've gotten egg all over your face. :)
Also, I just can't deal with it unless it's in fuschia.
Posted by: Aurynn Shaw | May 11, 2006 11:32:44 AM
When I read your post I see 37 Signals and BaseCamp written all over it, and it turns me completely off to your message. The problem is 37 Signals markets BaseCamp as the ultimate project management system for everyone, but then actively denies adding features that are essential in use cases other than those needed by a web development firm.
So, if a company is going to piss off the "blue," "pink," and "orange" users they should at least make sure they market the product specifically targeting to "green" users and not try to sell it to everyone.
Posted by: Mike Schinkel | May 11, 2006 11:48:14 AM
"but then actively denies adding features that are essential in use cases other than those needed by a web development firm."
Essential *to you* which is exactly Kathy's point. Everyone has their own set of "essential" features. If everyone's essentials were plugged in to make everyone individually happy then no one would be happy.
Basecamp doesn't have any features specific to any one industry. There's no web design features, there's no publisher features, there's no professor/teacher features, there's no architect features. There are just general, simple tools that apply to everyone: messages, to-do lists, simple scheduling, and file sharing.
Posted by: Jason Fried | May 11, 2006 1:49:43 PM
Ignore the uncaring? I'm not sure I agree. If a user is near-totally ambivalent about your solution as compared with someone else's, doesn't that tell you a great deal about your product?
Posted by: Mad William Flint | May 11, 2006 2:24:10 PM
Great posting, as I experience this article its concludes to me its all about choice. Personal choice and what that choice means to you. Visuals like these help to clarify, it learned me that black/white are only extreme forms of grey. Thanks
Posted by: Renald Chi | May 11, 2006 2:44:13 PM
This post is extremely helpful and arrives at a critical time. I'll be sharing it with all my staff. Thanks--again.
Posted by: Gardner | May 11, 2006 4:14:24 PM
"Ignore the uncaring? I'm not sure I agree."
I see your point really well, but you then have to go a step further, and ask where the critical mass of apathy lies, don't you?
There's always going to be a section of your userbase that drifts with the winds. How much is too much?
Moreso, should you be concerned if there -isn't- anyone who doesn't care one way or the other? Some sort of success barometer based entirely upon user apathy?
Posted by: Aurynn Shaw | May 11, 2006 4:28:43 PM
I been an avid reader for a while. But, how much of the above post is from the writer's experience and how much of it is his/her's hunch?
The post makes broad, sweeping and attention-grabing conclusions, which without experience is far far less useful than it could be.
Posted by: Ram | May 11, 2006 5:57:32 PM
You guys have a lot of great comments -- thanks.
Karyn: "You forgot the previously passionate, now purely habitual ("meh") user. This guy is another one you have to listen to. What made him lose his passion?"
Paul: "It seems in my own experience that the less successful a product or service is, the more pressure I feel to try to meet the demands of the user."
That's true, but what I meant by that was that the more successful it is, the more *external* pressure you get. I should have specified that, because you're right -- in the beginning there's more internal pressure to make the (fewer) users happy (and attract new ones).
Mad William: " If a user is near-totally ambivalent about your solution as compared with someone else's, doesn't that tell you a great deal about your product?" That makes sense... I hadn't thought about it like that.
Daniel: Yep -- I tend to revisit my favorite topics a lot, although I try to add a slightly new perspective to it. But I'm impressed if you remember my old posts better than I do.
Ram: I've personally seen it from just about any perspective, and dealt with each of the groups I named. As a software developer (everything from in-house business apps to public games), I've fielded requests and demands from existing users, managers, external clients, marketing, and engineers on other parts of the system. But, I've also seen the same problems with our books (although that's just as often about what to remove/tone-down as it is about what to add), and the internal and public training I used to do (client wants 20 topics in a time that's appropriate to cover 10, everyone has different ideas about what those 10 should be, etc.).
I'm not sure what you meant by attention-grabbing conclusions... I think just about all of us who are in this situation struggle with the same things (demands to change our products), and the point of this post for me is to start playing with ways to organize those requests/demands. We've got more than a quarter-million readers of our books right now, and that represents a staggering amount of feedback--there has to be a better way to filter it and apply different "weights" to different users, while still listening for ideas that make sense. And all too often, those who make the most noise often ARE the ones we should pay the least attention to. But I reckon it's always dangerous when you try to figure out who and what to ignore, since getting that wrong carries a big penalty.
Anyway, I'd consider this post an "alpha" -- my first cut at identifying/classifying/filtering requests. I never suggested that I've gotten this right, which is why I'm so grateful for the readers who offer ways to make it better. If you've got specific ideas, Ram, I'd love to hear them.
Posted by: Kathy Sierra | May 11, 2006 6:55:47 PM
I must say I really enjoyed this post. As the product director of MyPhotoAlbum I really love all our members. We have the philosophy that it’s our members that have made us successful so it's hard not to try to solve every problem, change everything that people ask. Our team is very personally invested in what we do, and because of that, sometimes, criticisms hurt. After all it is our baby.
Many of your comments were right on point. If only you could please all of the people all of the time. I think that sometimes users forget that we want you to like it, use it, tell other's how great it is. But everyone's definition of that GREAT is... unfortunately.... different. But I guess that's what makes working in the Internet business so fun.
Keep the great post's coming.
Director of MyPhotoAlbum.com
Posted by: Jessy Hanley | May 12, 2006 8:16:46 AM
Since you added "Engineers/Developers/Producers with little or no user contact", "Marketing/Sales" and "Customer Service / Tech Support" as categories, you are missing one other:
"Quality Assurance/Documentation" These folks usually come in after a feature has been implimented to meet the customers demand and sometimes have no contact with the client yet believe that a feature either goes too far or not far enough.
They definately belong in the "LISTEN..." group. Since QA's job is usually to break the program rather than actually use it, feature requests sometimes arise from lack of understanding of the use of the product in a real world senerio. Though sometimes feedback from another view close to the code is helpful.
Posted by: Blkbam | May 12, 2006 10:51:58 AM
I always thought the Kool-Aid point was the differentiator between those who "got it" and those who didn't get it.
Posted by: Mike Drips | May 13, 2006 10:36:54 AM
I think it's a fundamental mistake to filter feature requests based on who they're coming from. Even people who will completely hate your product no matter what you do can still offer useful insights into improvements.
Posted by: Scott Reynen | May 14, 2006 4:03:16 PM
Kathy, what an awesome post. I have blogged about it as consider it to be ESSENTIAL reading for any Web 2.0 marketeer looking to engage the community more and realising it is not as easy as it sounds!
One thing that cannot be underestimated is the value in those customers that complain.
People rarely call to say "thanks for your wonderful service or extremely practical vacuum cleaner bags".
People more often call with complaints which, given the effort and passion (read: anger!) required to be bothered to call/write/email means that the complaint is significant.
The customer in this instance is aleady helping us by letting us know what the worst parts of our product or service is and shoudl be treated better than most.
I often say that the sign of a good company is how it resloves its mistakes and we can only learn from the complainants.
Posted by: Paul Fabretti | May 17, 2006 3:58:10 AM
The comments to this entry are closed.