This article was originally published in Forbes.
In theory, customer success (CS) and product teams should be the best of friends, even BFFs. In practice, the two functions are often siloed, separated by a wall of creative tension and misunderstanding.
Until recently, this issue was frequently overlooked, especially at early-stage SaaS companies. Motivated sales organizations, supported by sturdy CSMs who were seen as “gap fillers” for the product, were usually enough to deliver the customer experiences that drive growth.
Rise of the customer-centric mindset
Today, things are starting to change. A more customer-centric mindset has arisen in executive circles, thanks to customer success evolving to become a company-wide imperative and the growing adoption of product-led growth strategies.
This mindset recognizes that CS teams can go only so far unless they lock arms with Product to deliver the features, enhancements, and experiences that promote universal user love and adoption. It recognizes that CS should be not just a functional responsibility but a company-wide endeavor. It becomes particularly critical when the need is to scale and drive efficient, durable growth.
For CSMs to be growth enablers, it’s important to ensure that the product meets the current and future needs of customers. In other words, to consistently generate the outcomes you need, CS and Product have to develop a shared framework and strategy that are tied to process, people and technology.
Without common strategies, expectations, and metrics, it’s not uncommon for CS organizations to complain that what’s being shipped isn’t fully baked, or that the release cadence is too frequent or infrequent. On the Product side, CSMs may be viewed as a source of unrealistic demands/deadlines.
Even if a company manages to avoid these problems, at some point along its journey from startup to maturity, it will have to confront the issue of how to scale customer success. How do you leverage the information you have—internal and external—in an efficient, standardized way to facilitate customer success?
Unlock value via the Product + CS Interlock
To meet this challenge, I recommend that SaaS companies create a Product + CS Interlock, a company-wide initiative that enhances collaboration between the teams by establishing common communications touchpoints, projects, processes, metrics, and governance.
The ultimate objective is to develop an ongoing program of joint decision-making that’s based on very clear shared expectations about what needs to be done (when and by whom) to overcome key challenges and ensure you are maximizing growth from your product.
Although the specifics of how the cross-functional teams communicate and govern themselves will vary from company to company, I believe it’s critical that every program be built around three components.
1. A “neutral” leader
To avoid the perception that one function is “taking over” the other, it’s important that the behavior of the person you choose to lead the program to be perceived as fair and neutral. The last thing you want is for your leader to be branded CS or Product-biased.
Even if the person comes from a Product or CS background, they should make a point of keeping one foot firmly in both camps by advocating on behalf of every stakeholder involved in the program. The ability of the program leader to understand different points of view and defuse creative tensions can be a major factor in helping you obtain (and retain) cross-functional buy-in.
2. A limited number of joint projects
To keep your initiative focused on specific, tangible, and achievable objectives (and avoid biting off more than you can chew), the teams should align around a limited number of projects.
At Gainsight, for example, we focused on three projects: (1) a revamp of our product release process; (2) acquiring better customer insights to support the overall product development lifecycle; and (3) providing better support for our CS ops and end-user communities.
3. A shared, cross-functional framework
• Find common ground on what everyone needs to do to provide customers with what they will need. For example, in the past, our Product team worked on what they knew was coming and what they needed to do. Meanwhile, CS worked on what they thought customers would need to be enabled. To establish common ground, we instituted a shared methodology called release impact sizing.
Now, all the features proposed for a release have a size assigned to them by the product manager and an SME team who determine the size based on customer impact (e.g., a big UI change for end users) as well as go-to-market implications, such as, “Would the debut of this feature require a big marketing splash?” From there, every feature is graded from a quarterly release perspective, and the assigned sizes determine both the launch strategy and the enablement assets to be delivered.
• Share project milestones. Create project milestones with cross-functional reviews and sign-offs. Note: It’s important that the scope of the cross-functional reviews and sign-offs cover not only product and engineering readiness but also your readiness to enable customers and properly market the release.
Once the milestone and review process is up and running, every member of the CS + Product Interlock should feel enthusiastic about what’s coming next. Why? Because once they hit every project milestone, they’ll know they’re fully prepared for the upcoming release.
• Share a scorecard. Finally, it’s vital that you develop a shared scorecard to measure success. For example, with regard to releasing process milestones, you might want to measure external and internal sentiment by soliciting answers to three core questions.
1. “How prepared for the release did you feel?”
2. “What types of assets did you find most valuable?”
3. “How would you rate the quality of the release and all the new assets?”
Of all the components underlying a CS + Product Interlock, I think the shared framework is the core determinant of how successful the program will be. Although every ingredient in the initiative will contribute to the results, more than any other ingredient, the shared framework will help ensure that your new CS-Product relationship is durable, long-term, and founded on joint problem-solving rather than mutual finger-pointing. And that’s pretty much the definition of BFFs.