1. Home
  2. Blog
  3. Creating Powerful Collaborations Between Customer Success and Product Teams
  1. Home
  2. Blog
  3. Creating Powerful Collaborations Between Customer Success and Product Teams

Article Creating Powerful Collaborations Between Customer Success and Product Teams

Linda Formichelli Jun 21, 2021

The March Humans of Customer Success Community Hour tackled the question of how product and customer success teams can collaborate to drive overall company growth.

Our discussion leaders were:

Conor O’Mahony, Chief Product Officer at Klaviyo, an email and SMS marketing platform for online businesses.
Kristen Yerardi, VP of CS and Product at Randori, an automated attack platform that’s solving some of the toughest problems in security at scale.
Shonak Patel, a growth consultant who recently started up the Customer Experience organization at the in-app user engagement platform Appcues.
Jonathan Tushman, Co-Founder and CEO of Quala, the most intuitive Customer Success Platform with the quickest time to value, that combines the voice of the CSM with customer usage data for a clearer view of customer health.

These discussion leaders have been part of early, mid-stage, and later-stage companies. All managing SMB, mid-market, and enterprise-level customers—so no matter what stage company or what type of customers you’re working with, you’ll find helpful, relevant information that you can start using today.

Read on for a wrap-up of the call, or watch the whole thing here.

Aligning The CS and Product Teams’ North Star Metrics

If your organization is struggling, it could be because your product and CS teams’ North Star metrics are in misalignment with one another—or with the customer. Here’s how to get the teams back in sync.

Shonak: For product in B2B SaaS, speed is everything. Time to value early on is very important. So I look at product’s job as removing friction and making it really easy to adopt the product and achieve the outcome.

In CS, it’s all about helping the customers with the process of adopting the product to achieve the outcome. Because even if the UX is amazing, you’re still asking people to change their internal process. And that change can be dramatic. CS is charged with a lot of change management early on—all in support of helping people find that value very quickly.

Jonathan: CS and product are probably the two most challenging roles in the organization. They have so many different masters, so many people they need to please. It’s not just the customers—it’s the sales organization, it’s the marketing organization, it’s the CEO, it’s the board. I used to joke that I wanted to wear a T-shirt and hat around the office that said “Disappointing Everybody.” You can’t please everybody, so you try to disappoint everybody the least.

Product owns two main things: the roadmap, and a ranked sort order of what the team is executing on and what they should be working on next.

Then, with customer success, there’s the phrase “the whole product.” You start off with a piece of software, and the software itself is not the full solution. Customers need to know what the roadmap is, and they might need some consulting services. Customer success helps fill that gap to satisfy the needs of the customers when the product itself is not doing what the product needs to do as a full promise.

Kristen: Customers look at the product as the company, not just as the thing that they’ve actually purchased that they log into every day. So understanding all the touchpoints is important in customer success, because they’re the ones that receive that feedback from the customer.

I saw a great visual of a “backward prism” that illustrated this. Instead of the white light going into the prism and all the colors refracting out, it was the opposite: it was all of the colors of the company going in. So you’ve got sales, you’ve got customer success, you’ve got product—all these different inputs into the product and outcomes.

The product roadmap—which really is the communication vehicle for the strategy of the company—also gets broken down into the tactical pieces so that the entire company has the whole view. Paying attention to it is super important.

Conor: When I first joined Klaviyo, our mission was simple: it was to help our customers grow. The first two years I was there, our company goal revolved around how much money our customers made that was directly attributable to us. That was our North Star. At every company meeting, we would start with that number. Customer success teams have quarterly business reviews, but we turned them into quarterly growth reviews because we were helping our customers grow.

The product team oriented around how we could help our customers grow, too. So the teams were aligned, but the scope of reference for the teams was a little different. The scope of reference for a customer success team is the customers, and the scope of reference for a product team is broader—because it also needs to look at people who are not customers yet, and might even be looking at other segments or solutions.

Product Is from Mars, Customer Success Is from Venus

CSMs, engineers, and the product team have very different viewpoints—and helping them all understand one another opens the door to powerful collaborations.

