Customer success is an often misused term.
In some circles, it’s seen as an extension of customer support, a team of specialists that takes over when support doesn’t have the answers. In other circles, especially at larger companies, customer success replaces the role of the account executive, helping to increase engagement and encourage upsell.
3 Touchpoints in the Product Delivery Chain
Internal constituents, including B2B and B2C customer care, partner and customer success, and internal training teams
Internal-to-customer teams, for instance sales, marketing, finance, human resources and any other internal team that needs to be an “expert” on your product and business model
Customers, including engaged and existing customers, interested prospects and new prospects
Both of these definitions can be true, but at its root, customer success is about, well, making the customer successful. For your company, the goal of your customer success strategy is increased customer engagement and retention. For your customer, the goal of your customer success strategy is to provide them with better learning and an ever-improving experience.
Your company can make huge gains leading your customers down the path toward success, a path that starts with your release management process. But that only happens when your release management process is fueled by your customer success strategy.
So how do you resolve that paradox?
In my last post on release management, I dove into how your release management process should inform elements of engagement and retention throughout your release delivery chain, from engineering to end customer. In this follow-up, I’ll talk about how to deliver the information everyone needs.
What Your Delivery Chain Should Know
Every product release delivery chain is different and unique, but they all run through three high-level groupings:
Internal constituents are the teams that feed customer success as I described it above, namely, operations, B2B and B2C customer care, partner and customer success, and your internal training teams. They need to know how to provide the learning around the improving experience, working directly with the customer to transfer that knowledge.
Internal-to-customer touch points are those with a more tangential link to customers or a direct link with prospects. This can include sales, marketing, finance, human resources and any other internal team that needs to be an expert on your product and business model. They need to know how your product improves experience, engagement and retention, and how that improvement impacts the sales pipeline, market expansion, revenue and P&L and even hiring.
And then your customers, which I recommend breaking into four subgroups: Engaged customers, existing customers, interested prospects and new prospects. They all need to be made successful, but this will happen in different ways for each subgroup.
How To Deliver the Message
Once your engineering team has completed its release notes, these need to be reviewed and scrubbed by your product team to put those engineering terms into plain speak and to link that plain speak to customer success at each point in the chain.
Before we talk about the content, let’s talk about the presentation. The methods of delivery are usually limited to a few channels:
Notice: Here’s What’s New
Notice of the new release is usually delivered in two formats, a short-form as a pop-up or message within the product itself, and a longer-form release email.
The short form is one sentence, tops, that speaks directly to each new feature’s benefit to the customer, let’s call it the “what” and the “why.”
The longer form includes the same information as the short form, but adds a bit of “how” in terms of simple, high-level steps, “when” in terms of the role of the new feature in customer use cases and “where” in terms of exactly how to access it.
Versions of each of these messages can become part of your marketing and sales material, and that’s usually where your contact with prospects begins and ends.
Reference: Here’s How to Use It
This is what we normally think of as help documentation. Again, there are usually two ways to deliver and maintain reference material for your product.
In-product reference is specific help that relates directly to the feature itself or even the steps within that feature. Think of those little question-mark icons directly embedded in the UI that pop up or open new screens with tactical instructions for that specific feature or step.
Then there’s the dreaded help doc, the more global, indexed reference for the entire application.
This content has to be continually updated and maintained as future new versions are released, so it requires bringing on a platform that’s easily updatable outside of the product but completely integrated into the product.
Furthermore, while screenshots, visuals and video are worth a thousand words to most visual learners, the need to perpetually update the content requires a very flexible approach to how visual media is presented.
For any media you decide to use, the more compact you make the content, the better off your customer will be using it. Keep the instruction tight, focused on the primary use case, and speak directly from your customer’s viewpoint, not your company’s viewpoint.
In other words, if there’s any engineering-speak or product terminology left in your reference material, take another pass at scrubbing it.
Training: Here’s How To Take Advantage of It
Finally, there are two types of training scenarios to consider.
New releases that are broad overhauls of existing use cases or entirely new use cases probably require specific training for at least some internal folks and even some customers, depending on the size and scope of the new feature.
Once a product reaches a certain level of maturity, an overarching and perpetually updated product training program for new customers and new internal constituents is likely a necessity.
Here’s a sticky truth. Nothing slows the velocity of product development like the need to provide adequate training both internally and externally. But an adage I’ve learned to live by in the modern startup world is that if what you’re building requires training to use, you haven’t built elegantly enough.
That doesn’t mean you should never need to provide training, but the training you do provide should focus on how to be successful using the feature, not a more boring, more detailed and live version of your reference documentation.
How To Speak To Success
So now we’ve covered the basics of release management, why it’s necessary, and why it has to be more than just the handing off of developer release notes. We’ve defined who needs to receive the message, how they’ll receive it and what that message needs to convey.
In my next and probably final post in this series, I’ll talk about some guidelines for addressing each link in your delivery chain to promote engagement and retention. I’ll include some thoughts on how your new releases can feed your sales and marketing to bring more new customers on board and headed for success. I’ll also get into some specific options that are more proactive about encouraging customer success, including FAQs and product newsletters.
