Thursday, roadmap committee. The Product Manager runs through the quarter's priorities, and you spot the feature a salesperson promised a prospect last month. The request three of your biggest accounts have been hammering on about for six months, however, is nowhere to be seen. You did pass it on: a ticket, two Slack messages, a line in a meeting summary. But on the Product side, it got lost among dozens of others, with no context and no business weight. That's how avoidable churn takes shape. Here's how to make the CSM Product's best ally!
There's nothing unusual about this scenario. In most B2B SaaS companies, Customer Success and Product want the same thing (customers who stay and grow) but don't speak the same language. The CSM feels like they're throwing messages in bottles out to sea. The PM, meanwhile, receives shopping lists that are impossible to prioritise: "the customer wants an export", "the customer wants a red button", without knowing who's asking, why, or what it's worth.
As long as the CS team fits in one room and the PM has lunch with them, corridor conversations make up for it. But once you have a dozen CSMs, several PMs and hundreds of accounts, informal exchanges don't scale. The quality of CSM/Product collaboration then depends less on the teams' goodwill than on the quality of the material CS brings to the table. That's the whole challenge: turning the voice of the customer into something Product can genuinely use.
Why Product struggles to hear the front line
Let's start with an uncomfortable truth. When Product wants to understand the market, it's often Sales it listens to first. That makes sense: they talk to customers all day and know the pitch inside out. But this source has two well-known biases.
The conquest bias
Sales feedback mostly comes from prospects and recent deals. Inevitably, features that help close deals jump ahead of features that help keep customers. The conquest bias puts potential customers ahead of those who pay for and use the product every day. Yet your NRR depends on your installed base.
The overselling bias
Ask any CSM what their main source of friction with Sales is. The answer is often the same: selling features that don't exist yet. The contract is signed, the customer expects their feature next month, the roadmap has it in two quarters' time... and it's the CSM who handles the disappointment. Involving CS in Product discussions alongside Sales helps rebalance promises before they become churn risks.
The product-certainty bias
Product has its own bias too, summed up by a line everyone has heard: "customers don't know what they want". That's often true of the solution, much less so of the problem. Pushed too far, this reflex leads to long, costly developments that nobody uses.
These three biases have one thing in common: they pull the roadmap away from those who fund it. The CSM is their natural counterweight, provided they don't just pass messages on. In Bob Mathers's "5-year customer" model, Product's job is precisely to prioritise customer feedback to deliver value. But that feedback still has to reach Product in a form it can prioritise.
Structuring how feedback is passed on
The first and most rewarding area to work on: how feedback travels from the customer to Product.
Report, don't interpret
The CSM is the voice of the customer, not their lawyer. Their role is to report what the customer said, as faithfully as possible, and above all the problem they're trying to solve. A customer asking for "a button to export to Excel" may simply need to share a monthly report with their management. If you pass on the solution they imagine, you close the door to a better answer; if you pass on their problem, you give the PM something to work with.
The right reflex: ask the customer "why?" before creating the card. Quite often, the answer already exists in the product. One less piece of feedback, one more customer unblocked.
What usable feedback looks like
Beyond the basics (customer name, date, CSM who raised it), usable feedback contains:
- the request, in the customer's own words;
- the problem to solve and the use case involved;
- the context: segment, account maturity, renewal date;
- the type: new feature, improvement, pain point, documentation (using tags);
- the level of urgency: churn risk, must-have or nice-to-have;
- the number of accounts affected and the business weight they represent.
Be careful with that last point. Asking a CSM to estimate by hand the MRR at stake for each piece of feedback is the surest way to make them stop passing it on. Business weight should be attached to the request automatically, not worked out on a calculator. More on this below.
Prioritise by impact, not by volume
A request mentioned fifty times isn't necessarily more important than one mentioned five times. Take a fictional example: forty small accounts are asking for a new export format, while four strategic accounts, which between them account for almost a fifth of MRR, are hitting a limit in the CRM integration. By volume, the export wins hands down. In business terms, it's a different game.
Sorting is all the more crucial because the funnel is narrow. According to an analysis by Harvestr of its B2B SaaS customers, only around 10% of feedback turns into features over a year. If the vast majority of requests will never see the light of day, the real question isn't "what are we being asked for?" but "what really matters?"
Close the loop
The last link, often forgotten: saying what happens to the request. Taken on board, planned for a given quarter, or turned down. A "no, we won't do it" is better than silence, because without a response, CSMs lose heart and Product loses its best source of information. That's the feedback "black box" you need to break open at all costs.
Bugs: the difference between the ticket that gets fixed and the one that gets forgotten
A bug is customer frustration in its purest form. And a badly written ticket means three rounds of back-and-forth with the tech team before anyone starts looking. Here, the CSM has a real filtering role.
Before creating the ticket, two reflexes. Reproduce the bug yourself: if you can't, the tech team probably won't manage it any faster. And tell a bug apart from an unusual request, because behaviour that doesn't match the customer's expectations isn't necessarily a malfunction.
A good bug ticket contains:
- the account and user affected, and the environment (browser, integration, version);
- numbered steps to reproduce;
- the expected result and the actual result;
- screenshots or a short video;
- the impact: number of users blocked, business process affected, any contractual deadline;
- the proposed severity level: blocking, annoying or cosmetic.
Then follow the ticket through to resolution so you can tell the customer yourself. It's often that final message that turns an incident into proof that you take things seriously.
The tech on-call contact
Everyone has interrupted a developer in the middle of deep work for an urgent customer question. And everyone knows it's costly. Hence the value of an on-call contact: a member of the tech team designated, for a set period (a week, a sprint), as CS's go-to person. They answer everyday technical questions, qualify the tickets raised and can join a customer call when the topic gets complex.
The benefits are immediate: fewer interruptions for the rest of the team, less frustration for CSMs, and developers who see customers' real problems first-hand. It's up to the tech team to set the scope and rotation.
Discovery: the CSM opens the doors, the PM runs the interview
You might think the CSM, who knows customers better than anyone, is best placed to run user interviews. They're not. Discovery requires a complete view of the product and the market, non-leading questioning techniques and a command of roadmap trade-offs. That's the PM's job. But they can't do it alone.
Choosing the right reference customers
In Inspired, Marty Cagan describes the kind of customers to involve in discovery: real customers (not friends of the team), who use the product in production, pay to use it and are willing to recommend it. He suggests aiming for around six reference customers, which means recruiting a few more to allow for drop-outs.
Yet PMs meet few customers. Choosing these accounts is the CSM's responsibility, and part of the roadmap depends on how well they choose. Avoid the trap of picking the chattiest or friendliest customer: look for accounts representative of your core target, with real usage and a relationship strong enough for them to agree to give up time for the exercise.
Go with the PM to see the customer
Don't leave the PM alone with the customer. Not to keep an eye on them, but so that everyone plays their part. The PM asks less leading questions and draws better conclusions, because they own the product vision. The CSM facilitates the meeting, puts everyone at ease, picks up weak signals and steers things back if the discussion drifts onto sensitive ground (a tense renewal, for example).
Job shadowing and "all hands" support
For the PM to really understand customers' day-to-day reality, nothing beats immersion. Half a day shadowing a CSM (onboarding, business review, a difficult call) is worth dozens of pages of user stories. It works the other way round too: a CSM who sits in on a backlog refinement session understands better why their request didn't make the cut.
You can go further with "all hands" support: having the whole company take turns on support, from Product and Tech to Sales and Marketing, right up to the CEO. Half a day every two weeks, for example. PMs hear pain points unfiltered, some outlandish requests are defused on the spot, and customers discover that the "back-office" teams really are listening.
Be careful, though, not to let support quality suffer. The support team remains in charge of the scheme, with training on how to handle customers, up-to-date template responses, solid documentation and support staff on hand as back-up.
Transparency: roadmap, release notes and shared rituals
Many tensions between CS and Product come from the same place: nobody really knows what the other team is doing.
A visible roadmap
On the Product side, the fear is understandable: showing a roadmap means committing to dates. The answer is simple. Share time horizons (this quarter, next quarter, later) rather than delivery dates, along with the overall vision behind the choices. Your CSMs don't need a day-by-day schedule; they need to know what to tell their customers.
You can also open a roadmap up to customers, where they can see what's in progress, submit ideas and vote. That's the choice made at Skalin: a semi-public roadmap, accessible from within the platform, with three to six months of visibility. This kind of set-up naturally feeds a customer community focused on product co-creation. But it demands discipline: if items slip from one quarter to the next every time, trust collapses.
Release notes that help the front line
On the Product side, make release notes systematic for every release: a Slack message, an email, a few slides, ideally with a demo. To make them genuinely useful for CS, add two pieces of information that are almost always missing: what the new feature concretely changes for the customer, and which accounts asked for it. The CSM can then close the loop with each of them, and that's often when a piece of feedback turns into a renewal.
The teams also need to know how to present what's new. That's why it pays to train teams on product updates with guides and practical examples, rather than letting everyone discover the feature at the same time as the customer.
Transparency works both ways. On the CS side, share your figures too: churn reasons, usage trends, onboardings in progress, at-risk accounts, and customer feedback, both positive and negative.
Shared rituals
A few regular meetings are enough, as long as you stick to them:
- a monthly feedback committee, where CS and Product review consolidated requests and their business weight;
- CSMs attending sprint reviews, which often include a demo of upcoming changes;
- pre-production testing open to CSMs, who quickly spot what will cause problems for customers;
- a quarterly roadmap review with CS and Sales, one bringing the usage view, the other the market view;
- knowledge-sharing sessions (lunch and learns, coffee chats) so everyone understands the other team's goals and constraints.
The aim isn't for CS to do Product's job. It's for every roadmap decision to be informed by what the front line knows.
Who does what: a Product/Customer Success RACI
To avoid grey areas, formalise responsibilities. Here's an example RACI to adapt to your organisation:
| Activity | Customer Success | Product |
|---|---|---|
| Collecting and qualifying customer feedback | R, A | I |
| Consolidating requests and their business weight (MRR) | R, A | C |
| Prioritising and deciding on the roadmap | C | R, A |
| Communicating the roadmap to customers | R | A |
| Selecting reference customers | R, A | C |
| Running discovery interviews | C | R, A |
| Reproducing and qualifying bugs | R, A | I |
| Prioritising fixes | C | R, A |
| Writing release notes | C | R, A |
| Announcing new features to customers who requested them | R, A | C |
| Updating product documentation | C | R, A |
| Measuring adoption after a release | R | A |
R: responsible · A: accountable (decides) · C: consulted · I: informed
Skalin Insights: the voice of the customer, quantified and readable by Product
Everything above rests on one assumption: that someone consolidates hundreds of customer conversations to spot trends. In practice, that's where the system breaks down. Emails, tickets, meeting summaries and notes pile up, each CSM sees their own portfolio, and nobody has the full picture. The feedback committee ends up debating impressions.
That's exactly the role of Insights in Skalin. Where the health score works account by account, Insights reads your entire customer base and surfaces the signals that converge. Each topic is categorised by theme, with the number of occurrences, the customers involved and the percentage of MRR they represent. In practice, the CSM goes into the meeting with Product armed with:
- the most frequent feature requests, with the associated MRR, to prioritise by business impact rather than noise;
- recurring product pain points, the ones that crop up across several accounts without ever becoming a ticket;
- documentation gaps flagged by customers, which are often quick wins rather than development work;
- feedback collected after a new feature is announced, to check it really meets the original need.
You can also query Insights in natural language: what are the main reasons for churn, which features are most eagerly awaited. And to drill down to an individual account, feedback stays centralised in the customer view, alongside sentiment analysis of conversations and usage data. That lets you measure, after a release, whether the change really moved usage and the health score of the accounts that were waiting for it.
One point makes a big difference to collaboration. On Skalin, read-only licences are unlimited: you can invite the whole Product team at no extra cost, and every PM can look at Insights directly. No more exporting, building a monthly deck or acting as the go-between. The feedback committee starts from shared data, and the discussion can finally focus on the trade-offs.
Let's be clear about who does what: AI surfaces and summarises, it doesn't decide for you. The CSM brings the context, the PM decides on the roadmap. And that's exactly as it should be.
Conclusion
Getting CSMs and Product to work together isn't a matter of getting along. It's a matter of material and method: feedback that describes a problem rather than a solution, a business weight attached to every request, qualified bugs, well-chosen reference customers, a roadmap and release notes that circulate, and clear roles.
If you remember one thing: the CSM isn't a letterbox between the customer and Product; they're the ones who turn the voice of the customer into material for decision-making. The day your PM turns up at the roadmap committee with the same figures as you, you'll know you've won!
Further reading