Conor: A lot of us have some sort of NPS score. Where is that owned? Is that owned by customer success? Is that owned by product? Is it owned by the entire company?

If you look at the comments that come back in NPS surveys, you’ll see that they span every touchpoint. So if everybody takes the viewpoint that they own NPS…and the NPS comments go into, say, a Slack channel…and everybody checks that channel every day…this ensures that there’s vitality in the reaction to those feedback loops. This can actually help break down some of the silos that might otherwise be naturally formed within an organization. It’s such a complex web, and everybody across the functions has got to be in the same boat rowing together in order to make it all work.

Jonathan: I actually think a lot of the DNA of the engineers, product, and customer success is quite different. I find engineers and product to be very sensitive, reactionary folks; when they produce software, they’re initially insecure about it. Every bug announced is a little dagger to their heart, and it can distract them and slow them down.

Customer success is really good at interfacing with customers—hearing and listening and capturing things—but if there is a constant flow of bug requests, it can potentially become debilitating to engineering. So it’s super important for customer success to be fully empathetic to the engineers and the product organization, and vice versa.

I find a lot of dysfunction in these two functions, because they’re not really putting themselves in the other people’s shoes. The engineers are not seeing that the CS team is being berated because the engineer missed a delivery or pushed a certain feature.

And on the flip side, customer success often doesn’t see that the engineers and the product organization do really care about delivering a high quality product, and they need some focus time to do it. So as engineering organizations evolve, the ones that do it well really shine a light on how other people think and operate.

Kristen: The point on empathy is huge. You should assume that everyone’s coming to the table with positive intent. I don’t think there are many people out there who have encountered someone who nefariously tried to release something with a bug. The reason some of our companies do so well is that we all care personally about the success of the company and the customer.

One of the things I used to hear from product managers was, “I just want to hear the problem…they always tell me the solution.” Well, they’re human! They don’t think in problem statements the way you’ve trained yourself to. We all inherently want to solve something. So you need to ask questions to get at what they were trying to do that made them come up with that solution. Then you can get to the crux of the problem.

If you start to see some of those ripples underneath the waves on the surface, trying to understand and correct them quickly really allows collaboration to happen in a great way.

Shonak: My role before this was in sales. For early stage teams, I put on the hat of almost being a BDR for the product team—setting up conversations, keeping them close to the customer. I would tell my CS team that our job is to get “at bats” for the product team, meaning interactions that are relevant to what is on the roadmap.

When Product and CS Collide

A CS Community Hour member was in a tough position when the product team didn’t have the bandwidth to work on product requests from customers. The solutions from our discussion leaders: clear communication, empathy, and letting the product team in on (not too many) customer calls.

Kristen: Customer feedback is business critical. The CS leader can ask what product is working on, what makes it mission critical, and how long will the team be focused there. Then ask if there’s any way to work together to understand what customers really need next so the CSMs can give customers a timeline on when some of these major issues can be solved.

Do it with empathy. Try to understand the bounds of what they’re telling you they have to do, and find out where there might be an opportunity to either piggyback on what they’re doing or peel off some work in order to keep some things going.

When I worked at WordStream, we had a hard time doing any bugs for customers. So what we ended up doing was saying, “Hey, if you’re doing two-week sprints, can we reserve 20% of the tickets in that sprint to be customer-focused issues? That way you still get things done on the roadmap, but we can at least start to handle some of these high priority bugs.”

Jonathan: Have somebody from product engineering actually get on a call with a customer and feel the pain with you. Hearing it from you versus hearing it directly from the customer are two completely different things. I guarantee that if this person is showing up on a call with the customer next week, the problem will be fixed by that time.

Sonci: Putting the product and engineering leaders on calls with customers is so good because it lets them hear the customer voice. But once they’re locked into that relationship, they might actually derail some of the larger company goals because of that connection. So use this tactic sparingly.

Conor: I want to call out something from the chat, which is that whether you use Gong or Chorus, sending little segments of calls to the product team, as appropriate, can be incredibly effective.

There was so much more to this compelling conversation; to learn more, watch the whole call on YouTube.

Interested in being a part of these in-depth discussions yourself?

Join our Humans of Customer Success Community for free!