Issue #74: 4 Mistakes CS Leaders Make When Working with Product

Success Happy Hour is a weekly newsletter for Customer Success leaders. Each week we feature one digestible piece of advice or a framework from a top Success leader, along with the best resources from that week. Subscribe here.

The strength of the relationship between an organization's Customer Success team and Product team can have massive repercussions on the customer experience and ultimately, the success of the customer. If this partnership is broken, you can bet that the dysfunction will be felt by the customer as well. 

The problem is, Product is juggling needs from all over the business and customer requests are only one slice of that story. Product takes requests from:

Because Product teams are collecting, organizing, and planning projects that serve different business goals, it’s on CS leaders to improve this partnership if they want the right requests to be prioritized. But many CS leaders don’t know where to start. 

Here’s some advice: if you make Product’s life easier, they’ll naturally start to rely on you as a trusted partner. So in this piece, we’ll dig into the “don’ts”—the 4 most common mistakes CS leaders make when working with Product, and then share a few tactics for a better partnership. 

Note: The following article is an excerpt from our upcoming handbook, Actually Influencing the Product Roadmap as a Customer Success Leader.

Avoid common mistakes CS leaders make

When interviewing Product leaders for our handbook, we asked, “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 Success into an asset for Product, and the behaviors above do the opposite. Let’s take them one by one.

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 just doesn’t have the bandwidth to think about individual customers. 

2. Summarizing customer feedback in your own words

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 to discover the customer’s true problem. As a result, filtered requests are generally written off as “not enough info”.

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 Success isn’t tracking. When Success comes to Product with solutions, it requires Product to do all the problem discovery themselves, which they don’t have the bandwidth to do.

4. Going directly to Engineering to solve “urgent” issues

This is an absolute non-starter. 

First, 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, it’s likely the engineer you have a relationship with who won’t actually solve the issue well. They may also unknowingly create bugs that are even more serious. 

Second, 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. 

Third, 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.

Other tactics for getting Product to prioritize your customers

1. Have a designated Product Ambassador

“Our partnership with Product has been strongest when CS actually had a member of the team embedded in Product. This person would attend Product weekly meetings, demos, and was the person responsible for training the CS team on upcoming features or changes to existing functionality.” 

—  Angela Guedes, Head of Customer Success at Belvo

2. Create an internal “CS Panel” for Product to lean on

“At HubSpot we have a rotating panel of CS folks that Product can go to. Our Product team outlines the problem and the potential solution, and then CS will tell us if they have customers that might fit. It’s a good place to gut check ideas before digging deeper.”

— Jesse Tremblay, Group Product Manager at HubSpot

“We have a Product office hour every week. It allows Product to present features they’re thinking of and get feedback from CS about how they think they can use that with their customers.”

— Megan Bowen, CCO and COO at Refine Labs

3. Document and socialize for all

“In different companies I have worked at, we, as cross-functional stakeholders, have jointly owned and internally publicized a monthly updated itemized list with Impact and NRR At-Risk and Opportunity using tools like Confluence and Sharepoint.”

— Jeff Heckler, Director of Customer Success Solutions at MarketSource

4. Aggregate requests into “problem themes” for Product

"Many Product teams already do this: instead of prioritizing one-off features from all over the business, they’ll group requests into “problem themes” (think: higher-level initiatives to meet the company’s goals). Customer Success can make Product’s life easier by grouping customer requests into problem themes for them.  

And by the way, a “Product Theme” is different from a “Problem Theme”. Here’s the difference:

• A Product Theme is a group of customer requests: “Everyone is asking for this feature, build it”
• A Problem Theme is a group of customer problems: “Everyone is having a hard time achieving X outcome in the product”

A problem theme is better because it hones in on the outcome that needs to be achieved and gives Product the license to figure out how to achieve it. When Customer Success reports product themes, they’re basically saying 'Hey Product, just build what our customers are asking for' which goes against everything a Product person stands for. Many Product people believe 'Customers can only point out problems, they don’t know the solution.'"

— Nick Paranomos, COO at ‘nuffsaid

This week's top posts

COMMUNICATION

How to Handle and Share Bad News

Jason Lemkin offers some great advice for anyone who needs to be the bearer of bad news. “[E]veryone that’s been around start-ups knows there are ups and downs. We expect it. And investors especially expect it. What people don’t expect is not getting a heads-up on the unexpected.” This post is a nice reminder that even when times are tough, “If you are [...] consistently transparent — you’ll get through it.”

Read the full post

STRATEGY

3 Questions To Ask When Building a CSM Comp Structure

Here’s Ejieme Eromosele, VP of CS & Account Management at Quiq, on how to thoughtfully design comp plans to attract and retain top talent. She provides some clarifying questions that would be useful to consider whether you’re building out your comp structure for the first time or reviewing your existing one.

Read the full post

MEETINGS

How Digital Business Reviews Differ from Traditional QBRs

Cast CEO, Dickey Singh, introduces the idea of a Digital Business Review as compared to the tried-and-true QBR. This post will be especially compelling to organizations with a segment of customers who require tech-touch engagement. Scroll to the bottom to check out an in-depth table comparing the two.

Read the full post

TRAINING

Most Business Numbers are Random Noise, Not Meaningful Signals

As Ed Powers proves in this video, many of the statistics we come across in business are bogus—we just have to be smart enough to see it. Sign up for Ed’s course on data-driven decision-making for CS leaders to level up your statistics and data-analysis game.

Read the post