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:
headrush.typepad.com/creating_passionate_users/2006/05/dont_give_in_t
o.html