Naturally, SaaS organizations want their customers to renew their subscriptions over and over. For some companies, renewal happens every month. Larger, enterprise applications might arrange contracts that span a year or more, but renewal will happen eventually.
The surest way to keep a customer is to make sure they find value with your product. Customers who consider your product valuable won’t just prefer it to your competitors’ products, they’ll build your product into their process and workflow, making it hard to abandon.
The goal of a customer success team is to ensure your customers are finding value with the product. “Customer success managers are well positioned to listen for and uncover needs across the customer base,” says Julia Guyadeen, director of product management at Gainsight, a customer success tool.
Customer success managers (CSMs) work in a variety of ways that ultimately support customer retention. Sometimes they handle renewals and service upgrades closely (instead of letting the sales team handle that).
How the customer success (CS) team helps customers find value depends heavily on the product. High-touch enterprise customers require a close relationship. CSMs will often spend time on site training the customer’s team, solving problems, or creating custom solutions. CSMs support customer value in low-touch products (like B2C applications) using automation and processes at scale.
CS is an emerging discipline. It hardly existed ten years ago, but now it’s part of every SaaS organization, even the ones who use waterfall development methodologies (which, admittedly, aren’t many). CSMs are charged with optimizing customer relationships, increasing product adoption and reducing churn. Because the concept is so new, many customer success managers come from sales, customer support, and account management backgrounds.
How customer success supports product development
We’ve spoken before about the importance of letting your customers drive your product development. Rather than making a product you think they want, it’s smarter to use their feedback and behavior to lead your development cycles.
The CS team is an instrumental part in creating a customer-driven product. They are a key source of information for the product development team. They deliver valuable feedback about how the customer is using the product, what the customer wants, and the customer’s problems.
Together, CS and product teams can create an incredible product. But in poorly managed SaaS organizations, tensions between teams are common.
In most cases, a new SaaS product’s iteration is driven by the product team. As an organization grows and new teams are built, feedback comes in from many places. Marketing wants to be able to promise “seamless integrations.” Sales has sold a feature that doesn’t exist to a new customer. Support is fielding questions about the same error messages over and over.
The challenge is often communication. “Both teams are doing their best to create products people will love – and both are having trouble effectively communicating with each other,” says SaaS consultant and customer success evangelist Nichole Elizabeth DeMeré on Notion’s blog.
Making CS and product teams work together
Aligning these two teams, therefore, is about improving their communication. You need to create a culture that encourages both teams to work together. Here’s how:
1. CS should organize their feedback before presenting to product
Not all customer feedback is equally valuable. Your CSMs should know how to distinguish between what’s good and what’s useless.
Part of customer success means defining an “ideal customer.” This is the exact type of person the organization wants to target because they are easiest to sell and realize the most value from the product. CS should work with sales and marketing to identify this customer type.
Complaints or feedback from ideal customers should be taken seriously, especially if they affect the way the customer finds value in the product. For example, if an ideal customer requests an integration to another tool that’s popular in that customer’s industry, it should be noted for recommendation.
Feedback from fringe customers is less valuable, even if they are the most vocal. They may complain the most, but making product changes for non-ideal customers can actually drive you away from your product/market fit. It would be nice if you could please everyone, but you can’t.
2. CS should only present feedback to product if there is a consensus
Before CS delivers their recommendations, they should come to a consensus. The CS team should unanimously agree that a nugget of customer feedback is worth the product team’s time.
Document this with data if you can, like how much time the CS team spends dealing with the particular problem, or how many support tickets can be eliminated.
3. CS should coordinate with the product owner/Scrum master, not developers
CS is on the front lines, speaking with customers and dealing with their problems every day. They should bring customer problems to the product team leader so it can be turned into features, fixes, and improvements to create a better product.
If you’re following an Agile methodology, CSMs should bring customer pain points to the product owner or whoever organizes the team’s development process. Sticky notes and Slack messages can be irritating, so deliver it in a formal format with all of the supporting context information (notes, logs, links, etc.). Keep in mind that product managers are typically motivated by objective evidence. Data and proof will support your case.
CS teams should not recommend actual IT solutions to the product team. Let the developers figure out how to solve the problems. If CSMs start telling product teams how to build the product, tensions will form. Furthermore, CSMs are not developers, so their solutions might not actually address the problem, or might address the problem in a poor way.
4. Product teams should recognize CS team’s work as a resource
Product teams should recognize the resource potential of customer success. CS is a direct line to the customer. They can help interpret the data you’re collecting by providing additional information and context.
While product teams set their own development pipelines and CS can only provide customer feedback and make recommendations, they should take CS’ information seriously. They should accept that as developers they lack the communication skills, resources, and access to customers that’s necessary for a truly customer-driven product.
The development product manager should be prepared for more re-prioritization than he/she is accustomed to. Scrum tasks will have to be frequently adjusted as new information comes in. This will become a more common occurrence as the organization grows and feedback comes in from multiple teams. It’s not unusual for large SaaS organizations to employ full-time people who only manage Scrum boards.
Furthermore, customer success should have a seat at the table when features are planned (or at least before they are released). It’s smart to consider their input before the team spends resources building something without CS, who represents the customer.
Whatever you do, avoid silos
Anytime you have multiple teams with their own autonomy, you should look out for siloing. Siloing is when teams do not wish to share information with each other within the same company. They often do this to horde the value of the information for themselves to make their own performance seem exceptional.
Avoid siloing at all costs. The only way to grow rapidly, retain your customers, and sign new business is to encourage unabashed collaboration across your organization. Building a customer success team is an excellent way to create a culture that prevents siloing because, by its nature, CS must integrate with the rest of your organization.
In a healthy SaaS organization, it’s critical that both CS and product teams should work together because both have the same goal: To make an incredible product.