Moonlighting as a CSM
Mild-mannered customer engineer by day, daring CSM by night. Or maybe the other way around?
When you’re the first customer engineer in the company, you’re bringing in a new set of skills that may not already exist anywhere else in the company: strong technical chops combined with a level of empathy and polish that make you suitable for working directly with customers. Last week we talked about one of the common side gigs for founding customer engineers: helping out the sales side by functioning as a part-time sales engineer (SE). This is so common because the skillset required to be a successful SE is very similar to that of a strong customer engineer. But if you set aside the technical skillset, there’s another role that looks a lot like customer engineering: customer success (CS). This week we’ll look at what happens when you’re called upon to handle CS as well as your core customer engineering duties.
What is Customer Success?
Like last week, most of the people reading this probably already have a good idea of what customer success is and does. To quote myself from last year:
There’s a lot of overlap between Support and CS functions. They both interact directly with customers, they both build relationships with individuals on the customer side in order to more effectively do their jobs, and they’re both highly invested in the success of the customer. But that’s where the similarities end. The critical distinction between the teams is this:
Support owns all customer issues and inquiries that are directly related to the technology, while CS handles issues around the business relationship and nontechnical product inquiries.
This isn’t a hard and fast boundary, but it’s a good way to conceptualize the two domains. If an issue comes in related to the customer experiencing a bug? Support gets it. If a question comes in about renewals? That’s Customer Success. Where things get more interesting, however, is in the borderline cases. Who handles questions about product functionality, for instance? What about feature requests? This is where Support and CS leadership have to spend time in discussion, carefully delineating the boundaries and providing guidelines for their teams to make sure customer inquiries are handled as effectively as possible.
As you can see, particularly in the last few sentences, there are a lot of gray areas in customer interactions that could plausibly be handled by Support or by CS. And while this can be a point of friction between two established Support and CS teams, it shows that it’s very plausible for a founding customer engineer to handle CS and CS-adjacent tasks in addition to their core duties.
CS tasks you can do
As should be clear from the last section, CS is focused on building and managing relationships with customers. And in the absence of a formal CS function, nobody is in more regular contact with those customers than you. While relationship building and management is not part of your day-to-day as a customer engineer, where your tasks are primarily reactive and transactional, it is a natural extension of those activities.
Getting to know the customer: What is their industry? How many people are directly touching your product? Who is the person who wanted to buy it in the first place? Who is responsible for the budget? Make an effort to at least know who these people are.
Understanding their use cases: What was the purpose of their buying your product in the first place? What problems are they trying to solve?
Regularly communicating with the customer: Keep the lines of communication open. Keep track of the last time you spoke to someone on the customer side, and reach out proactively if it’s been more than a month or two.
Serving as a customer advocate: By understanding who they are and what they are trying to accomplish, you can position yourself more effectively to represent their interests. Will a specific bug fix be very important to them? Would an upcoming pricing or policy change affect them negatively? Your company exists because of its customers, and you’re their voice when having internal discussions about the product roadmap or other conversations about future planning.
The good news is, a lot of this can be accomplished alongside your typical support process. Simply by chatting with the customer while you’re on a troubleshooting call with them, and paying attention to what they say (and don’t say) in support emails, you can start to paint a surprisingly detailed picture of their goals, frustrations, and general satisfaction. Where you’ll have trouble is with the customers you aren’t talking to regularly—if they aren’t having support problems, or regularly opening tickets to ask questions or make feature requests, they are essentially invisible to you as a customer engineer. And while sometimes no news is good news, that’s not something to rely on in the CS world. Quiet customers may be happy, sure, but they may also be quietly frustrated. You’ll need to be aware of these quiet customers too, and make an effort to reach out periodically to make sure you don’t lose touch with them entirely.
Another thing that you’ll have to explicitly keep in mind is that you need to be taking careful notes, not just about their individual support issues, but overall customer health. You should be able to collect and pull up information about:
Primary use cases: As above, why are they using your product? What specifically are they trying to accomplish?
Progress to full deployment: Are they successfully using your product in all the places they want to? Are all of their use cases fully deployed?
Roadblocks to full deployment: If the answer to the last question is ‘no’, why not? What’s blocking them? Is it business, politics, or actual technical issues with your product?
Upcoming expansion opportunities: Is the customer expecting to have new use cases soon? Are they planning a major expansion or acquisition? Obviously a lot of this will be confidential but you can learn a lot just by asking what they expect to be focusing on over the next few quarters.
Ongoing issues: What are their open support issues, and what’s the status of each?
Open feature requests: As above, what product improvements or changes have they requested? Are those feature requests scheduled, on hold, or do we know for a fact they won’t be built?
Overall customer sentiment and health: Based on all of the above, how are things going with this customer? Are they overall happy? Do you see a path to them fully deploying your product, and if not, why? If they had to renew their contract today, would they do it? Look for any warning signs and raise a flag to the appropriate teams.
This information is going to be valuable when your company needs to paint an overall picture of customer satisfaction and health, and will be critical when it’s time for contract renewal. As a part-time CS function you’ll be working closely with Sales, and the more information about customer state you can bring to them, the better their own forecasting will be.
Prioritizing
But how do you fit in your CS-related tasks while also making sure you’re not missing any urgent support issues? Well, taking a page from our discussion last week, it’s all going to come down to revenue. It’s harder to put a dollar value on individual CS activities compared to SE work, to the frustration of every CS leader I’ve ever met, but that doesn’t mean you can’t come up with a rough heuristic. If a given CS activity is directly tied to an upcoming contract renewal, it will likely take priority over all but the most critical support issues. Contrariwise, any other CS tasks are going to be lower on the priority list than handling inbound support issues and keeping open issues up to date and driving towards a resolution. The priority list, then, might look like this:
Critical customer issues (i.e. you might lose a customer over this)
Renewal or expansion-focused CS tasks (e.g. periodic business reviews, renewal conversations, etc.)
All other active customer issues (they need to be solved, but can wait until critical CS work is done)
Other customer engineering tasks (bug and feature request reporting, documentation, etc.)
Other CS-related tasks (regular checkins, following up on feature requests, documentation, etc.)
Handing off to a real CSM
Once your organization grows enough to start building a larger CS or CX (customer experience) team, you’ll finally be able to hand over your CS-related tasks to a CSM (customer success manager). At this point, the record-keeping and note-taking you’ve been doing will really come in handy, since you’re going to need to have a conversation about every one of the customers you’ve been working with up until now. Going through them one by one, you’ll want to make the new CSM aware of:
Overall customer health
Stumbling blocks
Ongoing issues
Once the handoff is complete, you’ll be able to focus more exclusively on your customer engineering work, but spending some time as a CSM will expand your own horizons. You’ll be more alert to customer friction points, be able to see the bigger picture around why a customer is complaining about a seemingly small issue, and will be more alert to small changes in customer demeanor, responsiveness, and overall vibe. This in turn will make you a valuable extra set of eyes for the new CSM(s) on your team—and a stronger relationship between customer engineering and CS is only going to be good for the customers you’re both committed to helping.
Thanks for reading Andy's Support Notes 💻💥📝!