7/23/20 

As you know, I’m a product person…and recently I was asked to be on a live-stream discussion with a Customer Success leader about how Product and Customer Success could be better aligned and collaborate more successfully together. 

Here are some of my thoughts…

To understand how to align, it means you need to understand how each other thinks, each other’s priorities, and how they work.

PMs generally HAVE to work with business cases… be it large scale or micro scale. As a Customer Success person, if you go to a PM and say “my customer has a problem or my customer wants X feature”, you can bet you’re going to get a series of questions back from the PM, including:

• How many customers / what % do you think this is affecting?
• How important is the value add of the new feature / the fix?

That is because our product lives revolve around prioritization, data, and tradeoffs.

You could leave it fully to the PM to figure all this information out on their own, and send the PM(s) every little issue/ case that comes up.…but that generally won’t lead to an optimal outcome. While it might feel good to give visibility to everything, you can imagine that’s a LOT of inputs that you have to hope the PM can figure out the value of on their own. 

Alternatively, Customer Success could also keep their own running set of desires, fixes, etc, that are organized and prioritized. And then make mini-cases around the top ones. This helps in several ways:

• 1) It grows trust with the PM that there is a prioritization strategy 
• 2) it make the most important ones stand out
• 3) It helps the PM make a stronger case 
• 4) it provides alignment on and keeps visibility on the most important ones

The framing of the issues and prioritization are key. 

Taking this approach affects Customer Success in a few ways:

• Removes emotion: It forces Customer Success teams to think about their customers a little differently – and remove some of the emotion of “but i want this fixed because I want to help so and so that I really like” … or  “to keep customer X from being frustrated at the product or mad at me”…  
• Understand the business: It helps Customer Success (especially more junior ones)to grow a bit more in understanding business, which arguably helps for their role or any future role. 
• Provides buy-in / sets expectations: It helps them to understand why certain things AREN”T getting fixed/done — and to take that blame away from product/engineering (friction reducer again), because CS has provided the actual prioritization. Ie, there is alignment and buy-in.

How do we know if it’s working well and going alright?

There are some metrics we can watch, such as what percent of the top important CS-provided / supported issues being fixed/built? And in what timeframe? Note that how/when the issues are implemented may have to do with size and stage of company though — and there are many models for how that can work, such as:

• Take some  (generally small) percent of CS/customer issues in each sprint. (consistent progress)
• Full sprint dedicated to customer work every X timeframe (lumpy progress)
• Small team of engineers dedicated to customer work. (consistent progress)

There may be some variability, but visibility and progress on the top items should be continual. Product should always keep Customer Success in the loop about what’s being taken off the list and worked on (or not) — and have constant conversations so Customer Success hears/understands. (CS team size dependent, it might be the whole team, or a representative from the CS team who is most directly in communication with Product…)

If nothing is ever moving off of that list there is a problem. It may be a lack of commitment/buy-in on the product side or a challenge with prioritization on the product side. But, Product definitely can’t expect CS to continue coming to the table if product never does anything with the list.  If this wall is being hit, CS and Product Leadership need to be talking.

What things should you think of when building CS business cases for Product? 

It’s not rocket science and it doesn’t have to be super perfect. 

• What percent of customers are impacted? (1 customer? 10%? 50%? 100%?) 
• What is the importance of those customers (ie, are they your highest value customers? Lowest value? A mix?)
• Based on those two, how valuable is fixing the issue / building the feature? Ideally, you’re tying this to money (revenue, costs, etc), if possible.  (Will you lose some % of the customers impacted? Will some % abandon or fail to convert? etc)
• It’s also helpful to share if there are work-arounds or not…and the hidden costs of those.

Also, do not underestimate the importance of calling out the impact on HUMAN SUPPORT in a business case (ie time spent by Customer Success or others in the company if the feature isn’t built/fixed). This one is easily forgotten, but super important in a calculation.  If an issue takes a CS person an hour to handle and it’s happening to 25% of your 1000 of your customers, once per month… that’s a huge amount of time (250 hours/month of your CS Team!). And that is a BUSINESS problem which translates to time, money, tradeoffs…exactly what Product people are prioritizing. This is the one that many people forget to add in.

Here are a few other areas that can cause friction between CS and Product

…but I think they have fairly easy solutions.

1. Customer communication/interaction: Product people will often ask CS if there are some customers that product can talk to about X (a new feature, a new product line, issues they’re trying to figure out, use cases etc) — and this can be more of a friction point than product might expect. Owning the relationship with the customer can be HUUUUGE to CS (and their renewal rates…and therefore their job security) — and CS people can be quite protective of that relationship (especially B2B ones). If your company faces friction in this area, CS and Product should have very clear, open communication about CS concerns and also about the expectations/desires if Product is communicating with customers. Examples:

• Initial outreach… who does it?
  • CS does a warm intro?
  • Product just emails the customer?
• Who’s on the call:
  • Does the CS person always have to be on the phone when the product person is talking with the customer?  (CS, watch what you wish for. THis might be unrealistic from a time perspective if Product needs to talk to 20 customers for 30 min each — you just lost 10+ hours of your week). 
  • Does the CS person sit in on a few to feel comfortable? …and let the rest be?
  • Does the CS person just let the product person do the calls themselves
• In call — what’s on/off limits
  • Is there anything that CS wants you to avoid with the customers? (ex: we’re about to do training on Feature Y, please don’t go into that if you can avoid it) Any particular hot points? (the set had some crummy experiences with renewals last year, they’ll get super sidetracked if you bring that up…)  And in the same way that CS likely shouldn’t be promising product-things, Product likely shouldn’t be promising CS- things.
• Follow-up
  • I think this is one of the most important.  CS concern: If the CS person is not on the phone, how does CS know what happened, ie, how do they know where the relationship was left? With good communication, CS can set the expectation that Product should let them know anything that they should be aware of from the call (via email, spreadsheet, entering in CRM, etc). Such things could include interesting tidbits of knowledge (customer seemed really interested in learning more about X), frustrations (customer was clearly peeved about Y and I let them know you’d reach out), stumbles (customer clearly didn’t know Z was possible…you may want to reach out to them about it), etc… You will find that this drastically reduces fear and concern from the CS person and adds trust to the CS-Product relationship.
• Post call:
  • What are the expectations if a customer reaches back out to the product person? (redirect to CS? Handle if it’s in the domain they talked about before? etc)

For some people reading that passage above, you may find it sounding overly bureaucratic and ridiculous — can’t a product person just talk to a customer?!? If you’re feeling that way, hopefully it’s because you’ve been lucky enough to be in environments where this wasn’t an issue… because of company culture, or type of company (B2C vs B2B), or size (heaven help you if you have that much friction at a startup– it’ll fail!;  but unfortunately it’s not so surprising at some larger scales). 

2. Promising dates. Simple, but worth mentioning: Rarely should CS ever promise a date for a fix or feature update, even if you’ve seen it on a product sprint plan or roadmap. These things DO SHIFT for reasons out of CS control (and even PM control sometimes)…and you don’t want to be left with frustrated customers, which often makes you frustrated with product people. Avoid those frustrations and frictions by not giving dates.

3. Personas. If Product creates personas and doesn’t have Customer Success buy in, the personas aren’t going to be a useful tool with that group, which would be really unfortunate. Product needs to be sure that CS is able to play a contributory role in persona development, else personas won’t be worth the piece of poster paper they’re printed on.

Thanks for reading and hope your Product:CS relationship continues improving and thriving!

by