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.
At what point do recurring feature requests signal market demand and a need to re-evaluate your product strategy? When is it time to validate your customer requests? No matter which customer is requesting something, think before you leap. (This goes for requests from prospects too!)
As a rule, your product strategy should be flexible, but pretty consistent over a given period of time. Ideally, when you developed your product and business strategies, you went through a solid market validation process, considering a number of factors to determine the right product-market fit.
Before frantically re-prioritizing your entire product roadmap and strategy 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 on 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. Your product shouldn’t have to pivot every three months based on customer feedback. So, if it’s not a magic number of requests, how do you know when you should adjust strategy based on feature requests?
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 a 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 makes 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.
7 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.
Tweet This:
“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. Ask yourself what are the customers really asking for?
When a number of feature requests come in, your customers are signaling that they have a shared challenge.
Identifying the problem your customers are trying to solve is critical because it lets you perform a quick litmus test: Is this problem something our product is supposed to solve? Is this problem one that we want our product to solve?
Remembering that your customers are requesting things because they have a job to do is an important step. They’re not asking you to add a button because they love buttons—well, most of them aren’t; they’re asking for a button because it will make their jobs and workflows easier, faster, more efficient, or enjoyable. It might help them build more widgets or ship more software. Understanding their real intentions and motivations is an important part of this process.
4. What are the positive and negative impacts on business metrics if we add or ignore this feature?
If you build this feature, are you likely to see an increase in revenue? A decrease? Are you gaining entry into a new market, one that you had been planning to enter? Would it increase customer retention rates and slow down churn? It’s much easier to make a strategic decision when you can back it up with data and projections.
Tweet This:
“Ask yourself: What are the positive and negative impacts on business metrics if we add or ignore this feature?”
If you’re re-evaluating your product strategy just to meet a handful of customer requests, you might be setting yourself up for failure.
5. What’s the opportunity cost?
Now that you have a sense of the scope of the feature, what resources would be required? Would it be worth pulling your team off of other projects to work on this one? There’s a lot of cost-benefit analysis that happens when weighing feature requests against your overall strategy.
Whether requests come from customers or internal stakeholders, a product manager is responsible for allocating her development resources in a way that advances her strategy without wasting the team’s time and energy.
6. Does it require further investigation or research?
Maybe, after moving through steps 1-4, you’re starting to sense it might be worthwhile to further explore adding the feature. That doesn’t mean you should start development immediately. It just means the feature gets added to your backlog, or to your Table Layout or Prioritization Board. Do some more research. Interview your customers to further understand the problems this new feature would solve. Treat it like any other new component or feature.
7. 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.
You need to use your instincts as a product manager, supplemented by business success metrics, and conversations with your customers and product team, to determine if a feature request warrants a re-evaluation of your product strategy or if it’s an opportunity to say “no” to your customer.
If you’d like guidance on using a weighted scoring model, you can read our post and watch our short video tutorial, for a walkthrough of the process.
