Your users are complaining? That’s great!

As Product Managers, we are always on the lookout for what our users want. 

We use methods like tracking user behavior on our products, running user interviews, mapping user journeys, and more - constantly looking for user ‘pains’, or opportunities to leverage ‘joyous moments’ etc.  

But there is 1 tool live products can take advantage of, that is often overlooked. 

While new products and products under construction have to rely on assumptions and calculated guesses, at least until they launch, live products enjoy the benefit of, well, actually being live… 

In other words, live products enjoy the benefit of having actual users using their product and providing feedback.  
And although we usually try very hard, not all of our users are constantly satisfied with our efforts. 

Nonetheless, this is a good thing — as unsatisfied users can often prove as priceless to our product’s development. Provided we can understand what actually hides behind their dissatisfaction.

live products enjoy the benefit of, well, actually being live… 

I was working as a Mobile Product Management Lead for a News & Media company in Israel. 
Most of our focus at that time was around scaling up one of the recent apps launched as part of our mobile portfolio, and I was heavily looking for user feedback to help optimize the product.

We benefited from the app being live for a few months already, and the fact that a core group of users was highly engaged and vocal, providing feedback both directly to the app support desk and in the apple store/google play reviews.

Analyzing this feedback pointed to several issues which were all taken into account. Here are a few examples from our app stores reviews and customer support:

1. “There’s too much items about traffic and weather, not enough ‘real’ news” 
2. “Let us customize the feed to show only topics we care about” 
3. “Please allow push-notification sound customization” 
    

We of course took these and all other feedback into consideration, and prioritized all relevant ones based on things like volume of requests for a certain feature, urgency, effect on our target KPIs and so on, but we didn’t stop there.  

We’ve also used the users’ feedback to identify “Hidden Requirements”.

 

IMHO, this is one of the most important parts of the product manager role:

Taking that ultra-specific client complaint or feature request, and deducting from it what core requirement for the entire product it might be hiding.

To explain what I mean, let’s have a look at the all-time famous and slightly overused quote of Henry Ford (or Steve Jobs, or none of them, depends who you ask), referring to his user research approach before mass manufacturing the T-Model Ford automobile:

“…If we asked people what they wanted, they’d say faster horses…”

This quote is usually given as an example of how to build products while ignoring user feedback.

I have a slightly different approach to understanding this sentence.

The way I see this story,
Is that those users that Henry Ford was referring to, actually did know what they wanted.
The did know that they in fact wanted a faster way to get from A to B…
They just didn't know how to say it.
So they used the terms they were familiar with - “Give us faster horses” they would have said, assuming they were indeed actually asked.

Henry Ford deducted that they needed a faster method to get from A to B, and so came up with the best solution he could find for addressing that comprehensive problem.
He built a wagon powered by a combustion engine instead of horses. 
Perhaps better known as the ‘Model T’ Ford automobile.
 

An effective product manager knows how to identify the user’s ‘Hidden Requirement’ out of its feedback or complaint, and turn it into an opportunity to make its product better, or hopefully, make it the best in its class — Since he truly understood what the users needed, even if they couldn't express it themselves. That specific trait, is what makes Henry Ford and Steve Jobs some of the best product managers of all times. 
 

An effective product manager knows how to identify the user’s ‘Hidden Requirement’ ...... Since he truly understood what the user needed, even if they couldn't express it themselves.

So how do you identify the comprehensive requirement behind your users’ complaint? The simple answer is, well, very simple — you look for it.

Seriously now — Whenever you encounter a user complaint, or even a specific request for a feature, your first step should be to ask “Why?”. “Why” do the users complain about it? what is it that actually bothers them? Ask it again and again until you find the root cause to the problem.

Asking “Why” is actually a familiar technique for getting to the root of a problem quickly. The technique, developed in the 1950’s by Sakichi Toyoda, one of the fathers of the Japanese industrial revolution, suggests that you can get to the root of any problem by asking “Why” 5 times or less.  

Here is an example of how car manufacturer giant, Toyota, is using this method.

you can get to the root of any problem by asking “Why” 5 times or less.  
 

So back to our young news app.

Some of the user feedback we received was definitely in-line with our data and our product goals, and we could address them directly. 
Those that met all criteria were prioritized first. The rest went into different stages of the roadmap and backlog. 

