Objection Handling for Product Managers
What’s an objection? As Merriam-Webster defines it, an objection is “an expression or feeling of disapproval or opposition” – and too often, our customers will have objections to our product.
Therefore, to be effective product managers, we need to know how to deal with customer objections and convince our customers to stick with us. This skill is called “objection handling”.
Why Does Objection Handling Matter?
Objections are natural. A truly engaged user who is committed to using your product is trusting a part of their life to you. Therefore, they’ll want to push you to introduce new features, or complain about gaps within your product.
This is a good thing! Feedback enables us to build better products.
At the same time, however, we shouldn’t just cave to every single request. Our job as product managers is not to be people pleasers – we need to know how to say “no” to low-value requests and to push back against unreasonable demands.
After all, we have limited resources.
Yet, when we push back, we need to do so in a way that puts the customer at ease, and in a way that builds trust.
Effective objection handling does exactly that. You can provide powerful narratives that convert your critics into your fans, and you can enable these fans to appreciate the thoughtful approach with which your organization builds products.
As a side note, one common belief is that salespeople should handle objections, and that product managers shouldn’t be involved.
I disagree with that belief.
Product managers should play a key role in handling objections because product managers have qualitative insights from user research, backed by quantitative product metrics and data across their entire existing customer base.
Product managers can provide the clearest view on how customers use the product, and provide informed assessments and decisions on why the product is being built the way it is. Product managers are uniquely positioned to deliver narratives that make sense to customers from a variety of angles.
Now that we’ve established the value of objection handling and discussed why product managers should handle objections, let’s dive into best practices on how to handle objections. Any product expert in the PMHQ community would, more or less, tell you about the same best practices.
Best Practices for Objection Handling
As product managers, our job is to empathize.
Therefore, when a customer objects to you, the first thing to do is to actively listen.
Never shut down a customer ahead of time. That will only make them defensive, and they’ll feel unheard. The worst possible thing you can do is to cut them off because they’ll perceive you as rude, cold, and uninterested.
Take the time to listen to their struggles, and be truly curious and empathetic. Why are they facing the pain that they are? Why do they feel that you have not provided a satisfactory product to them? Dig deeper until you understand the full story.
Now that you’ve established a baseline of understanding and rapport, it’s your turn to tell your story. Objection handling, after all, is just another form of communication, and communication is a two-way street.
People are naturally attuned to stories. When tackling objections, think about the story that you want to tell. You have a reason for why you can’t give in to their request – what’s the narrative that will make the most sense to them?
I’ve learned the hard way that I can’t just tell the story from my perspective. I need to tell a story that makes sense from the customer’s perspective.
For example, I’ve told narratives in the past about how their request would break my product’s architecture, and how it would take us a long time to build their feature. That narrative didn’t help ease the conversation at all – after all, it’s my job to worry about how to build it, and the customer honestly doesn’t what cost we incur to build something.
What made more sense was to discuss why their request would wind up delaying their other requested features and to have a candid conversation about tradeoffs. By positioning myself as their champion and advocate, I had a much better time convincing them that they should focus on just the features that would provide them the most value.
Common Objections to Handle
Product managers frequently work with two classes of objections: 1) feature requests, and 2) timelines.
Let’s discuss each in detail.
Feature Request Objections
The feature request objection runs something like this: “I’m not going to use your product unless you build this feature for me.”
Your customer is asking for a specific solution because they have a particular pain they’re struggling with. Rather than focusing on the specific solution itself, dig in to find the pain.
What’s the real challenge that they’re struggling with? Many times, you’ll find that their challenge is already solved by an existing feature, by a workaround, or through a reframing of the problem (e.g. internal process change instead of external feature request).
Once you’ve understood the pain, repeat your understanding back to them so that they feel heard and appreciated.
I can’t tell you how many times this single step has entirely resolved feature request objections on its own. Many times, customers force feature requests onto you just because they don’t feel heard!
After you repeat your understanding back to them, propose the next steps – whether it’s collecting additional customer feedback, tabling the request, or deciding to accept the request. That way, you’re in the driver’s seat and can make the right decision.
Don’t let yourself be in a reactive position. If you’re reactive instead of proactive, your customer will always force you to build their specific feature using their specific requirements, even if it’s not the right thing to do.
Timeline Objections
The timeline objection runs something like this: “You’re taking too long to build this thing. Build it faster, or I’ll stop using your product.”
Timeline objections are actually featured request objections in disguise. There’s some pain that your customer is dealing with, and the pain has gotten so intense that they can no longer wait.
Again, dig in to find the pain. Find out why their situation changed. Why were they okay with your timeline before, and why are they no longer okay with your timeline now?
Same as above – repeat your understanding, then propose the next steps proactively.
With timeline requests, your customer inherently understands that you have limited resources, which is why you’re taking longer than they’d like. Remind them that you have resource constraints, and ask them whether they can help you in exchange for helping them.
It’s fair for you to make an offer if someone requests one from you. Remember, value is a two-way street. You can ask them to reprioritize their other features so that you can reallocate resources, you can ask them to scope down the ask so that it’s easier to complete, or you can ask them to provide additional resources in the form of monetary compensation so that you can accelerate the work.
If your customer does not agree to any of the above, remind them that you have limited bandwidth, and confirm with them that the original timeline cannot change. You can only change the timeline if they give you the ability to do so.
By being transparent with the customer – that you have limited resources and that you have multiple priorities to juggle – you’ll find that they’ll usually relent on the request and will have more patience.
After you come away from a timeline request, be sure to provide proactive status updates to this customer so that they gain more confidence in you over time.
Empowering Your Organization to Handle Objections
You can’t be everywhere at the same time. No matter what, someone is going to object to your product through some channel, and you might not be present to deal with the situation.
I’ve found that it’s incredibly helpful to create a list of common objections as part of your product documentation and provide that to your customer-facing teams – whether it’s sales, customer support, customer success, or account management.
Below is a genericized example of an objection handling document that I’ve provided to my own teams, ordered by frequency of request.
As you read through the document, note the following themes:
- We should always conduct customer discovery and validate their concerns.
- We need to tell compelling stories about why we’re pushing back.
- For each objection, we have a clear set of next steps to reduce confusion and boost our own confidence.
Without further ado, here’s the list!
- “I need this kind of integration with your product.”
- Find out why your customer is asking for this integration. What’s the use case? A lead management use case is entirely different from a compliance use case.
- Depending on the use case that you discover above, propose this workaround. Note to them that many of our customers use this workaround with no trouble at all.
- Let your customer know that we are currently evaluating integrations that provide the highest immediate impact for our customer base.
- “I need your product to be a mobile application. I don’t want it to be just a website.”
- Let your customer know that our website is mobile-responsive, and that their users would prefer not to download apps because it takes up time and valuable space on their phones.
- Inform them that we had previously built a mobile application, but decided to sunset it because we did not see sufficient usage.
- Let your customer know that we build our platform as mobile-first, and that we’ve rigorously optimized through user testing and data analytics.
- “You have a feature that works for XX use case, but doesn’t work for YY use case. I want it to work for YY.”
- Let your customer know that the feature currently cannot handle YY, and that across our customer base, we haven’t seen much need for YY.
- Probe your customer to determine what percent of their use cases are YY, and how much value it brings them. You should generally find that this request is a nice-to-have, and that it doesn’t drive significant user value.
- Internal only: it would take us about 1 quarter’s worth of development work to build out YY. The ROI isn’t worth it.
“I want to be able to customize all of the logic within your product.”
- Let your customer know that our well-known competitor ABC allows for 100% logic customization, and yet few in the industry use ABC because full-blown customization is incredibly difficult and time-consuming for the customer.
- By offering pre-packaged logic based on robust data analytics and deep customer research, we are actually providing them value. Our customers love that they can “set and forget” and move forward with their business, rather than dealing with customization.
- Internal only: giving customers the ability to customize our core logic creates a huge problem when it comes to testing. If we gave them that ability, it would exponentially increase our test cases, which would slow down our ability to quickly ship the product.
- “I want to change the text in your product.”
- Let your customer know that we’ve conducted extensive field research with users to create the most compelling text possible, that we have powerful feedback mechanisms within the product to determine areas of confusion, and that we’re always reassessing the text in our product to ensure that it’s intuitive.
- Convince your customer that they should focus on higher-value business processes and that they can leave the details to us.
- “I need you to deliver this [already-committed] feature on an accelerated timeline.”
- The reason why we’re taking so long is that this feature is incredibly complex. Inform your customer that we only ship high-quality features and that we’re taking this time to ensure we fully understand the edge cases and handle each of them appropriately.
- Remind your customer that we serve many customers at once and that we have limited resources. If they would like to accelerate our development, inform them that we would need to secure the needed resources to accelerate and that they will need to pay their fair share to secure those additional unplanned resources.
- “If you don’t build this feature, I’m canceling the contract with you.”
- Loop in the product manager immediately. They will have additional context based on experience with the rest of the customer base.
- Probe your customer: what is the pain that this feature is supposed to solve? Why are they experiencing this pain, and why do they expect us to solve this pain rather than using a different pre-existing solution?
- Are there workarounds that they can use to mitigate the pain?
- Is this feature request common within the industry, or is this a one-off?
- Is there a particular deadline that they’re trying to hit, or do they just need us to commit to building it eventually?
- Remember that we build for total impact. If this customer is not impactful and building the feature does not solve problems for any of our other customers, we should seriously consider letting them go.
Summary
Objection handling is a critical part of a product manager’s job, whether they know it or not. After all, every ask can either be accepted or rejected – and we can’t possibly accept every ask while ensuring that our products are cohesive, delightful, and valuable to our total customer base.
Therefore, knowing how to handle objections empowers you to create better products, and converts your critics into your fans. By sharing clear reasoning for why you need to turn down their request, your customers will appreciate you for your transparency and thoughtfulness.
Additional Resources
Objection handling is a tactic that originates from sales. Below, we’ve provided resources that more thoroughly cover sales objection handling. You can apply many of those same techniques to product management as well!
- The Secrets of Highly Successful Sales People: Objection Handling – The Secret Product Manager Handbook (by Nils Davis, active PMHQ Slack contributor)
- 12 Objection Handling Techniques for Sales – Gong.io (2018)
- The Ultimate Guide to Objection Handling: 40 Common Sales Objections & How to Respond – HubSpot (2018)
- 6 Techniques for Effective Objection Handling – Salesforce (2013)
Have thoughts that you’d like to contribute around objection handling? Chat with other product leaders around the world in our PMHQ Community!
