So, hear me out...
I truly believe all CSMs should be technically curious. Notice how I won't go as far as saying "CSMs should be technical", as there's a lot of connotative baggage that comes with tacking on that adjective explicitly. But having an interest in the technical aspects of your tool, a curiosity for the analytics of how customer use your tool, etc. is game-changing
Before we go any further, it’s important we remind ourselves what makes CSMs invaluable in modern SaaS. As a customer resource, CSMs are expected to be account managers, product and ecosystem experts, business consultants, support engineers, and renewal specialists. For the veterans, you can add data analysts and product marketers to that list as well. CSMs are the Swiss army knife of software companies, a go-to resource customers know they can rely upon for guidance and support as they adopt new tools.
But in the last decade, the Customer Success industry has grown so much that many organizations, in the scaling process, have relegated CSMs into a role as a shepherd of customer touch points. They’re either overwhelmed with such large books of business that they don’t have the bandwidth to dive deep technically with customers, or the company simply doesn’t appreciate the importance of having a technically-curious resource on the front lines. But what these CS organizations don’t understand is that without technical capabilities, CSMs risk falling into the role of a pure account manager, responsible for just the financial relationship and high-level business discussions. And if that’s all you have to offer to an enterprise customer, the potential for CS-led expansion is non-existent.
Now that I’ve sufficiently preached on my soap box, let’s step back and ask ourselves what does it mean to be “technically curious”, because remember: my goal is not to convince every CSM to become a part-time software engineer; it’s to spark some technical curiosity, fostered by a bit of additional technical exposure. As a CS resource, there are really three flavors of technical work:
- In-depth product expertise (for tools with deep levels of technical configuration)
- Underlying infrastructure, such as the software architecture the tool is built upon
- Data analytics, for understanding your customer base
The first is by far the most straightforward to learn, in addition to being the most logical place to start. To some extent, the CSM should already understand the tool (by nature of the role); it’s well within reach for said CS resource to really dive in and understand all the nuances, the “nooks and crannies”, of the software, especially for tools that aren’t turn-key and require heavy configuration.
The second may seem daunting for those that don’t come from an engineering background, but I promise that it’s not! The tool you champion with your customers is (generally) just a layer of web application components sitting on top of more interesting, complex pieces. These pieces make the tool “tick”, and being able to offer to your customers an understanding of how it does so is a huge value-add. Basic things, like how an operation is performed “underneath the hood”, what cloud infrastructure provider (AWS, GCP, etc.) is used by your tool and where, even how your tool manages customer data and ensures security and compliance standards, will ensure your customer is that much more successful in leveraging your product. And none of this requires an engineering degree.
Finally, the third will allow you to truly prove your value to both the customer and the organization. Your company will likely ask “what makes a customer healthy in terms of usage of the tool?”, a question answerable with just two things: (a) decent usage data, and (b) basic data analysis chops. Similarly, customers may want to understand what their north star is – what the ideal organization does to use your tool, and get the most value from it. Understanding the customer base, and how its usage correlates to renewal/expansion/churn will allow you to answer that question.
So with all of that said, what are some tangible ways to go about becoming a more technically-curious CSM and expose yourself to the right resources? For the first option, nothing beats good ol’ documentation and blog posts, the staples of a SaaS platform. Consume that material as best you can, engage with your company’s product and engineering resources, and maybe convince them to run a few workshops for the CS team. In addition, if you don’t have a test instance of your tool, a sandbox for playing around and getting your hands dirty, you’re missing out on truly empathizing with your customers.
For software infrastructure, the engineering and product teams are similarly a great resource, but to truly make the most of their time, it’s helpful to brush up on the core concepts beforehand. Resources like A Cloud Guru, which has mini video-based courses spanning all expertise levels, the swath of courses at Cloudera and similar platforms, and even YouTube, are all excellent places to build a foundational knowledge simply and painlessly.
Finally, for data analytics, it all starts with SQL. Even if your analytics tool leverages a drag-and-drop visualization approach, understanding the syntax of Structured Query Language will be invaluable. Similarly, there are troves of courses on Udemy, Cloudera, etc. for learning the basic operation and use of SQL, most of which are free and catered towards a non-technical audience. And once you have your bearings in the lingua franca of data, getting hands-on experience through tools like Mode, Tableau, Looker, Domo, etc. (for which your company may already have a license) will allow you to start answering interesting questions about your users, and even find illuminating signals to stay ahead of renewal and tap into expansion.
Being technically curious is truly an invaluable character trait for CSMs, and doesn’t have to be painful to develop. Be the well-rounded, specialized resource your customers and organization need.
Link to original post
----------
Josh is currently the Manager of Customer Architecture at Honeycomb.io, an engineering observability tool used to maintain the health of large production systems. He's worked in Technical Customer Success for 7 years, and has particularly nerdy passions for CS Operations and Data Analytics.
Connect with Josh on LinkedIn