But the most important ones for us, were the ones indicating a more comprehensive requirement to the entire product, or a possible usage trend that can be leveraged.

Let’s take a look at the first 2 of the feedback examples listed above, to show what ‘hidden requirement’ we could make out of them: 
 

1. “There’s too much traffic and weather-related content, not enough ‘real’ news”
    
2. “Let us customize the feed to show only topics we care about” 
    

One is a complaint about the content, the second is a feature request. 

However, by asking “Why” over and over, trying to understand why users are making these comments, we realize they actually both point to the same user pain: 

The content is not always relevant for the specific user. 

Both comments were referring to the same thing, and were actually different stages of answers to asking “why”. 
Let's break down this example to show how we realized it. 

We asked “Why” over and over again, answering for the user (when possible of course - ask the users themselves).
This time it took us only 3 “Why’s” to reach the root of the problem in a way we could address it:

looking at the 2nd comment: 
‘Let us customize the feed to show only topics we care about’  

• We asked “why?” 
  ‘The content is not interesting enough as it is’ 
• Asking “why?” again, lead us to (the 1st comment): 
  “There’s too much traffic and weather-related, not enough ‘real’ news” 
• “Why does it matter?” 
  “I’m not interested in weather and traffic-related news, they are not relevant for me…”

Instead of limiting ourselves to the narrow point of view of our users’ specific feedback, by using roleplaying we could identify the root problem, and enable a wider range of possibilities for solving it. 

So from identifying our root problem as the relevance of the content to some of our users, we could isolate a meaningful action item that can be addressed — Making sure the content in the app is as relevant as it can be for the maximum possible users (without creating, yet, a separate app for each user…). 

For solving it we could use a variety of approaches: we could choose personalization, we could choose to go with the majority of the users, or any other solution that would provide the highest ROI.  
However, identifying the actual need of the user is what determines if we are investing our resources effectively. 
And we got a clear indication here, that we at least needed to optimize our content. 
 

identifying the actual need of the user is what determines if we are investing our resources effectively

So we indeed addressed it through both content optimization and new features, enabling easier navigation between content topics. 
Both of which proved extremely effective. 
Future steps included actual content personalization.
 

Another interesting example was the 3rd request related to the push sound (We were using the default device push notification sound at that time): 

3. “Please allow push-notification sound customization”. 

The request itself, in several different forms, was repeated enough times by multiple users that we addressed it twice within a short period (creating a customized app unique sound, and later adding a feature specific sound and enabling selection between the sounds). 
However the need for specific push sounds was not the main conclusion from the feedback, nor was the multiple requests the actual reason we addressed it with 2 specific features. 

It was the “Hidden Requirements” behind the requests, that were far more important in our minds.  Here is what we have deducted when using the “why” method: 
 

• Users were asking to distinguish between the push sound of our app to other apps on their device. 
  They wanted to know when it was our app which sent them a push message, reasonably enough so that they could respond to it and not dismiss it by hearing it as “just another push notification”.
   
• Users were specifically addressing our push notifications sound.  
  To us, the specific referral to the push messages alone, confirmed that they saw it as an important interaction channel with our app.

Those were important notions, and we were definitely going to leverage on them, with both our content strategy and new features supporting the push notifications.

One more important step for a proper handling of your audience feedback.  

Your user, whether he was complaining or commenting positively, eventually, gave you an important feedback.
Moreover, he showed genuine interest in your product. 
So genuine, that he actually made the effort to ask you to improve it so he can use it even more. 

Never take this for granted.  

Even better, use this opportunity to communicate with him, thank him and keep him in the loop as for your plans about his request.  
Your solution might not be exactly what he expected — for example we did not add the option to customize the feed or the push sound just yet —  however, we did make changes that resulted from his feedback. 
That alone shows appreciation, and that his feedback matters. Our users were always delighted to learn that.  

So make sure to keep such an engaged user in the loop regarding his feedback, and you’ll get yourself a loyal user and perhaps even a positive advocate. Not to mention you’ll be adding some light to the world by making someone feel better, and that’s always a good thing.

• Treat your customer support and any other user feedback tool as a source of genuine user requirement
• Do not take those complaints or requests as they come - try to understand the real requirement hiding behind them
• Ask “why” up to 5 times to get to the root of the problem
• Act on the root problem, not the original feedback
• Keep your users in the loop about the outcome of their feedback