The path to customer success starts before they see the product.

“Customer success” is an often misused term.

For your company, the goal of customer success is increased customer engagement and retention. For your customer, the goal is better learning and an ever-improving experience.

Regardless of your definition, customer success begins before the customer ever sees the product or any of its features. And the path to that success starts with release management.

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 to enable an ever-improving experience.

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, 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.

Customer touch points are those with a more tangential link to customers. 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.
• 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.

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 any release management engagement 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 a platform that’s easily updatable outside of the product but also 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 when 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 a lot of 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 detailed live version of your reference documentation.

In a nutshell, proper release management gives you multiple chances to tell your customers not only what they’re getting, but also why they’re getting it and why it’s important they get it.

In other words, you’ve started your customers on the path to success.