Why CROs need to speak Product
CROs spend a lot of time thinking about how to improve how their team sells and not enough thinking about what they sell.
The successful CRO of the future will inverse those. Deals get blocked because of feature functionality more than any other reason. Upsells frequently get delayed because of feature requirements. Even the product team wants to know what to build.
Revenue usually has the information needed to answer that question. It's scattered across thousands of calls said in slightly different phrases each time. But, that's not the hard part. The hard part for Chief Revenue Officers is taking off their Revenue hat and putting on a Product hat. Specifically, how does Product like to receive information and feedback in a way that will cause them to act?
Sales feedback is usually too messy for Product
Sales hears prospect and customer problems constantly. It can be off handedly mentioned in demos or account calls or even contract negotiations! The issue is what happens next.
A rep drops a Gong clip into Slack, while another rep "submits" something to the feedback form (and never hears back). At the morning meetings, a third rep even remembers losing a $100K deal over something similar six months ago. By the time the conversation reaches Product, the original customer problem has usually been turned into some version of "we really need this feature" or we will never win another deal. You lose all credibility and it's not very useful.
But to empathize with Revenue teams, there is one thing unique to you. Your compensation is tied to your performance. So every minute you aren't selling, BETTER be about how to sell more. So things like submitting product feedback, understandably, gets left by the wayside.
What revenue needs to product to product
Product has to decide whether the problem is common, which customers have it, how painful it actually is, whether the requested feature is the right solution and what gets pushed out if the team works on it. That is why Revenue needs to do more than pass along requests.
I've written before about why Product ignores bad sales input. A lot of the tension between Sales and Product comes down to the format of the information, not whether Product cares about revenue.
What useful product input from a CRO looks like
A CRO does not need to become a Product Manager.
But they should be able to walk into a product conversation with more than a handful of anecdotes.
Instead of:
We keep losing deals because we don't have this.
You want something closer to:
Three mid-market hospitals worth $420K in ARR are blocked by the same workflow. Five existing enterprise customers have asked for it too. Here are the calls and the exact quotes.
That gives Product something to work with. There is a pattern with specific accounts and commercial impact. There is also enough customer evidence for Product to understand the problem directly instead of relying on a summary from Sales.
The same thing applies when customers ask for a specific feature. A customer saying "we need bulk editing" is useful, but it isn't the whole answer. Product still needs to know what they are trying to accomplish, what they do today instead, who else has the same problem and how often it gets in the way.
CROs who understand that tend to have much better product conversations.
The four rules for revenue teams communicating to product teams
Having successfully led product teams and revenue teams, I've learned to speak both languages. So you don't have to, I've distilled all of this down into a set of rules. If you take only one thing away from this article, it's these rules.
- Specific Patterns, not general anecdotes: Product teams want multiple occurrences of a thing and HATE "a customer needs this". But, they also want 1 specific customer named in that pattern.
- Problems, not solutions: Product managers like to be the ones who come up with the answer. Telling them what the problem the customer has and then a potential solution will get a lot better reception then "customer needs this feature". Product managers HATE that.
- Let them earn their keep: Going along with number 2, product managers like to be the ones who do the answer. They like to also do the work. So, having a specific customer, with a link to their quote in a Gong call (an Arkweaver partner) is better than just a quote.
- Numbers, numbers, numbers: Use numbers, the closer to revenue the better. Tie it to a business outcome.
Here is the optimal write-up: 7 customers paying us $15k MRR want to add licenses but can't because we don't support Spanish and all the licenses they want to add are Spanish.
The hard part is getting the evidence together
Most revenue leaders already have a decent feel for what customers want. As we covered above, you intuitively understand this, but how do you get it together?
How many accounts have mentioned this? Which segments? How much open pipeline is affected? Are existing customers asking for the same thing? What did those customers actually say? Has Product already shipped something that solves part of the problem?
Answering those questions manually is a pain in the ass. Not only is the data in different tools and phrases, it's across hundreds of reps and with things moving so fast, its really hard to keep up. It's not a 1 time dashboard, it's a continuous operating system.
This is where AI is actually useful
AI is good at the part humans hate doing.
It can go through thousands of customer conversations, find repeated product problems, group similar requests and pull the customer quotes behind them. It can connect those problems to accounts and opportunities, then show how much pipeline or ARR is attached.
That changes the quality of the conversation pretty quickly.
Instead of a CRO spending hours gathering examples before a product meeting, the evidence can already be organized by problem, account, segment and revenue impact.
If your customer conversations live in Gong, we put together five ways to turn Gong calls into product intelligence.
AI can also help separate the requested feature from the actual customer problem. Ten customers may ask for ten slightly different things that all point to the same underlying workflow issue. That is hard to spot when the information is spread across hundreds of calls. It is much easier when the conversations can be analyzed together.
None of this means AI should decide what goes on the roadmap.
Product still decides what to build (they like that). Revenue still decides which commercial problems matter most (you like that). The useful part is getting both sides to the same set of facts before the argument starts.
CROs are already part of the product process
This is already happening whether companies call it "product fluency" or not.
CROs are involved when a large deal is blocked. They get pulled into roadmap discussions when an important customer is unhappy. They weigh in when Sales says a competitor is winning because of a missing capability. They spend time explaining which requests are isolated and which ones keep showing up across the market. That part of the job is not going away.
The better question is how much time CROs should spend manually gathering the evidence for those conversations.
If Revenue can show Product the customer problem, the pattern behind it and the money attached, those meetings get a lot more useful. And when the product already exists, Revenue should also know exactly which prospects and customers were waiting for it.
Because a feature sitting in production while the rep who asked for it has no idea it shipped is a pretty stupid way to lose a deal.
And when customer demand stays buried in calls, notes and meetings, deals can die in the roadmap.