1. Listen to expert users, but don't (often) integrate their suggestions.
I know many experts who will violently disagree with me here, but I think that just justifies my position. Probably one of the worst things you can do is to design your product for experts (unless you have a product that is only for experts, of course). As Khoi Vinh eloquently put it:
"Most features are designed for experts, but most users are intermediate."
Even those who are 'experts' will enjoy simpler, cleaner, more straight forward intermediate features.
Instead, think of ways they can extend your product for their own purposes (API, extensions, etc.).
2. Intermediate users may not tell you what they need, so watch their behaviour. (and sometimes when they tell you what they want, what they actually want is very different)
How are they using your product? Not using your product? Record oodles of data, even the stuff you don't think you need.
Some great examples of smart data collection is Last.fm and DIGG. Both companies have great examples of going against user feedback and opting for using the data to change directions to create a healthier community. For example, DIGG's removal of the top diggers list was not popular, but did a great deal for balancing the ecosystem. Last.fm's mining of the attention data has informed their smart feature roll-outs all along.
3. Respond to every feedback suggestion, even if you respond to tell them you won't be integrating it.
Customers should know that the time they've put into thinking about your product and their experience of it is highly valuable. If you answer even crazy suggestions with a well thought-out response as to why you won't implement it, you will be sending the message that they have been heard. 4. Try not to take flames and other negative feedback personally.
This is a tough one for most people, including me, because a good deal of feedback is sent in a moment of frustration.
The best I can figure is that we all need to stop and think, "It's not about me," and take some time to reflect before responding. 5. If you do use a suggestion that is unique, give credit to the person who gave the suggestion.
Remember those silly suggestion boxes in the workplace? When you put in a suggestion and it was used, didn't it feel good to be 'Employee of the Week?' or get mentioned and thanked for your great suggestion? Didn't it encourage you to invest more time in it? Well, if you didn't get to experience that firsthand like I did, it feels awesome (even if it's a little embarassing at the moment). 6. Indicate changes with a flag.
You know when the traffic department puts in a new light or changes some signage and they put up more signage to signal to people that there has been a change? Well, it may seem redundant to you, but it's not. It's smart. People get into routines and will miss something. Google is really good at putting a 'new' beside parts of their apps that have changed for the first month. It draws people in to explore as well.
Don't take it for granted that everyone reads your blog (although you should blog it as well).
7. Smaller, incremental changes or one big dump of changes?
Well, you know your audience best, but I personally prefer incremental changes rather than a big one. It feels like a company is cooking along. Those that hold back all of their changes in their dev site for a big unveiling tend to fall off my radar and there is a tendency to overthink the smaller changes when a company does this.
Still, a big dump of changes can be an exciting time for a promotional push, I suppose. A good combination of both could be your sweet spot.
8. Don't hire your biggest fans.
So, after you have great feedback and things are going well, it may be hiring time. You may look to your users as future employees. Unless you are an open source project, it usually kills the enthusiasm and gives a false sense of security to a company (stagnating the company). Hire your biggest critics instead and encourage them to continue being your biggest critic.
9. Don't overlook really simple, small suggestions.
They could be the golden key. I think we all have the tendency to dismiss smaller, subtler ideas. People will even say, "Yeah, we already know that." but months will roll by without making those changes. The small, 'unsexy' things will often be put to the backburner for the big ideas. It's a big mistake. Sometimes it's just moving a link 50 pixels to the right that makes the biggest impact. 10. Ego doesn't belong here.
The whole "Not Invented Here" syndrome will kill any positive movement forward. Lead with humility. You don't always have to be the expert and the one with answers.
11. Trying to please everyone will leave you with a boring product.
See Kathy's post on this. Very important. Designing by consensus kills great ideas. 12. Do it right over doing it fast, but don't take forever.
I'm not a fan of whipping out something half-assed just to get it out. That being said, you needn't sit on it and test it for eons either. The most important is to set expectations for your customers who have given you the feedback (see #3). If there is an important change that is effecting service, but it's going to take a while, keep them up to date.
Ultimately, it's very very difficult to balance all of this stuff and for many smart development teams, this comes naturally. However, we've witnessed many train wrecks by not following these simple guidelines. As a disclaimer, I should also mention that following these guidelines to a tee will still not ensure the success of a project, but not following them is deadly.