Managing Sales Requests and Changing Priorities
How do you deal with one-off feature requests from sales that are supposedly deal breakers?
Have you noticed that car salespeople always sell what they have on the lot, while software sales people always seem to sell what they don’t have? After all, our salespeople and executives believe that anything is possible with software.
And it is. But not instantly.
So how do you deal with a request from the sales team to build a feature in order to close a deal? To keep your sanity, it’s important to address this common request head-on during sales-channel training.
There are three parts to getting salespeople to understand managing priorities:
- Explain your prioritization approach.
- Show them the release plan allocations for the items that salespeople care about and the ones their buyers want.
- Share your public roadmap.
Salespeople live in a world of abundance, while developers live is a world of scarcity. Salespeople often cannot see the incredible list of top-priority items because everything on the backlog is important to someone.
Explain that you have a prioritization that favors markets over individual customers. The backlog contains everything—big ideas and small—and each is prioritized using a simple scoring system (such as quick prioritization). Make a list, prioritize it and work from the top down until you run out of time. (See Prioritize Product Delivery with the 5 Queues.)
Release Plan Allocations
To keep salespeople and others satisfied, your release plan should focus on including something for four different groups: something visionary (for executives); something that appeals to buyers (and salespeople); something that helps customers use the product more effectively (and helps your customer support teams); and something for your core product team (usually to address technical debt and other infrastructure issues).
However, some companies have an uneven distribution of capabilities among these four groups, as shown in the red box. The current plan is heavy on capabilities for executives and buyers, but new capabilities for users and technical debt are virtually nonexistent.
I prefer the allocations shown in the green box. It includes something for executives, buyers, users and also something for a healthy product. When you take each group into account, everyone is at least a little happy.
Your Public Roadmap
I recommend sharing the public roadmap with sales teams. Ideally, your roadmap contains the problems you plan to solve. Problems, not features, are key to healthy prioritization—and for keeping the sales team focused.
But remember, a roadmap is not a commitment, it’s a plan. And plans often change. That’s why it helps to focus on problems, not features. It’s likely the problems you plan to solve won’t change, even if the specific features do.
Encourage your sales team to sell what you are confident you can deliver; don’t treat the roadmap as a wishful commitment. In the words of American humorist Mark Twain: “If you tell the truth, you don’t have to remember anything.”
Looking for the latest in product and data science? Get our articles, webinars and podcasts.