How do we empathize, prioritize and communicate customer feedback?

Chris Bialecki

What are the most effective frameworks and tools you use to prioritize and communicate customer feedback to your product team? This can include feature requests, bug reports and/or any other type of customer feedback. 

Jared Scoubes

We use our office communication tool - SLACK - to enter customer requests and report issues into our "Bugs" channel. It gets good visibility to everyone who touches product but due to the quantity of messages (responses, answers to questions, or other) things tend to get lost a bit -- or at the very least, don't seem to be tracked as efficiently. (I'm assuming the admin for that channel maintains some sort of spreadsheet but I really don't know for sure). I've petitioned for some time that we need to have a meeting with key people from several different departments to discuss how to better organize ourselves - specifically regarding customer feedback/requests so our dev. team can include those ideas that are most requested in their next sprint. Great discussion point - I'm excited to hear other's ideas/successes regarding this!!

Lauren Culbertson

I've got a ton of thoughts on this, but here are the most simple / helpful tips I would recommend:

1. Organize and prioritize your channels of feedback across the CX - this means pre-sale too... NPS Surveys, Online Reviews, Sales Win/Loss Notes should all be fair game. This will broaden your case for why the feedback needs to be acted on AND make it feel less like the requests are coming from a Customer Success Silo. 
2. Pull out the common themes coming from positive AND negative feedback. If a customer is complaining about something a lot, but raving about it more, it might not be where you focus your time. Focus on where you are seeing high volumes of negative feedback, OR where feedback has become dramatically MORE negative in a certain time period.
3. Quantify the frequency of the issue (# of times it came up in X time period) and the IMPACT (how many $ were lost from new sales, churn because of this). 
4. Recommend actions that could fix the issue but encourage debate on what should be done. The important thing is that you are aligning your product managers (and other cross-functional stakeholders) on one understanding of what your customer needs or struggles with. From there, you should collaborate and have healthy debate on the actions you take.
5. When you decide  what actions to take, get buy in on timing and follow up on it. The companies that do this well are discussing in weekly leadership meetings. Accountability is everything when it comes to VoC because nothing encourages customers to GIVE feedback more than them seeing you ACT on it. 

Also including a link to a template you can feel free to use if helpful!

https://docs.google.com/presentation/d/1Y9qiAbrSqoyGnwrEu2Y-B55sSCSZR5mAW9-0ef1FyBk/edit

 

 

 

Jay Nathan

+1 nice answer @Lauren Culbertson, and great to see you here

Silvia Yancheva

At my company we use a combination of 3 channels for reporting and sharing feedback:

• Bugs communication is usually done through Slack and Trello boards. Their priority is then reviewed and taken by our Product team, and the resolutions scheduled for an upcoming bug-bash or fixed on the spot, depending on their severity  
• Feature requests are also reported in Trello but discussed IRL afterwards as well, during regular CS <> Product meetings
• We also have a public online forum (Canny) for users to put requests directly to our UX team 

When it comes to prioritising new feature requests:

The decisions are made based on CSM prioritisation and recommendations, and are afterwards mapped to the company-wide roadmap or put into consideration for the upcoming sprints (or put on hold, of course) . Feedback and requests are flowing from the other parts of the organisation as well though (Product itself, Marketing, UX, Catalyst, etc.) so we try to keep the prioritisation process for the improvements as inclusive as possible. This at least allows us to quantify our feedback properly first, as well as come up with suggestions for improvements. Some of those requests might require months of UX research and technical investigation, so preparation/clear communication is the key for us.  

Petra Makaremi

Greta points! +1 to Slack (or Trello etc) and unique channels for each area like bugs reporting, feature requests etc. It's critical to assign someone to be accountable for those as the sheer volume can mean important feedback gets lost. Ideally this would be a joint process between the CS and Product teams - Product to prioritize the work based on CS feedback, and CS to communicate solutions and timelines to customers.

In my previous company (a younger startup) we had me as head of CS join all Product roadmap meetings down to backlog grooming & sprint planning meetings to bring prioritized feature requests and product issues, to be the voice of customer/business. I would have a weekly conversation with the Support and CS teams beforehand to collect feedback and prioritize internally. 

Slack served as a depository of ideas in between that was open companywide for visibility, also great for more urgent requests like bugs that may need much quicker resolution than a (bi)weekly cadence of meetings could serve. We also trained our Support team to report bugs via Jira tickets that our Product team could then take forward - CS prioritization was again key otherwise tickets can get lost in the backlog "black hole." 

 

Willow Moellering

I agree with everything above, including one huge item: REPORTING!  The system that works for your team is often the best for everyone; rather than introducing a new process, but make sure you can report on those items.  Here are key reporting details you need on bugs/features: 

• # of customers requested/reported the items (including the customers linked)
• Date of original report 
• Area of product
• Feature request vs bug vs design enhancement
• Date of resolution 
• Type of resolution (ie hot fix vs major release)

Reporting will enable you to take a high level look at issues monthly.  You will be able to see if specific areas have more requests/issues.  As Customer Success, the reporting above will enable to you see a product view specifically from your customer's eye before EBRs.

Jared Scoubes

LOVE this @Lauren Culbertson! Thanks for sharing!

Lauren Culbertson

????????

Will Gilmore

We recently shifted a lot of our documentation over to Notion, and it was fairly easy to make a lightweight feature request board where you could keep track of different requests, list out how many (or even which) customers are requesting something, etc.

Can have multiple views depending on whats helpful (lists, kanban, etc). Notion does a lot of cool things.

So far it has been a helpful spot for our team to drop and prioritize requests. Eventually we plan on moving to productboard so we can easily integrate with some of our other tools (intercom, Zendesk, etc), but until then Notion has been a nice bridge!

Steve Bernstein

I'm not sure you need "more" surveys and feedback listening posts, and instead might focus on how you are communicating what you hear with the good reporting/analysis. For example, do you link financials and sentiment (don't forget those silent, non-responders that are telling you something by being disengaged!) to show revenue at risk and upside potential?  Does your root-cause process articulate why a customer perceives a gap (i.e. what their expectations are and why, compared to what they experience)?  Can you statistically show which areas of improvement are most likely to move-the-needle (improve) or are you just focusing on the loudest voices?  

"Anyone" can run a survey. Asking the right questions of the right people at the right time -- with clear/insightful analysis and follow-up -- is where it gets more involved but doesn't have to be difficult; just needs the right tool for the job.