9
Product: Design from the Start for Customer Success
The best way to make Customer Success happen is to “build it” into the product itself from the start. That means not just delivering an outstanding product, but building in the listening and follow-up methods that will allow your company to take customer feedback about problems with the product and act on that feedback quickly and successfully. We believe so strongly in the impact of baking CS into the product that we'll posit that the transformation of Product teams could be a solution to our societal challenges with technology.
Why Do Product Teams Need to Change?
Before we dive into how Product teams need to change, let's dig into the why. Why do Product teams need to change how they work to create better client experiences and outcomes? As someone who studied a lot of philosophy in college, Allison is constantly thinking about the deeper subjects in life, such as ethics and meaning. She believes that a liberal arts perspective can be useful in Product Management, where we can couple a humanist perspective with technology to create amazing outcomes and experiences for clients. Here's what she has to say on that topic:
As a COO, I'm always trying to figure out how to get a ton of things done in a short amount of time. I'm constantly thinking about how to do more with less. The danger for someone like me is that when you give them technology, the standard for what counts as “efficient” dramatically increases. Figure 9.1 shows what my typical workweek looks like.
Technology helps me pack my calendar to the brim: Any empty 30-minute time slot is immediately visible and available for me to book. In the two minutes I might have in between meetings, I flip through my inbox to see how quickly I can get back to inbox zero and how many text messages I can respond to. The busy-ness is such a good sign that our teammates want to collaborate, that clients want to meet, that there's opportunity. But the volume of communication is exorbitant. I'm playing a day-long game of whack-a-mole, as illustrated in Figure 9.2.
It takes its toll. By the time I'm at home, I am fried. My long-distance vision has declined because I spend most of my day staring at one or more screens, 12 inches from my face. I'm not as familiar with city neighborhoods, because when I'm in an Uber, I spend the time responding to emails. I am more forgetful than I used to be, because my brain operates in short-term memory as opposed to long-term storage.
I have my coping mechanisms. I don't check email in the morning until I've read a book for ten minutes, so my mind is in a more focused state. As a general rule, I don't check email after 7:30 p.m.; if someone needs to reach me, they know to text or call. I spend Saturdays completely outdoors, usually hiking in the Marin Headlands across the Golden Gate Bridge.
As much as I try to protect myself against technology, I'm struggling. The problem is that when I'm living this way, I don't feel completely human. I feel like I'm controlled by my technology. And I know that I'm not the only one who feels this way.
Today, the treadmill of technology has eliminated most autonomous moments we experience, so that we rarely exercise the muscle of reflection. When we do have a spare moment of space, we fear it. A friend of mine said to me once, “I don't want to pause and reflect, because it's terrifying to imagine what I'd think about.”
Products today reinforce and take advantage of our basest emotions—especially feelings of inadequacy and fear of missing out or being left behind. They erode behaviors we once valued and that I would argue make us more human: independent thinking, deep consideration, and control over our actions. Products today don't speak to our highest human nature. Technology has become first; humanity, second.
In March, my husband, Scott, and I planned a trip to celebrate his birthday. We decided to go “glamping,” which means glamorous camping. It involves sleeping outside in a tent, but with electricity. What's fascinating is that you forget entirely that the technology is there, because it's hidden in the background of nature (see Figure 9.3). Our humanity comes first; technology is here for us when we need it, but it's a servant to our higher interests.
Scott and I spent the day discussing the deeper things in life while wandering through the forested hills, shown in Figure 9.4. I even had a couple of breakthroughs about my work at Gainsight, which I never could have envisioned in the daily ritual of whack-a-mole. In this environment, humanity was first; technology, second.
Software products today don't fulfill this human-first standard. They don't recognize the humans they should be supporting as independent thinkers. They instead refer to humans as “users,” as a large mass of units, perhaps distinguishing among them based on groupings such as “persona” or their company's size. These are users to be “activated”—like a machine—or “converted”—which sounds like religious conversion. The technology is supposedly the source of religious insight; the humans, mere recipients.
Products therefore come with a vision that says “people need to change,” but the product doesn't facilitate that change. So a company buys a new product, and they look to roll it out, and the team struggles. As a group of naturally independent thinkers, these users are dumbstruck by the thought that they have to conform their entropic thinking to the mostly inflexible interface of today's software—or else risk not performing in their jobs. They're smart, so they'll eventually figure out where to click and how this software might help them. But the act of conforming to software dehumanizes them. In a moment of independent thinking, one of these “users” might ask, “Why doesn't the software conform to us?”
Our industry is so far from this ideal that thinking about this might generate feelings of cynicism among us. One might say: “We're all trying to make money, after all—both the vendors and the buyers who want their teams to operate with greater efficiency.” That's true, as we've discussed at length in this book! However, I believe that in the future, the ability for both sides to make money will depend on the degree to which technology conforms to and reinforces the most elevated of human behaviors. What will matter in the future is the degree to which a product is “human-first.” And I believe that together, this community can help create a new era of human-first products.
What do I mean by a human-first product? I'd put forward five principles for how a product should view the humans it serves.
The Five Principles
A human-first product should treat each human as:
- Growing: The product treats each human as having the raw material to improve their ways of working—but importantly, only if given time and coaching to master the new way, autonomy in how to do it, and clear alignment with a purpose. (I'm referring to the framework created by Dan Pink in Drive: The Surprising Truth About What Motivates Us (New York: Riverhead Books, 2009.)
- Special: The product treats each human as unique, with distinct beliefs, preferences, and motivations, not as an undifferentiated user. The product is inclusive of that specific human.
- Vulnerable: The product recognizes that a human can be abused by others who have their data on how they're using a product. It therefore assumes by default that any data gathered is owned by the human who generated it and offers meaningful ways to use the product without being forced to waive rights to privacy.
- Ends, not means: The product holds the humans it serves as ends in themselves (with technology as a means to their goals), taking their feedback seriously and adapting its approach accordingly.
- Autonomous: The product reinforces independent thinking and decision-making.
At Gainsight, we haven't totally fulfilled these five principles. You might think that this chapter is therefore hypocritical, but rather, it's an admission of guilt! That said, I honestly can't think of a single product that has fulfilled these principles. Our industry is not there yet. And it will probably take us a while—likely many years—to get there. To offer up a map to get us to that destination, I'd consider these five principles to be the five different stages of improving a product so that it becomes human-first.
The Path Forward
The five stages on the path forward are (see Figure 9.5):
- Stage 1—Growing: Instead of expecting humans to adopt products instantaneously (“Go figure it out!”), let's design the product's UI itself so that it coaches people over time on how they can take advantage of it and why it helps them. A simple first step is for Customer Success and Product teams to work together to create in-app guides to walk users through new releases.
- Stage 2—Special: Product teams should design ways to learn about what makes a person unique, and help create a correspondingly unique experience for them. Customer Success teams should have tools to visualize clients as more than accounts, but rather as collections of unique individuals who need to work together. The goal is to be inclusive of every client.
- Stage 3—Vulnerable: At the same time, gathering tons of data on people makes them vulnerable. So Product Managers need to create unique experiences while honoring people's need for privacy. And Customer Success Managers need to ensure that clients' sensitivities are communicated well.
- Stage 4—Ends, not means: Since technology is a means to a human's ends, products should adapt to what that human needs. As a starting point, Product Managers need to create a 360-degree view of feedback from clients and also learn about what clients need based on their adoption of the product. And CSMs can contribute their observations to that 360-degree view.
- Stage 5—Autonomous: Finally, products should be a “pull,” not a “push.” Products should help clients test their own hypotheses, not merely push recommendations. And CSMs should ensure that the configuration that's rolled out isn't overly rigid.
For the sake of a more humane software industry, Customer Success and Product Management can come together to help our industry honor these principles, and even to come up with new principles as well. But there's also a business reason for CS and Product to come together to design human-first products.
The Scaling Problem
We mentioned earlier in this book that last year we surveyed 100 Customer Success leaders about the maturity of their organization on a number of different capabilities. The most difficult pain point was automating the customer journey (see Figure 9.6).
And we've personally heard from many of you, “I need to scale my team.” (We've also said this about Gainsight's Customer Success team in the past.) It's worth us asking, What's the root cause of that need to scale in CS?
Imagine a hypothetical conversation, where we ask ourselves why nine times:
- Why do you need to scale?
- “Because Customer Success isn't a priority at my company.”
- Why are you saying it's not a priority?
- “Because my CFO won't give me more budget.”
- Why isn't your current budget sufficient for helping your clients?
- “Because my CSMs have too many accounts.”
- Why is that account load too significant?
- “Because my CSMs are already working nights and weekends in answering client emails, hosting best-practice calls, conducting trainings, running EBRs.”
- Why do they need to do those things?
- “Well, because our clients need it.”
- But why do they need tons of email responses, calls, trainings, etc.?
- “Well . . . because that's what it takes to enable adoption of our product.”
- Why is your product hard to adopt?
- “Well, because . . . well, we released this new feature recently, and it was a version 1. So we had a slew of calls with clients about that. We also have a backlog of enhancement requests, and it means we have to do this workaround for our clients, which takes some time.”
- Why aren't you solving the product gaps?
- “Ummm . . . well, that would be great. But it's not my responsibility. That's up to the Product team.”
- I thought you said your responsibility was to scale?
- “Right. . . . Well, I guess it's a shared responsibility.”
- Sounds like you and your Product leader should set up a meeting.
- “Good point.”
We have a massive scaling problem in our industry because we're not designing human-first products. This is an ethical problem. It's also a business problem.
We can break this scaling problem down into two related ones: a cost problem and a revenue problem.
The Cost Problem: “CSM of the Gaps”
Does the following situation sound familiar?
A new product is released. That product delivers a certain amount of value to the client “out of the box”—in other words, without human intervention to help the client. But the value that the client is hoping for—the Outcome that the client wants—is typically far greater than the “out-of-the-box” value. So the CSM spends their time plugging the gap between those two values: creating Band-Aid solutions or workarounds, running training sessions, and performing other activities that would not be necessary if the product delivered the requisite value in itself. The CSM is performing the role of “CSM of the Gaps,” since they are plugging a value gap that the product would fill if it had been better designed, as shown in Figure 9.7.
As a result, your CS expenses grow, and your profitability is suppressed. Moreover, when CSMs are filling gaps, your Finance team will start to account for them in the Cost of Goods Sold bucket—since CSM becomes an essential team to deliver on what you sold. And that means investing in CSM of the gaps is terrible for gross margins. (On top of this, your CSM team isn't happy, because they'd rather focus their time on more strategic activities. They can tell that these efforts wouldn't be needed if the product were more effective.)
Besides the cost problem, you incur a revenue growth problem when your CSMs spend their days filling gaps.
The Revenue Problem
In the “CSM of the Gaps” model, you handicap your revenue in two ways. First, when CSMs are building Band-Aid solutions day in and out, they don't have time to do the things that could maximally drive growth in your recurring revenue. They don't align client stakeholders, propose a success plan, and enable change management. They don't facilitate faster expansion and convert clients to talkative advocates. Clients don't get as much value as they could. Your renewal, expansion, and advocacy rates suffer. You don't grow fast.
Second, in this model, you don't build the product that will maximally drive revenue growth. When CSMs are building workarounds, they paper-over the root causes that another team—Product Management—is better equipped to solve. They shield Product from the information they need to make better decisions. The only data point that the Product leader sees, likely in strategic planning sessions, is that the cost of CSM is too high (as discussed above)—which, to the untrained eye, looks more like an execution problem that a CS leader should solve with the CFO's active monitoring, rather than a problem that the Product team can help solve.
As a result, your product quality and value don't improve fast enough. Your competition catches up. Your customers churn at higher rates. They stop expanding with you. You can't get advocates to speak at your events anymore. Word spreads that your product isn't great. Sales cycles become longer. Over time, what seemed at first glance to be a CSM execution problem has turned into a growth problem. Because you're not growing fast enough, your board tells you to become more efficient—but that's hard, because your high CSM headcount is necessary to compensate for your suboptimal product.
You might get stuck as a low-growth, low-margin company unless you can transform the way your product makes customers successful—not just once, but continuously over time. For that, you need processes to consistently bake CS into the product. You need systematic alignment between CS and Product Management on how to solve the problem of scaling.
Now that we've discussed why that alignment is important—for both ethical and business reasons—let's discuss how to make it happen.
Product and CS: The New Sales and Marketing
Here's some conventional wisdom that's at least as old as the wheel: If you want to achieve growth, invest in Sales and Marketing; acquire new customers. Marketing would attract new leads and nurture them, then pass them along to Sales, who would close them.
As we've discussed, in the Age of the Customer, CS teams have joined the ranks of Sales and Marketing in driving business growth by focusing on customer retention and advocacy (see Figure 9.8). But as we've discussed, CS can't do this alone. Because the product itself generates so many invaluable customer insights and personalized interactions with clients, the Product Management team has become an invaluable partner to CS. Just as Sales and Marketing were once considered jointly responsible for top-of-funnel growth, so CS and Product Management are now the “two peas in a pod” for delivering experiences and outcomes, to keep and grow customers and turn them into advocates.
CSMs immediately grasp the idea that CS and Product are the new Sales and Marketing. CSMs are often, well, obsessed with the idea of sharing feedback with the Product team. “CSMs see how customers deal with the product post-sale, so they have the best view of what customers find valuable, and what they're trying to do with the product going forward,” says John Sabino, customer success officer, SVP at publicly traded data software company Splunk.
CSMs really live with the customer every day. So they feel it in a very personal way when the product doesn't work. They see how hard an upgrade is and what the client actually gets for that upgrade. They see how many support tickets are created and how many of those tickets have built up over time. They see the customer interact with the product and can usually advise better than anyone else on how easy it is to use and possible feature or usability enhancements. They are your key to ensuring new feature adoption and the value these investments create for your customers.
CSMs are your number-one source of what's the next best thing to build, because they're your number-one source of info on how your product is being adopted and whether or not it's working as intended in the marketplace. And they know better than anyone how stable and scalable your product really is.
CSMs may be eager to provide feedback to Product teams. But how do we ensure that Product teams are happy receivers and that the partnership endures?
We propose nine solutions below.
Solution #1: Create One Common Data Set
Part of the solution lies in ensuring that CS and Product teams have the same data set. A while ago, our CS team launched revised Scorecards for Adoption. They called them Adoption-Breadth (capturing diversity of feature usage) and Adoption-Depth (capturing the degree to which individual users used the product). They presented them in an executive team meeting, only to hear from the Product team that they were already using their own, very different definitions of Breadth and Depth. The CS team had no idea! Each team was well-intentioned, trying to achieve similar goals. It wasn't the Product team's fault. It wasn't the CS team's fault, either. The problem was that we weren't all coordinated.
Make sure you have one set of data on clients across your company—a true “Customer 360.” That data set should include adoption data, Support ticket data, survey responses, and Customer Health Scores. All of that data can help Product and CS teams develop a common point of view about how to prioritize enhancements on the roadmap. (We'll come back to how to build a Customer 360 and which metrics to prioritize later in this book.)
Solution #2: Bridge from Situations to Patterns
Let's turn to Steve Sloan, former chief product and marketing officer for SendGrid, a division of Twilio, and current CEO of Contentful. He has worked to build a tight connection between the Product Management and Customer Success teams.
We assume that our entire company wants to consistently create products and experiences that our customers love and value, and each team works toward that goal. But for instance, in the case of Customer Success and product management, they're working from slightly different angles. I think of it as a two by two, with the x axis the number of customers you're focused on, and the y axis is impact. Both the CSMs and the product managers [PMs] are focused on high impact. PMs are usually focused on the impact across as many customers as possible, and CSMs are focused on the most impact on the subset of customers that they focus on. The trick in getting the groups together is how you bridge between the two.
We have a few ways to make this happen. For the PMs, we created something we call “listening posts”—ways in which the PMs are able to gain insights about customer problems. It establishes a regular rhythm where the PMs go to the CSMs and ask specifically for themes or trends to understand what they're seeing from customers.
The second thing we did was to have them focus on problems, not solutions. A team may get focused on the idea of “Let's go build X!,” but it's possible that this solution won't ultimately yield what the customers want. But when we get everyone to focus on a really acute problem—again, that focus must occur across teams—we can have a fair amount of success. We can then go in and validate a range of potential solutions. But the problem always comes first.
Solution #3: Productize Those “Workarounds”
Remember those CSM workarounds we discussed earlier in this chapter? Product teams can turn those Band-Aids into enduring solutions. That's what Sloan's team has done.
We observed that CSMs were brilliantly and creatively coming up with their own little tools to handle the customer problems that they saw over and over again. We had a notion that we could create services offerings to do the work that CSMs were already doing out of the goodness of their hearts. Or we could actually productize those solutions—build them in as a new feature or a premium tier in our products.
To enable that productization, we assigned a PM and a product designer to work full-time with the Customer Success team. They noticed that time after time, CSMs had created a bunch of creative and insightful problem-solving templates, which were signals of a product opportunity. If the CSM had taken the time to create the template, it must mean that they saw that problem on a regular basis.
In 15 months, that pair of people in combination with the CS teams created a new set of products and services that went from nothing to about $7 million in revenue. That really showed us that we need to have people with the skills and the time to identify those problem patterns. Because we had both the product manager and the product designer, the team could come up with paper-based prototypes and share them both with the Customer Success managers and get their initial reactions. It works so well because the teams can sit down together, see what the other side is dealing with, and then work through the solutions literally side by side. The product folks sit behind people and just watch what they're doing. Then they reveal all these amazing insights.
One of the challenges for productizing these things is that CSMs do this work automatically. So they take for granted all the amazing little insights they have, and all the little tips and tricks they have for quickly getting a customer to a successful place. It's the exact same set of skills you have when you're doing customer research where you ask people questions, but then you need to go and watch them work and understand what they're doing. And then when you see something that looks interesting, you pause them in the middle of their work and get them to walk you through it. We're trying to get inside the brains of these awesome CSMs and figure out a way to generalize their insights.
Solution #4: Create a Product Risk Process
At Gainsight, we track Product Risk, which is when a client can't get sufficient value from the product unless an enhancement is made. When a CSM escalates a Product Risk through a Call to Action in our Gainsight software, it kicks off a formal process outlined in a Playbook, which the CS team and the Product Management team collaborate on. The Playbook often involves the Product Manager meeting with the client to understand why they're not getting enough value, and then closing the loop with the client once the Product team has made a decision on a change in the product roadmap.
Flagging Product Risks is a careful balancing act. Too many flags can result in a stretched Product team that handles a large volume of risks, but doesn't follow up any of them with sufficient effort, and/or a Product team that dedicates too little time to breakthrough innovation. That said, we usually see CS teams flagging too few risks to their Product teams, not too many.
Solution #5: Leverage Your Online Community
An online community allows you to gather feedback from your customers at scale. Customers post their ideas to the community forum, and Product teams can respond directly to their posts to learn more. CSMs can also post their own perspectives on the forum. Gathering product enhancement requests posted on the community forum allows you to track and analyze the requests that are common to many customers. Community participants can upvote product ideas; enhancement requests that appear most often or that have the most upvotes are prioritized on the product roadmap. Because both Product and CS have access to the community—including the upvoting data and the qualitative feedback—they can more easily align on the highest priority problems to solve.
Solution #6: Subject Matter Expert Program
CSMs are not the only client-facing team members who have a valuable perspective on the product. Members of the Support and Services teams should also have the opportunity to share feedback with the Product team. For example, while a CSM would lend an interesting perspective on the usability of a product for end users, a solutions architect might have a perspective specific to the configurability of a product for an admin.
At Gainsight, our Subject Matter Expert (SME) program connects our product sub-teams, each of which focuses on a different part of the product, with people across different roles in our CS organization. Each SME team meets once every two months, with the following agenda:
- Product feature update: Overview of trending usage stats, recently released enhancements/functionality and bug fixes.
- SME examples: Review of challenges faced by customers related to a feature, and proposed solutions.
- Feedback on roadmap: Review the upcoming roadmap and reprioritize, add, or remove proposed features based on SME feedback.
Sometimes, if we hit on a really juicy subject, we hold a follow-up meeting with the appropriate SMEs and Product Managers to deep-dive on specific issues.
Solution #7: Publish the Roadmap
In the same way that CSMs need to close the loop on feedback from clients, Product teams need to close the loop on feedback from CSMs. Product teams should share how the roadmap is changing as a result of the feedback: specifically, what is going to be built, when. “Eventually, we realized we needed to have a shared document that everybody could look at and know what was on the schedule and what wasn't,” says Sloan. “Otherwise, the CSMs will assume the fix fell through the cracks, when what actually happened is that it was actively decided that the team isn't going to prioritize that build right now.”
Solution #8: Develop In-app Messaging
It used to be that the only way for Product teams to make changes to the product experience was by altering the code through a new release. Today, in-app messaging tools allow Product teams—with close collaboration with their counterparts in CS and Marketing—to improve the product experience without touching the code. Product Managers can design walkthroughs for new customers, guiding them on what to do when they first log into the product. They can communicate with customers on how to get value from a new feature. They can surface knowledge base articles that may be relevant. They can even gather survey feedback from customers precisely where they get stuck—in the product itself—which generates response rates that are often three times as high as for emailed surveys.
Solution #9: Foster Mutual Empathy
All these processes are valuable. But they won't sustain their impact unless Product and CS demonstrate compassion for each other. “One missing piece in many of these conversations is a shared empathy,” says Steve Sloan.
PMs need to understand that the CSM who they're talking with is explaining a customer problem. And the CSM probably had to deal with a tough conversation with that customer. Keeping that realization in mind helps to build empathy for that charged situation from the product management side. And from the CS side, it's important to understand that the product manager they're talking to has far more valid projects to pursue in any given week, month, quarter, year than they can actually deliver. There are good projects that won't make the prioritization list because there's a finite amount of engineering time. It's a painful reality of prioritization, not an excuse.
For all of us, there will be things that we'll be bummed out about because they're not happening. Without that shared empathy, cross-functional communication tends to go poorly.
Summary
What is the big takeaway from all of these best practices? Transforming the Product-CS couplet into the new Sales and Marketing requires an evolution in the data they share, the language they use to communicate, and the processes that systematize their collaboration. Your investment in these innovations will pay off in terms of reduced cost, improved revenue growth, and—more abstractly but equally importantly—the fulfillment of your ethical obligations toward your clients as human beings.
There is an enormous opportunity for Product leaders to build products that guide people through a journey from fear and confusion to success. There's also an opportunity for Customer Success leaders, who are staffing teams to break down the barriers between human and machine. The solution is for Customer Success and Product Management to join together to deliver technology that is human-first.
Let's come back to the feeling you have when you're walking through the woods. The clarity of thought. The freedom. The empowerment. What if every product experience could be like a wondrous hike through the woods?
In the next chapter, let's move on to how another department should evolve: Marketing. What's the new role for Marketing in this Customer Success symphony? Hint: It doesn't end with a hand-off to Sales.