Partnering With Product to Best Represent Your Customers

The following is an excerpt from How to Actually Influence the Product Roadmap, a new handbook that gives a blueprint for Customer Success leaders to build a better partnership with Product. You can get your copy here. 

Given what we know about the process of creating a product roadmap, what can Customer Success do to actually influence the roadmap? The simple answer is this: turn Product into a raving fan. Make Product’s life easier, and they’ll naturally start to rely on you as a trusted partner. 

Here’s how:

1. Avoid the common mistakes CS leaders make when partnering with Product
2. Dig into customer problems
3. Aggregate and quantify problem themes

This may seem like an oversimplified magic wand. It’s not. It’s an actual plan you can implement to change the influence CS has with the Product org.

Avoid common mistakes Customer Success teams make

In our interviews for this handbook, we asked Product leaders “what’s one thing you want CS leaders to take away from this?” Nearly all of them pointed to one of these four common behaviors, and asked CS leaders to stop doing them:  

• Sharing “important” customer requests with Product as they come in
• Summarizing customer feedback in your own words
• Proposing potential solutions to “make it easier” on Product
• Going around Product, directly to engineering, to solve “urgent” issues

If you’re doing any of these, stop. Yesterday. Your goal is to turn Customer Success into an asset for Product, and the behaviors above do the exact opposite. Let’s take them one by one.

*An important nuance about this list of mistakes:
A CS leader is more likely to make some (or all) of the above mistakes when it comes to the 800-pound-gorilla customer that’s coming up on renewal. Suggestions: 

• Be honest that not all customers are treated equally. The VIP customers have outsized influence and it's important to plan for that reality.
• Make sure your team knows that CS + Product have predetermined which accounts are the most valuable to avoid all CSMs believing that their accounts are the most important.
• When a large renewal is at risk, have the necessary data (renewal date, renewal $, risk level) to justify a commitment from Product on roadmap functionality. 

Mistake #1: Sharing “important” customer requests with Product as they come in
As soon as a customer reaches out with an ask, the urge is to report that immediately to Product. It feels good to help a customer right away, but it’s actually counterproductive. Product is looking for problem themes across the business. One-off customer requests almost always get lost in the ether (backlog) because Product tends to avoid solving problems because they’re “on fire” or they’re an edge case. 

Mistake #2: Summarizing customer feedback in your own words without also providing the VOC source
The hard truth is that Product doesn’t trust customer requests that have been filtered through a CSM. Product Managers are better trained to read between the lines (sometimes by going and talking to the customer themselves) to discover the customer’s true problem. As a result, filtered requests are generally written off as “not enough info” unless CS is also giving Product access to quickly dive into the source information. 

Mistake #3: Proposing potential solutions to “make it easier” on Product
Imagine Product coming to you with tweaks to your customers’ success plans. Totally unhelpful. That’s how it feels when CS proposes potential product solutions to customer requests. Every change made to the product requires 2-3X the planning that you’d expect, and affects many areas of the platform that Customer Success isn’t tracking. (Non-Product people often don’t realize what all goes into solutionizing. They also may not realize that the tight collaboration between Product, Design, and Engineering gives that group the ability to deeply understand the business goals, technology trends, and usability patterns.) 

When CS comes to Product with solutions, it requires Product to do all the problem discovery themselves, which they don’t have the bandwidth to do. 

Mistake #4: Going directly to engineering to solve “urgent” issues
This is an absolute non-starter for a few reasons:

1. The only issues that are actually urgent are bugs that prevent customers from using important features in the product. These kinds of bugs often have implications across the platform, which specific engineers don’t know about. If you keep Product out of the loop, there’s a chance the engineer you have a relationship with won’t solve the issue well. They may also unknowingly create bugs that are even more serious. 

2. When you ask Engineering to do something “urgent” they have to deprioritize other work. That other work may have a much bigger impact on company goals than the issue of an individual customer. 

3. And you lose all credibility with the Product team when you cut them out of the process  (unless you’ve agreed on the workflow ahead of time). Once you break trust, it’s hard to earn it back.

Dig into customer problems

Customer Success has exactly what Product needs: constant access to product feedback. But often, CS teams waste those customer interactions by not digging deeper into customer problems. 

In order to (a) uncover problem themes that'll have an impact on the business and (b) get sufficient data for Product to create a solution, CS needs to:

• Provide CSMs with user research training
• Get actual quotes, audio, and video recordings from customers

This isn’t the typical “keep bugging them” advice. CS really needs to rethink the role it plays in the process of researching, understanding, and prioritizing product themes, and skill up in areas it’s sorely lacking.

Provide CSMs with user research training
User research is the cornerstone of any great Product org, and software company. It requires you to ask the right questions of a user or customer to understand what they need, even if they don’t know how to explain it. 

“Customer Success teams need to take the same approach as user research teams.”
— Andrew Litvak, Senior Product Manager at Shopmonkey

There are many UX research trainings on the market, and most of them boil down to asking these 5 basic questions:

• Job - what are you trying to get done?
• Importance - how important is this for you? Why?
• Frequency - how often do you need to do this in a given month?
• Blockers - what’s preventing you from doing it?
• Alternatives - what workarounds are you using today?

CSMs should ask these questions any time customers express frustration with the product, point out bugs, ask for new features, or simply say they’re using it less. 

More often than not, what a customer says is different than what they actually need to be successful. These questions will help your CS teams uncover underlying problems for Product to solve. 

General Assembly offers an online Intro to User Research course which we recommend for Customer Success teams that want to learn more.

Get actual quotes, audio, and video recordings from customers
The more context Customer Success can share with Product, the better they’ll be able to understand and solve customer problems. Ideally CS teams would record every customer interaction they have in a tool like Gong, Grain.co, or Fathom.Video, annotating each video to bookmark answers to the Job, Importance, Frequency, Blockers, and Alternatives questions above. If you’re not ready to implement a new tool, providing word-for-word customer quotes in response to those questions is a decent backup option.

Aggregate and quantify problem themes

Once your team starts asking customers the right user research questions, you’re going to amass a treasure trove of customer data. So much so that Product won’t have enough time to review it all. Catch 22!

CS needs to start by syncing with Product to agree on some proposed high-level problem themes. Then, CS needs to do the legwork of summarizing problem themes for Product and quantifying the value of each problem theme to the business. This includes:

• Severity - when this problem comes up, how painful is it for customers?
• Frequency - how often is this pain felt in a normal month?
• Reach - how many customers does this problem affect?
• Risk - what $ will churn each quarter if this problem isn’t solved?

Then, taking it one step further, Customer Success can identify which of these themes align to current quarterly goals before bringing them to Product. 

This is the holy grail for Product teams—especially when Product can double click on each problem theme to see detailed user research questions, quotes, and videos that provide context for how the problem affects individual customer accounts. (And specifically, “who” the problem affects, so Product can see whether the feedback is coming from people who the feature wasn’t built for.)
Once you’re able to deliver this data to Product, your influence on the product roadmap will skyrocket.

If you enjoyed this chapter, read the full handbook on How to Actually Influence the Product Roadmap.