“Bueller?… Bueller?… Bueller?”
If you’ve ever submitted product feedback through a customer support widget like Intercom or Zendesk, you know how much of a lost, black hole it can feel like.
Yet, for many companies, that’s exactly where product feedback goes, never to be seen or heard from again.
It’s not Customer Success’s fault.
Customer support and success have important jobs. They’re helping fix problems, educate customers, clear up confusion, and catch bugs.
But triaging problems and being patient with frustrated customers is a totally different skill set than understanding customer needs and making product decisions.
It’s no surprise then that the feedback CS does receive often gets lost in the shuffle, dumped in a backlog somewhere, or filed away, never to be seen again.
What else are they supposed to do?
Let’s take a closer look at these misaligned incentives and responsibilities, and why they leave customers feeling unheard and product teams missing out on priceless customer feedback and connections.
Why CS is the wrong channel for customer feedback (and what to do about it)
Every person in your company who directly interfaces with customers is a powerful source of feedback and insight. That definitely includes CS.
Yet, just because someone interacts with customers doesn’t mean that they have the skills to help you make the right product decisions.
Here’s a few of the challenges with turning what CS receives into something valuable and actionable for product teams:
1) Feedback from CS lacks depth and an understanding of the root cause
Regardless of the source, most product feedback initially lacks sufficient detail to be actionable.
Whether it’s a feature request, a bug, or general feedback / frustration, you usually need to probe a bit deeper to really understand what your customers truly want.
To CSV, or not to CSV…
Early in my career, I frequently heard requests for CSV exports for our analytics reports at KISSmetrics. The easy thing to do would have been to just build a CSV button on every page that allows you to download the raw numbers behind every chart and table in our product.
And doing that would have missed so much, and rarely given customers what they really needed.
Because when I dug into why customers were requesting CSV exports, it turned out what they really wanted were things like:
- Peace of mind that they could get their data out after a trial or being a customer for a long time. (Which a .json file and API access was a much better solution for, in addition to the later emergence of tools like Segment)
- Reporting in different formats, ranges, and segmentation than we then offered. (Better to build those reports, including a catch-all “Power Report” we could charge more for, than a CSV dump.)
- A daily email of their most important metrics they could monitor and occasionally forward to their boss and other team members.
Yet, I only learned those things because I took CSV export requests and asked followup questions to go deeper. Whether it was through a back-and-forth email discussion, or a customer interview, it was only after asking those additional questions that I found out what they were really trying to do. Then, we were able to design the best solution, which was rarely what they had initially asked for.
It’s not reasonable to expect your CS team to do this.
The truth is, even if you had the time to do it, it would be unreasonable to train all of your CS reps to do this kind of follow up and question asking. Here’s just a few reasons why:
- Misaligned incentives: CS is often measured on the speed, quality, and quantity of tickets they close. While a PM will happily ask just one more question to get more insight, CS is incentivized (rightfully) to resolve tickets quickly.
- Different personality and work styles: The skills to make customers feel heard, accept their frustrations, and politely resolve their issues quickly are very different from the ones needed to pry into the real motivations and needs behind a request or bit of feature feedback. You’re running into both a skills gap, and a motivation gap; the people who want to ask product-style questions aren’t likely to be great CS reps (or they’ll want to transfer to your product org very soon!).
- Getting to the root cause is just the beginning: Even if you could train your CS reps to do this kind of followup, you’d also then need to start to train them on how to organize, report on, and make it actionable at scale. That’s firmly a product manager’s job, which you don’t want to end up having to train your CS team to do as well.
When you have a firm number of tickets you have to resolve each week, the last thing you want to do is be trying to figure out how to get more feedback from a customer on an open ticket that isn’t really even a problem. It runs counter to all of their other instincts and training.
2) Customers aren’t expecting CS to be a feedback mechanism
When you contact customer support, most people expect it’s to get questions answered, fix bugs, or help resolve an issue. The first thing on your mind isn’t, “This is the perfect place to send in that great product idea I have!” nor is it, “This will totally help the product team make the product more valuable to me.”
Yet, when there’s no other option, some people will try to submit it there despite feeling like it’s probably a lost cause.
Finding signal in the noise
When you’re processing hundreds of tickets a week (or more!), it’s very hard to also be thinking about product problems. It should be no surprise then that if you sit down with your support team, they’re going to have a hard time reporting to you what they heard customers ask for.
Instead, you’re likely to deal with a few issues:
- Recency bias: They’ll more likely remember the last few support tickets they received that included product feedback than a comprehensive breakdown of the last quarter’s customer requests.
- Lack of recall: When you have to triage constantly and resolve issues rapidly, you train your brain to not remember things for long. As soon as a ticket is resolved, you move onto the next issue, dumping whatever you were just thinking about. That’s great for resolution rate, but not good for remembering the product feedback tickets you quickly closed.
- Squeaky wheels: If CS hears the same thing from a few loud customers over and over, there’s no guarantee they’ll recognize that it’s actually a vocal minority, and not a broader issue.
Yes, with the advancements in AI, it could help address some of these issues, by picking out the product feedback better and faster than a busy CS team member or manager could. However, that AI would still be a victim of the circumstances created by CS gathering the customer feedback.
A narrow (or closed) door?
While some people will still try to share their product feedback with CS, it’s a much smaller proportion of users than if you have a dedicated way for them to give your product team feedback.
This happens for a few reasons:
- Lack of trust: When customers don’t feel like anyone really listened to their feedback, they’re not going to speak up again. Yet, that’s exactly how it feels if your first message CS sends is a simple, “Thanks! We saved this to share with our product team later,” and a closed ticket.
- Out of sight, out of mind: When you prompt people directly, or give them a clear mechanism to share product feedback in, they’re much more likely to share feedback with you. Yes, a few people might go all the way to your support docs or a “Contact Us” form to send it in, but that happens much less frequently than if they’re prompted while using your product.
- No positive loops: The real power of product feedback happens when your customers experience a virtuous cycle; when they submit feedback, feel heard and understood, then see that their feedback was acted on, they will want to go out of their way to give your more feedback. Yet, CS is never going to be able to deliver on that loop. It falls firmly on product to build that loop.
If your product team relies on the collection of partial thoughts and feature requests from your CS team, you’re missing out on so much potential.
3) The wrong tool for the job
Even if you had the perfect CS team that somehow knew how to do root cause analysis and ask great follow up questions, they’re still using a tool built for them, not product people.
The fact is, every product you use is built to solve the problem of a specific type of users. And support tools are built to help CS teams crank through tickets, resolve issues, and measure the success of each reps’ efforts.
Unfortunately, none of that helps a product team get what they need, because it was never built for them. Product isn’t typically part of the decision making process for buying a CS tool, nor should they be. It’s a different department for a reason.
However, because of this, product feedback never reaches its full potential. It doesn’t help your product team make better decisions, and misses out on connecting with passionate, interested customers for a variety of reasons:
- No easy way out: There is no obvious path to take the customer feedback from CS and get it in the hands of the right product leaders.
- No deeper understanding: Since CS isn’t trained on how to followup and is incentivized to close tickets quickly, all the feedback you would get out lacks depth and clear understanding of the root cause of their request.
- No filters: Even if you can get a dump of messages into a CSV, a database, or a bloated Jira backlog, it’s not curated nor organized in a way that allows you to know which is most important to listen to, or what’s actually just noise from a non-ICP, freemium, or other low value user.
Is it any surprise then that all this customer feedback goes to waste and most people think it’s pointless to send it in at all?
Customer feedback shouldn’t feel like a lost cause.
Too many companies make sending in feedback feel like a paper shredder suggestion box.
Think about the products you use every day that are most frustrating. I bet there is a direct correlation between how hard it is to send them feedback and how poorly designed and annoying the product is to use.
The same can often also be said for companies that ask for a lot of feedback, but never do anything to signal they actually listened or cared what you said. Lip service changes very little.
The good news is, you don’t have to be that kind of company.
You don’t have to make sending in feedback to your team a trial of Hercules, nor a game of telephone passing between many teams and stakeholders.
Instead, you simply need to create the vehicles to receive quality, actionable feedback.
You can do that through things like:
- Running NPS and P/M fit surveys
- Installing a dedicated feedback system or tool
- Creating a dedicated product feedback email address, customer Slack channel, or other mechanism other teams can refer customers to and is run by your product department
- Creating a customer advisory board or encouraging all of your PMs to build relationships with relevant customers
- You and your product team actually following up and responding to customer feedback when it is passed to you
And while all of this does represent an investment of time, effort, and often money by your product team, the payoff is huge: When customers feel heard, they churn less often, become evangelists for your company, and most importantly, they help you build new features and improve your product in the ways that lead to break away growth and market wins.
Want to improve how you and your product team source, understand, and make the most of customer feedback?
With my new startup, Product Arrow, I’m working hand in hand with a few select companies and product teams to develop software and AI that solves problems just like these.
If you’re the kind of leader eager to get hands on help, and wants a solution built to perfectly fit your team’s needs and workflows. Get in touch (jason at productarrow dot com), or you can sign up for a call to discuss your needs here.