Are your Customer Success and Product teams besties?

Sure, they might be able to crack a few jokes and engage in small talk before meetings. Heck, they may even be able to laugh at the same memes on Slack. 

But would your teams go to bat for each other? Would they go above and beyond to help each other out? Would they argue over who gets to float safely on the big door while the other stays in the frigid ocean water? 

Don’t fret if the answer is “no.” You can still turn things around and get your CS and Product teams to be the dynamic duo they were always meant to be. And you don’t need to spend a single red cent to do it. All you need is for your CS and Product teams to adopt a few new, simple practices:

Tip #1: Celebrate each others’ successes

Everyone wants to be appreciated. Yet few developers ever get to hear what the customer thinks about their product (except for feature requests and bug reports, which is not encouraging feedback). 

Whenever a customer praises the product--no matter how minor it is--share that information with the product team in a visible way. Don’t just copy-paste what the customer said, either. Share the context of that praise and how it helped the customer. 

Consider this example:

“Customer says they like the product.”

Compare that to:

“Customer appreciates the “Notes” feature a lot. It’s saves them literally hours of work every week and they use it every chance they get.”

See that? CS gets to spread the love and Product sees how their work has positively impacted the customer story and improved the customer relationship. 

In the same vein, CSMs and their customers would love to know whether or not their suggestions contributed to the product roadmap. If the Product team acknowledges their input, it would help CSMs feel good about sharing information with the Product team and encourage more of the same. 

Tip #2: Be transparent (and polite) about failures

Things don’t always have to be perfect. There will be features that are duds, and there will be customers that churn no matter what you do. 

What’s important is for CS to communicate these incidents to the Product team, and to do so in an impartial and constructive way. 

Compare:

“The new report feature sucks!” (Flip table)

To:

“The customer thinks that the new report layout is too busy, and that the font size makes it hard to read the labels. Would you like me to ask them for any other details or feedback?”

Notice the difference? The first reaction will just make the Product team hate you. But the latter reaction is much more helpful to the Product team and more likely to prompt positive action. 

You can do the same thing for churned customers. Telling the Product team that a major account churned because a competitor has a better UI will give Product a better idea of what to focus on the next time they review the roadmap. 

Tip #3: Be considerate of each others’ needs

One of the most important elements of being a good co-worker (and even being a good human) is thinking beyond yourself. Everything you do at work affects how other people do their work. A job done poorly or hastily in one area will make life difficult for someone else down the line. 

For CS and Product to be besties, they’ve got to think about how what they do affects the other team, and take steps to ensure that effect is positive. 

One area where Product can do this is in pushing new updates to production. CSMs don’t like surprises--especially when a customer discovers a new feature first. Yet there are still Product teams who release updates without notifying the rest of the company. 

When a Product time gives appropriate notice before releasing an update, it gives time for the CSM to get accustomed to the changes. Then they’ll be able to provide more intelligent answers when the customers ask about it. 

As for Customer Success, one area of improvement is in providing feedback. The Product team gets LOTS of questions, comments, and emotional reactions from customers who want the product to do what they want--even if it’s not appropriate to the roadmap or the product’s core purpose. If the Product team took the time to investigate each and every issue, nothing would get done. 

Customer Success can help by asking customers the right questions before passing the feedback on to the Product team. Questions like:

• What are you trying to accomplish?
• What are you expecting the feature to do?
• What steps did you take prior to encountering the error?

By asking these questions, the CS team can help the Product team narrow down possible options and help come up with a solution faster--even if it’s a workaround. 

Also, CS can help by vetting the customers that are giving the feedback. Is CS talking to an ideal customer? Or are they talking to a bad-fit customer? The answer can make a huge difference to the Product team, because they don’t want to take the product in a direction that only one person wants--they want to help as many people as possible. 

Tip #4: Be inclusive

When I say “be inclusive,” I’m not talking about it in a social context (although you should definitely be inclusive in that context). I’m talking about letting the other team in on what you’re doing. Allowing them to pitch in and help out in a non-invasive way. 

For instance, CS can invite Product into meetings with the customer so that they have the chance to get feedback direct from the source. 

Catalyst did something similar. We had a “Reverse Q&A” where we had a customer attend a webinar, and our Engineering team asked them questions about the product; what they liked, what they didn’t like, and ways it could be improved. 

CS can also provide recordings of customer calls, so that the Product team can play it during internal meetings and review the data according to their own schedules. 

The Product team, on the other hand, could invite CS to be beta testers whenever there’s a major new release. They’d be able to provide valuable feedback because they are front-line with the customer, and would be able to speak intelligently about how customers would react to the proposed changes. 

The key to making the beta user arrangement work is actually acting on the CS team’s feedback. Failure to do so gives the impression that it’s an empty gesture. That’s going to hurt the relationship even more than if Product just didn’t do anything to begin with. 

Tip #5: Set expectations

The key to a good relationship is boundaries. Boundaries and expectations. And just because we’re promoting a spirit of cooperation between CS and Product, it doesn’t mean that you have to do everything for each other. Because you can’t (and shouldn’t). 

What you should do instead is set expectations for what each team can and can’t do. I’ve known some organizations that create an official SLA document to formalize aspects of the team’s working relationship. For example:

• CS will log suggestions and feedback into a ticketing system
• Product has 3 days to provide a response

“Setting expectations” doesn’t need to be so formal. It could be just an understanding of each team’s situation. 

For example, Product could understand that CS is obligated to forward customer comments as part of their duties, while CS could understand that Product won’t be able to honor every feature request--even if it’s a good idea. 

Let’s roll

So can your CS teams be best buds with your Product team? 

Absolutely.

Like all good relationships, there needs to be communication, transparency, and trust between the two teams. It’s not going to happen overnight, but if you follow the steps above and do it consistently, your teams will be so in sync that they might even start finishing each others’ _________!