Sales talks to your customers more than you do, and what comes back is feature requests with the evidence stripped out. How PMs can keep the customer's verbatim words attached as requests travel to the roadmap.
Look at where the items in your backlog actually came from. If you're a PM at a company with a working sales motion, most of them arrived the same way: a Slack message from an account executive, a line in a CRM note, a forwarded email from the CEO after a big call. Customer X needs SSO on the reports page. Two prospects asked about version control. And the most effective variant, the one that jumps the queue every time - as one B2B founder we interviewed put it, relaying what came back from customer calls:
"A few of them raised this feature as a deal breaker for them, full stop."
There is nothing dysfunctional about this picture, and it is worth saying so before criticizing it. Your customer-facing teammates talk to more customers in a week than you could interview in a quarter. A senior PM we spoke to described the situation most product teams settle into: too busy building to run discovery personally, so the flow of user contact runs through sales, customer success, and the CEO - the people who are already in the room. That is not laziness. It is a sensible division of labor.
The trouble is what the labor produces. What travels back from those rooms is almost never what the customer is struggling with. It is what the customer asked for - a request, arriving already finished, already shaped like a roadmap item. And a feature request is a peculiar kind of evidence: it is a solution with its problem amputated. Somewhere in the original conversation there was a person describing their situation, in their own words, with a struggle in it. By the time the request reaches you, the situation, the words, and the struggle are gone. What is left is a conclusion you are invited to either build or ignore.
This essay is about that amputation - where it happens, why the standard fixes don't hold, and what it takes to move the customer's actual words, rather than other people's conclusions, into the hands of the person deciding what to build.
The amputation is easiest to see in a single exchange. A product designer we interviewed at a B2B data-tools company described sitting in on an analysis of sales calls with her CTO. On one call, a customer had started to describe a problem - and the salesperson, doing exactly what salespeople are trained to do, closed the gap immediately: "my version-control feature can solve that."
The CTO's correction is the whole argument of this section:
"If that's true, you only need to hold it at the level of 'I need to see what changed when I make a change.' It doesn't have to be version control - another solution could work."
Notice what the CTO did. He moved the request back to the altitude it was at in the customer's mouth, one sentence earlier. I need to see what changed when I make a change is a problem: it names a situation and a struggle, it admits several solutions, and it can be weighed against other problems. Version control is one team's guess at an answer, expensive to build and impossible to compare. The salesperson didn't do anything wrong - closing gaps is the job. But the conversion from problem to solution happened in the room, at the moment of maximum context, performed by the person with the least stake in getting the product decision right. The same designer was blunt about why:
"Sales thì không có nghiệp vụ đào sâu" - "sales doesn't have the training to dig deep."
Again, not an insult; digging deep isn't their job. But it means the conversion runs in one direction only. Once "I need to see what changed" has become "they want version control," nobody downstream can run the tape backwards - unless the original words made the trip too.
Here is the detail from that company that we have not been able to stop thinking about. Their sales input didn't get weighed on a scale of importance or deal size. It got filtered by something much simpler:
"Sales input mostly gets dropped. If sales can bring back a direct quote, it moves forward; if not, it gets skipped."
Read as process documentation, that sounds arbitrary. Read as an evolved behavior, it is very smart. The team had converged, without anyone designing it, on the insight that the verbatim quote is the unit of product evidence. A quote carries the customer's altitude, their vocabulary, the texture of the struggle - everything the request format strips out. A summary carries the summarizer's conclusion. The team couldn't articulate a policy about problem-versus-solution framing, but they could feel the difference between input they could judge and input they had to take on faith, and they priced it accordingly: no quote, no roadmap.
The same interview shows what happens when the quote is missing and judgment has to run on summaries alone:
"The CTO knows what needs to be done, so he can spot the problem inside a sales report. The product team can't pick out the data points to make a decision from."
The CTO could decode a stripped, solution-shaped sales report because he brought a decade of industry empathy to it - he could regenerate the missing context from memory. The PMs couldn't, and no amount of process was going to fix that, because - as the designer put it - "to build enough empathy to make good decisions takes years; you can't just sit through a few calls." A company can survive on this arrangement, and hers did: the founders reviewed every feature from problem to design. But a workaround that requires a founder's judgment at every decision is a bottleneck wearing a hero's costume. It doesn't delegate, and it doesn't scale.
So the condition for anything better is set: the product team needs the customer's data points - the words - not a wiser reader of other people's conclusions.
Most PMs who see this clearly try one of two fixes, and both fail the same way: not on intent, but on cost.
The first fix is take back the calls. If sales strips the context, the PM should be in the room. Every PM believes this, and at the data-tools company they even tried it - for a while. The designer's account of how it ended is an epitaph for the approach:
"PMs used to reach out to customers on their own, but everyone is buried in delivery - there's no shortage of things to build."
Discovery run on PM heroics has the same failure mode everywhere: it works at the start of an initiative, then delivery pressure rises and the calls quietly stop - "and it's not like anyone has the spare time to sit around listening to calls." The call volume that makes sales such a rich source is exactly the volume a delivering PM cannot personally attend.
The second fix is more sophisticated: upgrade the pipeline instead of replacing it. A senior PM at a business-intelligence company described the most mature version of this we've encountered:
"Our product team trained the sales team to ask basic discovery questions - what's the use case - and some salespeople have the taste to go deeper. Then the product team sits down and re-listens to those calls to synthesize."
This is genuinely good practice, and it honors the condition from the previous section - the product team goes back to the customer's actual words. But look at the price tag hiding in the second sentence. Re-listening is discovery's most expensive activity: an hour of tape costs an hour of PM attention before synthesis even starts, and the volume that makes the sales channel valuable makes exhaustive re-listening impossible. His team, too, admitted the calls had thinned out - most contact now happened in shared Slack channels. The fix is right in shape and unaffordable in practice. Which tells you precisely what's missing: not better intentions, and not another process - a way to get quote-level evidence out of customer conversations at a cost that survives delivery pressure.
This is the specific gap CLRA is built for. The principle: stop trying to attend the conversations; transport the verbatim words instead.
Concretely, the loop looks like this. The raw material your customer-facing teams already produce - call notes, transcripts, the long Slack thread where a customer explained their setup - goes into CLRA as an interview. If it lives in markdown somewhere, the CLRA MCP server pipes it in without copy-pasting. Then CLRA's AI does the re-listening the BI company's product team was doing by hand: it reads the full note and extracts candidate insights as highlights - each one the customer's own words, anchored to the exact place in the source it came from. You judge the results instead of producing them: keep the real pain, discard the polite noise, and tag what each quote actually is - Pain, Worldview, Jargon, Observation - so a belief about how things should work never gets mistaken for a burning problem.
Then comes the step that undoes the amputation. Instead of filing "version control" in the backlog, you frame what the quotes actually support as a problem - a job story at the customer's altitude: when I make a change to a report, I want to see what changed, so that I can trust what I'm shipping to my stakeholders. The problem stays linked to the highlights that justify it.
When a stakeholder asks "says who?", the answer is the customer's own sentences, one click away - which means the evidence rule that smart team evolved informally ("no direct quote, it gets skipped") becomes the default state of your problem space rather than a lucky exception. And when the third customer this quarter says something that sounds like the same struggle in different words, the pattern is sitting in one place instead of scattered across three people's call notes.
Unlike GitHub Issues or Linear, where a request lands as a finished conclusion waiting for a build/ignore verdict, CLRA connects the user's pain directly to your build decisions - the request is stored as the problem underneath it, with the words that prove it. The backlog tools are fine at what they do; they were just never meant to hold evidence.
Sometime soon, another message will arrive: a customer said a feature is a deal breaker. The argument of this essay is that the message is neither an order nor noise - it is the visible end of an amputated conversation, and the valuable part is the part that didn't make the trip. Your sales team remains what it always was: the richest stream of customer contact your company has. What has to change is not who takes the calls but what travels out of them - the customer's sentences, kept whole, tagged for what they are, attached to a problem you can defend.
Ask for the words. Give them somewhere to live. The requests will keep arriving finished; you no longer have to take them that way.
Pipe your next batch of call notes into a free CLRA workspace - and if your discovery also runs through online communities, the CLRA extension captures verbatim quotes at the source.
