You’re probably pretty familiar with the following scenario. You’re sitting at your desk typing away. Out of the blue, you get a Slack message from a sales rep asking you for a feature a customer just requested on a call. The sales rep tells you that the customer is a big customer, but you know the request doesn’t align with your product strategy.
Before you have a knee jerk reaction and reject the sales request, check yourself! Sales requests are a critical source of information for product managers, and it’s dangerous to simply shut down requests because they don’t align with product strategy at first glance. You’ll end up missing out on some amazing opportunities to innovate.
How do you navigate between focusing on product strategy versus incorporating sales requests when they make sense? We’re going to dive into this topic in the following blog post, providing clear tactics on how you can best manage sales requests, especially when they don’t align with product strategy.
You’ve probably seen the hundreds of memes that make fun of the love/hate relationship between sales and product teams. Sales reps have endless feature requests and often promise features that haven’t shipped yet. Product managers say no to a bunch of requests and often don’t ship features on time.
So what creates this massive gulf between sales teams and product teams? There are four main reasons for this:
Sales reps are beholden to quotas that they have to achieve on a (usually) quarterly basis. In order to hit their quotas, they have to look for ways to get customers to say yes faster. The faster they get a customer to commit, the more pipeline they can build. Product teams, on the other hand, plan out projects that often take months or years. When two teams operate on different timelines, they will obviously make different decisions!
When sales reps sell the product, they focus on high level benefits, selling points, and features. Product managers need to dig in deeper on the details — the precise functionalities, the workarounds for common use cases, the flows from A to B. Sales reps have a good sense of what customers want at a high level, but usually don’t know the details of exactly how to ship a product that will meet customer needs. The details of how to build a product lie with product management.
It’s important to remember that sales reps are dealing with customers every single day. Some customers can be rude, dismissive, or forceful! When your job is dependent on getting customers to say yes, you’ll obviously feel pressure to meet their requests. Product teams are insulated from this pressure, which makes product teams well positioned to make better prioritization decisions, but at the same time more distant from customer requests.
Sales teams worry about the direct customers they deal with. Product teams are responsible for the entire product area they own. For sales reps, an immediate request from a large customer is a dire situation. For product teams, that request is just one of many requests that span the entire product surface area.
Although it might seem that sales and product have irreconcilable differences, having a strong relationship between sales and product teams is something you should work towards, even if you don’t have it today. That’s because ultimately, product managers need to build things that sell. That means building a great product that your sales team can sell that meets the needs of the people they are selling to.
Sales requests are an incredible source of information for you as you build out your product roadmap. But the challenge for product managers is to deeply understand the sales request, turn it into a solution that solves the underlying problem, and prioritize which requests to handle first. We’ll dive into how you can get this right (and wrong) in the following sections.
I’ve been a product manager for almost a decade now, and I’ve tried a bunch of different strategies to manage sales requests. The biggest mistake you can make is to ruin your relationship with sales, so it’s important to find ways to work with them without making them feel like they aren’t being heard.
As a product manager avoid:
I’m guilty of doing this — when approached with a request I know we won’t do in the near future, I just tell sales that I’ll add it to the roadmap with no context and no timeline. This is pure laziness on my part, because providing that additional context in response to a sales request is a lot of work, especially when I get requests day in and day out!
The thing is, sales can tell that you are giving them the cold shoulder. Less confrontational sales reps will simply stop coming to you with requests. This is bad because like I mentioned earlier, sales requests are critical data points you need to build the right products. More confrontational sales reps will get frustrated with you, leading to friction and disagreements that build up over time.
It’s very dangerous if saying no to sales requests becomes a habit. Every once in a while, there really is an important sales request that you should do that you would have never come up with yourself. Always seek to question whether you’re saying no to a sales request because of muscle memory, or if you really think it’s not the right thing to do.
Although we don’t want to keep pushing sales off and ignoring requests, we also don’t want to build exactly what sales asks for unless it maps to what makes sense for the product. If you simply build what sales asks for when they ask for it, you might get the timing wrong by building a feature before enough people need it, or you might build an obvious solution to a problem, instead of the best solution.
Now that we’ve talked about strategies that you shouldn’t use when managing sales requests, let’s walk through a better way to handle sales requests. The steps I outline below are steps that I like to take when I hear sales requests. They help me avoid saying no to great sales requests, and also help me frame rejections in a way that continues to preserve my relationship with the sales team:
You should definitely avoid having a knee jerk reaction to sales requests. Although you may feel like you are bombarded by requests all day long, you must keep an open mind so that you can truly leverage your sales team’s expertise to build an amazing product. Truly hearing a sales request is as simple as asking a couple additional questions to determine whether or not you should dig in. Some great questions to ask include:
It’s important to make sure you truly understand the problem customers are facing, not just the feature they are asking for. As a product manager, you might have a better sense of how to solve customer problems in a way that makes more sense for your product. By truly understanding the problem customers face, you can make better decisions on whether or not a sales request is worth doing.
Now that you’ve heard a sales request and done some research, it’s time to decide whether or not you want to take on this sales request. Just because a sales request doesn’t match your strategic product roadmap, doesn’t mean it’s not worth taking on. That’s because you could be ignoring an important customer problem or missing out on a better market by sticking with your existing product strategy.
I find that the best way not to miss out on an opportunity hidden within a sales request is to go through a quick cost-benefit exercise. Think through the best and worst case scenario for a new feature. You might realize that if you say no to a sales request, you could fail to meet customer needs and lose out on an excellent market!
Rather than telling the sales rep that you’ll “add it to the roadmap,” a better response is to come back to the sales rep who requested a given feature and provide a sense of whether or not you’re going to take on that feature and when. This gives sales reps closure. Now they feel heard, and they also know tactically how to handle customers who continue asking for a given feature as they have a clear sense of whether or not the product team will eventually build the feature.
At this point, it’s time to stand your ground. Even if the same request comes in again, you can use the same rationale to explain your decision because you’ve already done the work. However, be careful not to stand your ground if new information surfaces. If you’re starting to see more requests, if the market starts to shift, or competitors start to move into this space, you must reconsider whether or not to re-prioritize.
At the end of the day, remember that it’s your job to make sure your product roadmap builds towards positive business outcomes, not just for the next sales opportunity, but for the next year (and more!). That means that if sales teams request features that don’t align with product strategy, you have to find a way to say no.
On the flip side, you must strive not to miss out on opportunities hidden within sales requests. This balance is difficult to manage, but it’s what makes product management fun! By following the steps outlined in this blog post, you’ll be well on your way towards finding a balance that works for you.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
A project baseline acts as a reference point so you can compare project progress against your intended plan.
Kunal Thadani shares necessary qualities of a full-stack PM, including being resourceful, process-driven, and willing to wear many hats.
A data product manager (DPM) is a type of PM who specializes in managing products that are heavily reliant on data.
Dan Lawyer, CPO at Lucid Software, talks about his philosophy that without autonomy, there is no leverage as a leader.
Learn more →
