If you want to be a bad product manager, assume that lack of complaints means your product is successful. There are lots of customers using your product, so when you add a new feature or make a change and don’t hear complaints, that must mean that everything is working fine. If something was really unusable or broken or didn’t meet your customers’ needs, they would let you know. It’s much easier to just make a change or add something to the product and wait to hear feedback than to do a whole bunch of research and testing first — that’s just a waste of time, right?
If you want to be a good product manager, proactively seek out feedback rather than wait for complaints. Lack of complaints does not mean that you have a fantastic product — it just means that you are not getting any complaints.
Waiting for customers to complain is problematic for several reasons:
- Not all customers complain. Think about all of the products you use on a daily basis, and the problems you encounter with all of them. There may be a confusing button on your cell phone, a strange error message on your online banking site, or a slippery grip on a kitchen gadget. How many times have you taken it upon yourself to contact the organization responsible for that product? Despite the multitude of different ways to complain — from the traditional methods like contacting the company directly, to more modern methods of voicing your frustration on Twitter or a product review site — most customers do not make the effort to send this feedback directly or indirectly to the company. A product manager simply hoping to hear from customers with problems is only going to hear about a fraction of the problems from only a fraction of the customers. For every customer who vocally complains, there are likely tens or hundreds or thousands of others who are silent.
- Lack of complaints may mean lack of customers or users. While we would like to think that lack of feedback means lack of problems, it is often that lack of feedback means lack of experience on which to provide feedback. When a product manager adds a new feature to a product and does not hear any complaints about the feature, he may assume that the feature is a success and the fact that customer service has not received any complaints is because it is working smoothly. Unfortunately, it could be just as likely that no one is using the new feature, and thus no one has any experience about which to complain. If there are a small number of customers using the new feature, relying on their complaints alone may provide very skewed feedback.
- By the time someone complains, it is usually too late. While the previous two points are worth noting, this is truly the most important reason to not simply wait for complaints. For physical products, changes to a product after it is in the market can be extremely expensive and time consuming to rectify. From a purely financial standpoint, it is the responsibility of a product manager to attempt to produce the best product and thus avoid costly changes. However, even for web-based products which can be changed very quickly and cheaply, waiting for customers to complain is backwards approach to product development. Sure, it may be gratifying on the surface to say that you are able to respond quickly to problems that customers raise, but wouldn’t it be better to prevent these problems in the first place? Would you rather buy a car from a company who listens to your complaints and reacts when your car has problems, or would you rather buy a car from a company who produces a car which will not cause you problems and will not cause you to have to complain?
Ultimately, no matter how hard an organization tries to address problems and meet needs, people will complain, and product managers can benefit from listening to and understanding those complaints. However, when a legitimate complaint is lodged, rather than just reacting to it, product managers should ask, “How did we not know about this earlier?” Is the complaint related to something that the team should have known about? Would a better understanding of the customer needs have helped prevent it? Would better design or more usability testing have uncovered the underlying problem? Did a defect make its way into the final product? Did we know about the problem and just hope that no one would notice? How did it come to this — that a customer had to complain in order for us to realize something was not right?
Complaints are a valuable source of information which can be used to help improve your product, though they are only one source and should be used carefully. Product managers need to be proactive at gathering feedback from customers and prospects, though activities like usability testing, Win/Loss analysis, site visits, observational interviews, and other types of qualitative and quantitative research. Rather than just waiting for complaints and responding to them, product managers need to be focused on preventing them from occurring and getting to the root cause when they do appear.
Translations available:
Thanks for the reminder. Product managers should proactively visit clients (buyers and non-buyers) firsthand. The current thinking seems to be that follow-up phone calls and surveys (qualitative methods) will suffice but nothing beats a good face-to-face meeting. Qualitative research is needed before and after qualitative.
Thought provoking piece, Jeff. Thanks.
Developers should prototype and A/B test their interfaces. With SaaS, the functionality appears on a page, so use shows up in the server logs. If you use web analytics, you can see where customers quit using the application. It may be hard to see optimal use, but A/B testing your views will tell you if one particular one is better than the rest.
When you prototype, you do not need to wait for a product manager to tell you to change something. From a product manager’s prespective, if you don’t have to direct, or you can direct less, you end up with more time to be proactive somewhere else.
Not to pick on one vendor… but read through the commentary from this particular prospect as he recorded his thoughts on Twitter.
http://search.twitter.com/search?q=bellware+mingle
Someone should have been on this long before it got to the point it did.
When you design for learning, it comes back to you as a lack of usability, but if you design for usability, it never comes back to you as a lack of learnability.
A lack of fitness shows up as Excel spreadsheets and Access databases on the desktop. Look for them. Ask about them.
Jeff: good point and one that can be easily forgotten when we all have way to much to do each and every day. What I’ve discovered with some customers is that they can actually be shy about providing feedback (yeah, we all know all too well about the ones who are not shy!) These are the ones that you may have a great relationship with and for some odd reason they don’t want to spoil things by calling your product ugly. Well, in the end you’ll get the point when they stop buying from you (“I just want to date other products.”) These are the customers that you really need to go after and see if you can dive beneath the “It’s ok” comments and see if you can get to how they really feel.
– Dr. Jim Anderson
The Accidental PM Blog
Good product manager always looking to the other comatitaor practice, and try to understand them not to copy them..As it will be no use for them.
Understand And don’t Copy
Hi! Ivan?
Would you be so kind to look at that of my website and would you give me a feedback about it?
I,d like you to ask how I could be able to sell that website.
Thank you very much it forward.
Yes no news is NOT good news. Those three key points really hit home for a product manager.
Complaints and feedback are the same just one is in a position of reaction and the other is proactive.
Jeff,
Thank you for yet another great post.
You covered it all so good. I could only add that it’s good to hunt for updated users feedback and not stick to hackneyed truisms such as “all our customers like X” or “none of our customers do Y”. Often times PM’s try to achieve some feature for years and lose the moment when it’s no longer relevant.