If you work directly with customers, then you know exactly what they need to succeed with your product because you’ve heard it straight from them. You’ve spent countless hours interacting with them, celebrating their triumphs, and seeing them through their struggles.

But sometimes, it can feel like no one recognizes your knowledge. No one asks for your take on how to improve the product, even though you’ve got a direct line to your customer base and tons of ideas about how things could be better.

Sometimes it can feel a little like you’re that Sisyphus character from Greek myth  —  the one who had to keep rolling a boulder up hill all day every day, only to have it roll back down. Just plugging away, listening to the same complaints and walking customers through the same issues as you did yesterday, and the day before that, and the day before that.

You might think that this is part of the job, and that a customer’s product experience is outside of your control. This kind of thinking is a fast track to burnout. In customer support, few things are worse than facing legions of aggravated customers day in and day out, making apologies for things you had no hand in doing. Not only that, but when customer-facing teams are silent, then valuable customer feedback is lost.

So, the best customer support teams don’t just keep on, continually providing the same answers and making the same apologies, pushing the boulder up the hill again, and again, and again. They work with their product teams to give them the customer insight they need to make valuable product improvements. 

The truth is, you can and should enact change. Your job isn’t just about answering emails and making phone calls. It’s about bringing your expertise to the table, representing the customer voice, and working cross-functionally to improve the customer experience.

I know what you’re thinking. “Easier said than done. My product team doesn’t listen, and they don’t really care about our customers…”

While they might not be listening, it’s highly unlikely that it’s because they don’t care. It’s much more likely that you and your product team just aren’t speaking the same language. (And spoiler alert: That language is data.)

Treat Your Product Team Like a Customer

There are many types of customers, all with their own preferences, and many ways to try to classify customers into different types. 

Generally speaking, product teams can be classified as analytical types. Analytical customers want to work with facts, operate through defined processes, and make decisions based on data. To a product team, anecdotal and off the cuff feedback seem subjective and unorganized. And product managers, like you, are busy and constrained, under pressure to keep moving the product forward by devoting work to only the fixes and features that will have the most impact.

The bottom line: Your product managers do want customers to be happy; to convert faster, engage more often, and stick around longer. To that end, they want your insights about customers. They just need those insights to come in the right package  —  one that’s wrapped in data and delivered through a routine process. Thinking of your product team’s needs the same way you would a customer’s will help you build the most friendly and productive relationship.

Let the data drive your discussion

Because of their analytical orientation, product managers need to see numbers to bring problems into focus.

The easiest way to start speaking with data: Categorize and label all the contacts you have with your customers so you can pull reports on overall contact volume by topic, feature, product, or whatever else you want to track.

Being able to tell your team that you’ve seen 1,000 customer contacts about a new screen in the onboarding process, for example, and that your contact volume in that area has increased by 50% this month is far more effective than just telling them what you know from experience: that customers are having trouble with that screen.

Your ticketing and phone systems should have features that will allow your team to tag conversations as they have them. High-level categories like “Onboarding” or “Billing” are great for painting in broad strokes, and you can add sub categories like “Onboarding — Email Entry Bug” to get more granular. 

Through tagging, you can clearly point out which features and areas are creating the most inquiries. You can show week-over-week and month-over-month differences that add context to that volume. And you can lay out exactly what measurable results you expect to see from fixes.

These kinds of concrete details are exactly what it takes to get through to a product team. You can even go a step further to show your product team how much a problem is costing and how much could be saved over time. The most basic way to do this is to calculate the number of inquiries you’ve handled in the past month and multiply it by your cost per inquiry.

Once the problem is fixed, you and your product team can take credit for those cost savings. Boom! You’ve struck product team gold.

Start with a data driven process

A tagging system like this is not a “set it and forget it” type of thing. Before unleashing your team on tags, you need a process. Letting your team loose on tagging without a system, documentation, or any consistency is a recipe for disaster because you need the data in a format that is easy to cut and compare, so someone should first define your tags and how they should be used.

Your system will also need consistent maintenance and adjustment.

- Has a new bug popped up in your platform? You’ll need a new tag.

- Noticing a trend around confusion with the new sign up process? It needs a new tag.

Your team needs to know about these new tags and how to apply them, and new team members will need to be trained on common usage. But, these extra efforts are worth the payoff when you can use the results to influence product, improve the customer experience, and finally stop hearing about the same issue customers have been raising for months.

Also, bear in mind that just because an issue is the most popular, doesn’t mean it’s the most important. There are other dimensions you should be looking at to guide prioritization. These will vary depending on your business and your overall philosophy, but you could consider:

- Urgency: Is there a workaround? Is this a major blocker to using the core product? Are customers cancelling? How badly the issue interrupts the experience can inform its rank on the list of things to fix.

‍- Sentiment and sensitivity: Is this something like a typo on the site that customers don’t really care about but are simply pointing out? Or is it something so irritating that it makes them angry? Aside from your gut instincts here, you can track sentiment with special tags or bring in your CSAT data to connect how customers feel about an issue and size it up.

- First contact resolution rate and resolve times: Do these inquiries require a ton of back-and-forth and drag out forever? If so, they’re likely costing you more and causing more friction for customers, which will affect their relative prioritization.

‍- Customer type: Who is running into the issue? A bug that’s affecting a few high-value customers might be more important to you than one that’s impacting a larger number of free users.

Solid as a rock

While sharing numbers alone is a great first step, to take it to the next level, you need visualizations. A quirky old boss of mine once used the analogy that if a graph was a tool, then it’d be a rock. Sounds weird, right? It definitely did to me, but as he explained more, it started to make a lot of sense.

A rock is pretty much the most basic version of a tool. It doesn’t take any special training to understand or operate, it can take a few different forms, and it has tons of different uses. The same goes for visualizations. You could probably show a churn chart to someone who has never worked on churn before, and they’d be able to read it. The raw numbers in an Excel array? Maybe not so much.

Visualizations are the great data equalizer  —  making complex information much more accessible to even the most data-phobic among us and much more clear and concise to those are well-versed in it. To show a trend over time, you might use a line graph. To show parts of a whole, you might use a stacked bar chart. To compare a few items with each other, you might use a column graph.

There are lots of types of visualizations that can help you succinctly summarize key takeaways. The bottom line is that visualizations allow you to present your data in a way that makes it instantly readable and easy to understand, for product teams and for anyone.

Delivering your data driven insight

Once you have your data, the next step is getting it to your product team. Aside from an emergency situation, presenting your insights in a regularly scheduled and consistently packaged way is a sure-fire way to woo your product team’s process-loving hearts. Whatever method of communication (written or spoken; asynchronously or real time) and cadence (daily, weekly, monthly) you choose, keep it consistent. Having a routine helps your product team feel their time is respected, and it establishes a routine that trains them to anticipate hearing from you.

If you add positive feedback to the mix, they’ll even come to look forward to it. Celebrate wins and share what customers are happy about to balance out your critical feedback and give your product team something that everyone wants to hear: what they’re doing right. While you’re at it, ask your product team what you can do to help them. What do they want to know and how can you help them track it?

It goes back to treating them like a customer. When you can add value to their cause, working with you is welcome. And once your product team sees what you can contribute, they’ll start to include you in every stage of their work, from planning through launch and beyond. At that point, you can anticipate issues before they even arise and nip them in the bud.

That’s better than fixing issues after the fact. It’s better than finally getting that boulder to the top of the hill. It means having no boulder to roll at all, leaving you to focus on what you do best: connecting with customers and helping them reach their goals.