It is difficult to think of a phrase that has been more misinterpreted and misused by businesses than, “The customer is always right.” Customer centrism is always encouraged. BUT, product managers must remember that no, the customer is NOT always right. Especially when it comes to feature requests, you need to do due diligence and validate customer requests before you act on them.
No matter which customer is requesting something, think before you leap. (This goes for requests from prospects too!) Before frantically re-prioritizing your entire product roadmap to get done whatever your customer is demanding, you should take a step back and validate that request first. In fact, stick to this suggestion every time your PM alarm bells start going off. Stop. Think things through. Don’t jump just because a user tells you to jump—no matter who they are, or how loudly they’re shouting.
Because, no, your customer is not always right.
The Origin of “The Customer is Always Right”
Who first said “the customer is always right,” anyway?
While the origin story of “the customer is always right” has blurred over time, the phrase first gained popularity in the early 1900’s. It was initially used in department stores to remind customer service and sales teams how to approach customer interactions. The intent was for customers to feel appreciated, cared for and, above all, not taken advantage of.
Under this “the customer is always right” notion, if a shopper thought they had until today to buy your product at the sale price, when in reality your promotion ended yesterday, it might be smart business to make that concession.
But if you’re a product manager, using “the customer is always right” to guide product decisions could cause some serious harm to your product’s success in the market. Here’s why.
3 Types of Misleading Customer Requests
Customers often get it wrong when making requests or demands, for several reasons. Let’s take a look at a few of these reasons, which we’ve grouped into broad categories of customer personas.
1. “Can’t You Just Make the Product Do This?” (The Unreasonable Persona)
Some people simply aren’t reasonable. Maybe a customer bought a few licenses of your SaaS software, and now they think they’re entitled to demand a fully customized version of your product. And once you do that, they expect you to add whatever new functionality their team needs anytime they ask.
We’ve previously discussed some tips for dealing with unreasonable customers. But for our purposes here, what’s important to understand is that unless you validate a customer’s request to determine it has broader market value, you don’t need to upend your product’s development plans just because one customer is yelling that they want some new functionality.
2. “Do You Know Who We Are?” (The VIP Persona)
One dangerous trap many B2B product teams find themselves in is landing a large customer—say, a multibillion-dollar corporation in the Fortune 100—only to find that customer continuously demanding more. More customization. Expanded functionalities. Extra training and support resources. More everything.
Let’s say a big corporate customer demands you add something to your product roadmap. Or that your team make other concessions just for them. You need to first weigh the costs of fulfilling those requests against other strategic goals.
The thought of losing the business of these large companies can be intimidating. But you can’t let that fear blind you to the even-greater risks of veering off-track from your product’s strategic plan.
3. “What We Need Is… Uh… This, I Think.” (The Confused Persona)
Another thing to remember when you’re confronted with a customer request, particularly one that strikes you as unreasonable or mistaken, is that your customers often don’t know exactly what they want. They know the problem they’re facing, of course, but they often don’t know or can’t articulate how best to solve that problem.
The classic example here is Henry Ford attempting to validate the market for his vision by asking people what they wanted in terms of better transportation, and people telling him they wanted “a faster horse.”
Is that really what they wanted? No. People were eager for more freedom of movement and the ability to cover more distance more quickly and cost-effectively. Turns out that didn’t mean breeding faster horses; it meant inventing the automobile.
The same might be true of your customer’s urgent request for some new functionality or product enhancement. If you delve a little deeper into what’s behind that request—rather than simply jumping and fulfilling it because the customer asked—you might discover they really wanted something else, or that your product already solves the problem they’re facing, and they just didn’t realize that functionality was there.
3 Strategies to Validate Customer Requests
We’ve discussed some common scenarios in which it might be a strategic mistake to fulfill a customer’s request for your product. Now let’s talk about some of the strategies you can use to determine the validity of such a request when you’re not sure.
1. Check the customer request against your roadmap.
You’ve developed your product roadmap for a reason. It’s there primarily to serve as a high-level visual summary of your product’s vision and strategic plan of attack.
But you can (and should) treat your roadmap as a set of strategic guardrails to keep your product on track. These guardrails ensure your team doesn’t veer off course. They’re protection against “shiny object” features that fail to serve that larger strategy.
“Your roadmap acts as a set of strategic guardrails to keep your product on track and safeguard against “shiny object” features that fail to serve your long-term strategy.”
This is exactly the type of thing that can happen when a product team reflexively leaps to fulfill every request or answer every complaint. And it’s why you should check every customer demand against your product strategy. (This is also a good reason to have a roadmap that’s easy to access and review with your team. Customer requests and demands come up often.)
2. Validate the customer request against your market.
Maybe a customer’s request to add a new piece of functionality would be a great idea for their unique process. But is not much value to any other company that uses your product.
When a customer goes to the trouble of asking for new functionality, it can be extremely valuable information. Perhaps they’ve uncovered a new value-add you can build into your offering. Maybe you can use this feedback to improve your product for every user.
So, which is it? The only way you can know the answer is to ask your market. Not sure how to do this? Check out our post on how to craft a great customer survey.
3. Subject the customer request to a weighted scoring model.
Let’s say a customer has asked your team for something. A new feature, support for a new operating system, an upgrade to your data encryption protocols, whatever.
You’ve checked this request against your product roadmap (tip 1), or you’ve put the question to your user base via a well-crafted survey (tip 2). In either case, you’ve determined that, yes, there is some strategic merit to this request—it could add real value to your product that will likely both enhance your existing customer relationships and help you attract new customers.
But questions remain: How much of a priority should you give this customer request? Does it jump to the front of the line on your product roadmap? What kind of resources and budget does it warrant?
You can’t answer these questions in a vacuum. You’ve got other items on your development team’s agenda. And limited resources.
Our suggestion: Use a weighted scoring model. With this approach, your team can create a common currency—points—across key business metrics, such as revenue or customer delight. You then can also distribute points against the costs in terms of resources, risk, opportunity cost, etc.
If you’d like guidance on using a weighted scoring model, you can read our post and watch our short video tutorial, for a walk through of the process.