On a call this week, a sales leader described the thing that happens in a lot of enterprise companies: a rep hears the same problem three or four times, drops a note into Slack or Salesforce, and hopes somebody who can do something sees it. The rep is trying to sell, the product team is trying to protect its time and nobody owns the trip between the customer sentence and the product decision.
That is why evidence-based product prioritization is often weaker than it looks. Teams have scores, intake forms and planning meetings. What they lose is the reason the customer cared in the first place. Was this a nice request, a real blocker, an expansion opportunity or an implementation headache that will show up after the contract is signed?
For a revenue leader, that missing context is expensive twice. First, the deal can stall. Then, when the team finally ships a response, the prospect, customer, rep or account manager who needed it may never hear about it. The teams using this loop are currently seeing 2x upsells, 2.5x cross-sells and 4x prospect re-engagement.
TL;DR
Evidence-based product prioritization should connect a request to the customer, the commercial situation and the product work that follows. Count frequency, but do not let frequency replace context. A request from nine accounts can still be optional, while a request tied to one $150,000 opportunity can change a decision. Keep the original evidence visible, label uncertainty and review the outcome after the work ships.
Why a backlog score is not enough
I used to think the hard part was getting requests into one tidy system. It is useful, but it is not the actual job. A tidy system can still make a weak decision if every request arrives stripped of its deal stage, customer use case and the exact friction the rep heard.
One sales leader gave a clean example: several customers wanted a prior-authorization capability. The interesting number was not the count of requests. It was the commercial context attached to it: nine customers and roughly $150,000 in revenue if the team could solve the problem. That does not mean the feature is automatically worth $150,000. It means the team has something real to investigate instead of a vague demand signal.
The same call made the current alternative sound familiar. Sales teams keep a spreadsheet, attach something in Salesforce or leave a note in Slack. Then the rep moves on. By the time product looks at the issue, the meeting is gone, the account detail is scattered and the customer language has been flattened into a title like “improve authorization workflow.”
How to do evidence-based product prioritization
Start with the original customer evidence. A call recording or transcript is better than a polished summary because it preserves what the customer was trying to accomplish and what made the problem expensive. Extract the request, but also capture the account, owner, opportunity stage, timeline, competing workaround and a short excerpt that explains the stakes.
Next, separate request volume from commercial severity. “It would be cool if you supported Spanish” and “we cannot add this user until this works” are both feedback. They should not receive the same treatment. Give the product team a way to mark whether the issue is a stated blocker, a repeat operational problem, an adoption gap or a preference. That keeps a very loud request from pretending to be a revenue case.
Then connect the request to the actual work. A product manager should be able to see whether the team declined it, is researching it, has added it to a project or has shipped a constrained version. The revenue team should be able to see the same thing, including what is not included. That is how you avoid a rep making a promise from a vague roadmap comment.
How to prioritize feature requests based on deal size without making sales the product team
How to prioritize feature requests based on deal size is the question that makes product teams understandably nervous. Deal size matters. It should not create a private ordering system where every large prospect buys a custom branch of the product.
Use deal size as one piece of evidence, alongside repeatability, strategic fit, delivery cost and the cost of carrying the work afterward. A large deal attached to a one-off integration can be worth doing. It can also create years of support debt. The useful conversation is not “sales wants this.” It is “this account is worth this much, these other accounts have a similar need, this is the smallest credible scope, and this is what it displaces.”
That format protects both sides. Sales gets an answer rooted in the customer situation. Product gets the freedom to say no, with the reasons recorded. Leaders get to see which decisions are bets and which are already supported by repeated evidence.
What should happen after the feature ships?
Evidence-based product prioritization does not end at release. In a second call this week, a business operations leader described a company where 60% of revenue comes from upsells and one added license can be worth $50,000 a year. New functionality is often included in the product tier, so the commercial opportunity is not “charge for the feature.” It is helping an account see a reason to expand use.
That creates a very practical test. When the feature ships, tell the account owner which customers asked for it and why. Give them the real scope, not a celebratory release note. Then watch what happens: did the owner follow up, did the customer engage, did usage change, did the original blocker remain? Those are the events that tell you whether the prioritization decision was right.
It is annoyingly easy to measure tickets closed and call the process mature. A better system measures whether a decision made it back to the person who had the customer conversation. If it did not, the company may have built the right thing and still left the money on the table.
FAQ
What is evidence-based product prioritization?
It is a method for choosing product work using verifiable customer, commercial and operational evidence. The evidence should include the request itself, the customer situation and the later result, not only a vote count.
Should product prioritize the biggest deal?
Not by default. A large opportunity deserves attention, but product should also assess repeatability, fit, delivery cost and the support burden created by the work.
What evidence should sales provide with a request?
Provide the customer problem in their words, account owner, deal stage, expected impact, workaround and any time constraint. A call excerpt is often more useful than a rewritten feature title.
How do you know a prioritization decision worked?
Track the sequence after release: account follow-up, customer evaluation, usage or deal movement and the remaining blocker. Shipping alone is not proof of value.