#15 | The Technical CSM

"Don’t be so enamored by your process that you fail to notice when it needs to be improved." - Justin Su'a

Bain published an article a few months ago on Why Software companies are failing at Customer Success. I believe the research has merit so let’s dive in.

Bain’s premise is that NRR has fallen in ~75% of software companies, because there’s misalignment in how customers want to be served and what Software vendors think their clients need.

Two areas of disconnect stood out for me:

1. Software vendors silo CS, completely segmenting CSMs from tech support, professional services, and learning rather than delivering an integrated post-sales experience package. Many companies launched beautiful adoption packages. I think Salesforce has the clearest and most attractive packages. Clarity in responsibilities, swim lanes, and KPIs are key so that each role can spend their time wisely on the right activity at the right time leading to better results and reduced spending. I don’t recommend showing up to your client like your org chart. Reinforce capabilities you deliver vs roles.

2. Clients want their CSMs to be technical and specialized, focused on architecture and implementation while CSMs are spending more of their time aligning on client objectives, client outcomes, and success plans. While the disconnect is pretty staggering, I don’t find it completely surprising. CSMs in traditional SaaS companies play more of a relationship manager role. I see CS Architects and CS Technical Specialists roles at companies that must move clients into new architectures (ex. VM or bare metal to container-based or cloud native architectures), in paid CSM models where CSMs do implementations, or when companies are trying to get new products installed.

Now what?

Bain has some ideas on next steps that you should read. Here’s my view with considerations for next steps:

· CSMs are a technical role: CSMs need to be technical and need to support architecture and deployments. CSMs have little credibility with clients and the rest of the account team if they can’t use your products. I do believe there is a lot of value in a CS Account Specialist or Technical Advisor to look across adoption, orchestrating deployments if a company has many, many products for clients to implement. Clients also want 1 person to go to … not 5. IBM implemented the CS Architect role in 2021 focused on installing IBM Cloud Paks on OpenShift. We’ve recently moved to CS Technical Specialists aligned by our platforms, focused on just a few products so our CSMs can architect, install, onboard, and help clients use our products. The data shows focus builds competence and competence builds confidence in moving adoption forward faster.

· Training: Invest in a dedicated squad to recruit, onboard, and train your CSMs, especially if it’s a new team. Once you get your team launched, think about how your CS Practice Leaders take over training your CSMs. You need to keep it going with skill challenges throughout the year. We just wrapped ours up! Another idea… your CSMs should be the very first team that tries the products before they GA. The tight feedback loop with the lab is golden.

· Where to hire: First, you need a hiring formula so you have some consistency in your model. Product management, development, technical sales, and delivery are great places to source a technical CSM team. Think about new hires coming right out of university, too, with Computer Science, Engineering, and Information Systems degrees.

Every company is different so you need to figure out what will work for yours.

I would love to hear what you think about Bain’s research and if you are aligning your CSMs to be more technical and specialized.

Janine