One thing that keeps surprising me in my conversations with customer success leaders and practitioners is how little access they have to product usage data. In 2025, that still feels wild to say out loud.
Most CS teams I talk to don’t use product analytics tools directly. Not because they don’t want to, but because those tools were never really set up for them in the first place.
In many cases, they don’t even know what tool their product or engineering team uses. Is it Mixpanel? Amplitude? Heap? They’re not sure. Sometimes they get a shared dashboard link or an occasional export dropped into a Slack channel. That’s the extent of it.
And when they do get access to the data, it’s often surface-level. Logins. Session counts. Maybe a few charts about feature clicks. It’s data, yes, but it’s not insight.
It rarely answers the questions CS teams are actually trying to ask:
-
What’s changed about this specific account’s behavior in the last 30 days?
-
Who is struggling silently after onboarding?
-
Which customers are using the features that correlate with retention?
-
Which accounts show signs of readiness for expansion?
Instead, what they get is generalized behavior across all users. It’s too shallow to act on, and too generic to help with the deeply relational work CS is doing every day.
This disconnect made me realize something. Product analytics, the way it’s currently designed, doesn’t serve CS teams. It’s built for product managers and data analysts. It’s optimized for feature adoption studies, A/B test results, and growth funnels. Those are important use cases. But they are very different from what CS teams need.
CS lives in the context of the account, the customer relationship, and the business outcome. They need to know why an account is stalling, who is seeing value, and what action to take next. Product analytics tools were not built for that kind of question. And the truth is, most teams are still trying to retrofit tools like Pendo, Amplitude, or Looker to answer CS questions they were never designed for.
This might also explain why so many CS professionals feel like they are flying blind, even in companies that are considered data rich. It’s not that there isn’t data. It’s that the data isn’t accessible in the right format, or at the right time, or shaped in a way that’s useful for their work.
And it’s not just a tooling problem. It’s a gap in how we think about visibility, trust, and collaboration between product and CS teams.
Here’s what I’ve seen help:
-
Giving CS teams scoped access to product analytics with pre-built account-level views
-
Creating auto-generated insights and nudges based on customer behavior, not just raw data
-
Moving away from static dashboards to more contextual, event-based intelligence
-
Aligning on shared metrics that matter to both CS and product, like time to first value or expansion signals
The best CS teams are deeply curious about how their customers are actually experiencing the product. But curiosity alone is not enough. We need to meet them with tools and data structures that support their workflow, not force them to translate metrics built for someone else.
Because if the people closest to the customer don’t have the context they need, then how can we expect them to drive outcomes?
It’s time we stopped treating CS visibility as an afterthought. Product data should not just be for product teams. It should be a shared asset. One that’s shaped for action, not just observation.
