A customer success masterclass | How to design, build, and scale a CS org | Stephanie Berner (LinkedIn)

Brett: Well, let's do it. Thank you so much for joining.

Stephanie: Thanks for having me.

Brett: Maybe a good place to start Is let's say you join a company and they're just getting going.

They have early signs of product market fit. Customer success isn't owned formally by anybody, but the founders are doing a lot of it. So let's say they have a few million dollars in recurring revenue. They're thinking about formalizing customer success, hiring their first people, but there's nothing really built yet. How do you think about like, here's a roadmap, here are the tenants, if I were to join, here are the first five things I would do and why. What sort of comes to mind for you?

Stephanie: So the first thing I think you need to ask is, is now the time. And some of the things that you look for in, you know, when to start your customer success organization is, where are your early employees spending their time? Are they spending a disproportionate amount of time solving problems for customers, answering questions, getting them up and running?

And I think that's a really valuable way to get a business going but when you have a meaningful volume of customers you end up spending, say, more than half your day just resolving problems or getting going in your product. Then that's the time that it makes sense to consolidate that work into a couple of individuals.

you know, what, what you need in those early days are people who can work really quickly, Are really curious about your technology and are really curious about the customer. You know, customer success is all about getting your product into your customer's hands as fast as possible.

And so all of those qualities of your first customer success people, I won't call them CSMs cause I think it can take a lot of forms, is you need people who are really fast at doing that really well. The second thing you need in those early days is you need people who communicate exceptionally well, because they're the ones who are going to be your feedback loop to product engineering and even leadership. To help you understand what is it that you need to be doing with customers?

Um, what do we need to build next? Where are they running into problems? What new workflows do we need to build, et cetera. So your first step is to think about, you know, what are some of the key skills that you need in your first CSMs and then go hire them. I would start with one, maybe two.

Of the questions I get a lot is, do you start with industry specialists or do you start with people who are really technical? And I think the answer to that lies more in what your product is and customers are doing with your product than it does in like any one, you know, formula.

And I think as you grow, I think it's actually nice to have a mix of both industry people and technical people. But you know, you want to hire for folks who, are tech curious, who may have some understanding of the problem that your customer is trying to solve, who have a demonstrated bias for action and can communicate well and collaborate well internally.

So that's where I would start. 

Brett: do you generally hire people who have done customer success in some capacity or not?

Stephanie: I've done it both ways. These days, you can find people who've done it, and they often can get going a lot faster and are going to have a much better perspective on what's, you know, step 345 than somebody who's never done it before. Now I would bias toward looking for people who've done it in startups in a startup environment.

That said, again, you have to look at what is the problem you're solving for your customer. And if it's very industry or function specific, sometimes you're actually going to get a better result by finding somebody who's done that industry, knows the industry well, or knows the function well, because they're going to be able to speak to the customer's use case really quickly.

Uh, and they're going to be a lot more valuable in that product feedback loop. So I don't know that there's one black and white answer. Instead, I would look at, you know, again, what are you solving for for the customer and what are you solving for internally in your business? Ideally you can find somebody who, kind of has a mix of all of that, but I think you, you can't go wrong if you, um, just pick one or the other and just go all in.

Brett: Can you talk just a little bit more of this question about industry versus technical? if you're a founder and you're, you want to answer this for yourself, what are some of the questions you're asking or what are you looking for in your business that would point you in one direction or another?

Stephanie: So again, it comes back to what is the problem we're solving for in customer success. We are trying to get the product into the hands of our customers and getting them using it. And if the path from, yes, we want to use your product, to we are actually using the product and, making some change in our business, if that path involves a deep understanding of the use case, because it's specific to retail or specific to the accounting function you know, specific to, uh, a sales team, then having a deep understanding of how the customer is going to use the product so I guess the question is, how deep do you need to be on the use case or the team using the product in order to help that customer get to value quickly, but to usage and value quickly?

Similarly, if the path from, "Yes, we want to buy this" to, "We're implementing this" is very technical in nature, meaning there's a lot of integrations, you have to do a lot of data transfer, we have to manipulate a lot of data that is in itself a technical activity that you don't necessarily want to ask your customer to do in the early days.

And therefore I would look for a profile that's more technical in nature. So. What's the problem that you're solving for? And, what work can you rely on the customer to do versus what do you need your customer success team to be doing on behalf of that customer to get them using your product?

Brett: Do you always start with IC, CSMs as your first hires, or are there some conditions where you would hire a manager type or a head of CS to sort of kick things off?

Stephanie: I am biased toward hiring ICs first. Ideally, you can find somebody who either has been a manager before or has aspirations to be a manager, or, you know, if you can assess for leadership qualities in your early interview process as somebody who has the potential to be a manager. the reason is because you need people who are doers. You need people who are going to go super deep on your product.

They may turn into the future manager of that team, but what you're optimizing for in those first hires are people who are going to run fast and run straight for the customer, and be really clear on those internal feedback loops. When you have only a handful of hires to make hiring those IC's first, to get them moving is, is super important. Now, if you've waited a really long time to hire your first customer facing, like, you know, either it's a support team or CSM type role or an implementation team, and you know that you need to hire five people in the next three months, then in that case, hiring manager first can be helpful because if you get the manager in seat, that gives the founder more leverage to have the manager make all the IC hires.

The trade off there is there's just going to be a bigger lag and how much of the tactical day to day work that the ICs, you know, once it just takes longer for them to get hired. So, you have to wait a little bit longer before you see that impact.

Brett: How do you like to set up the interview loop for these first couple CSMs? Can you kind of give some specifics about the most important part of the loop and maybe how you get at some of those things, whether it be biased towards action, um, really exceptional communication skills or those type of things?

Stephanie: I think you need, at least one of the founders on the loop. Uh, I think you need the head of product and or the head of engineering and you need somebody from a go to market function. And I'm assuming that all of those are filled. I bias in the, or in the early days, if we're talking like sub 20 people at the company, I bias toward the most senior leaders who can make time for the interview. 

Brett: And is your recommendation to always hire your 1st sales or go to market folks before you hire your 1st or is there some order of operations there? 

Stephanie: I don't know that there's a rule of thumb that I fall back on, especially because I see so many really early stage companies where the founders are leading sales for a really long period of time for some strategic reason. As companies scale, the CS team scales after sales, after marketing. The one thing, that is important to, to keep in mind is if you have a really short sales cycle and the founders are able to get, if it's a founder led sales motion, they're able to get a high volume of customers in the door quickly, then that means there's a high volume of customers that need support.

They need help. And so in those cases, I'd say, you know, it's, it probably makes sense to hire somebody to be customer facing just on that delivery and support side pretty early on.

So in any interview loop, I like to include, somebody who has the closest understanding of the current experience of the customer. And so that usually is a founder or a co founder and somebody in either product or engineering. So that's why I include them. Somebody who has an understanding of the culture that you're trying to build in the business.

Usually those are co founders. And then somebody who has some exposure to what this function can look like in the future stages. So that depends on, you know, who in the business has actually seen, startups before, this industry before, this product area before. The way that I like to get at like drive or bias for action is to ask for specific examples.

And usually people who are looking for IC roles in these types of businesses, can offer, well, they should be able to offer some really good examples of places where they saw a problem and then fixed it on their own. Or they, saw a workflow or a process that involved multiple teams across a business that was broken and took steps to actually foster change. Sometimes they could make the change themselves. Sometimes they could escalate it to get some help from more senior people. I also look for customer empathy and this is, um, I do have one sort of heuristic for hiring sort of early stage and or more junior customer success, support, or implementations teams. Which is, there is an inherent choice that sometimes is subconscious, that people often make pretty early in their professional life. 

there's a pattern I've seen, that sometimes can be a really good tell about somebody's orientation toward customer service. you know, early in somebody's life when they're starting to take on their first odd jobs here and there, either as a teenager or through college or whatever, people often have an opportunity to take on some kind of a customer facing job.

And that can be very instructive for a person, whether they like working with. The general public or customers or they don't. And if people continue to opt in to odd jobs or part time jobs or even career modes that include a customer oriented, uh, experience, then that tells me that they are a customer oriented person.

I've hired people who've never done anything customer facing into customer success and support roles, and they find it. really jarring. They don't like it. They don't actually like being in front of customers and taking, you know, tough questions and solving tough issues. And that doesn't mean that those people aren't good for our company.

It just means that they don't belong in a customer facing role. So that's sort of a heuristic that I like to use. You know, has somebody done something customer facing early in their life? that gives me a clue about their customer orientation.

Brett: do you end up exploring a lot of that work? Right, I assume there are people that did customer facing jobs that hated it you know? You kind of want to get to the bottom of that.

Stephanie: I, the best way to get at that is with a scenario. My favorite scenario, is, you know, to offer something like this: so Brett, you walk into, uh, your office in the morning and, um, it's, you know, you're on the early end. It's 7 30 a. m. And you look at your phone, it starts blowing up with some customer face and some customer says, "Oh my gosh, there are bugs all over our dashboard. We can't log in."

And then the phone starts ringing. And then you start hearing from the sales rep. And then you start hearing from the support team. What do you do? I don't expect a perfect answer, but I do when I'm looking for, you know, problem solving and ability to like handle pressure, a bias for action.

I'm looking for somebody to sort of break down the problem. "Okay, what's going on. Let me get on the phone with a customer, really get clear on the problem that they're having. Let me escalate to the people who are going to be part of my solution. And then let me build a plan for what I'm going to do to help this customer."

And, you know, the answer is not quite that. framework driven, but those are the kinds of clues I'm looking for. What tells me that somebody may not be a fit is like if they scoff at the question, or if they, you physically get flustered at the prospect of getting bombarded with customer questions when they don't really have an answer. Or, somebody who doesn't think that, "Oh, I have to involve other people to help me solve this."

Those are some clues that maybe being in a customer facing role is, is, may not, maybe not right for them.

Brett: If I were to listen to the last 200 interviews you've done for people that are in the shape of the CSM you're talking about for kind of a zero to one CS function, are there other types of questions that you constantly go back to over the years?

Stephanie: Yeah, there are three. So the first is, " Think of a, a brand that, you know, likely a consumer brand that you think delivers excellent customer service." And oftentimes they'll say something like Nordstrom, Four Seasons, you know, My Corner Deli. And I'll say, "Okay, tell me the, the aspects of that great customer service and what does it feel like when you get great customer service and what does it feel like when it breaks?"

And that tells me like how empathetic are they to a given person's experience and how like reflective are they on their own experience as a customer themselves in some context. So I love, I love that. We use that one very often. The next go to for me, especially in very fast growing organizations, both for ICs and for managers as I'm really looking for some self awareness because that drives leadership behaviors, that drives an ability to work well with a very varied set of people internally, and that also gives me a clue about somebody's ability to grow with the organization.

So my question there is, " Tell me about, the most impactful piece of feedback that you got in your last performance review." Or maybe I'll say "In the last two years", depending on their career level. And that's all they, that's all I tee up and whatever their answer is. Usually people go to like negative feedback and then I'll dig in and I'll say, "Okay, so how did that land with you?

How did it feel? And then what action did you take?" But then I don't leave it there. I then say, usually it's like a negative feedback. And then I say, I want to actually know the other side of it too. And I say, " So you just shared with me some negative feedback or like an opportunity for improvement of feedback that you got.

Tell me about some positive feedback that surprised you and how did that land with you and what did you do with that? And how are you leveraging that today?" And that gets to, again, like All the depths of self awareness that can be really useful in a growing organization. And then my third favorite question for hiring managers and leaders, this is a little bit of a, um, secret and Stephanie's toolkit.

So anybody who, um, might listen to this might, uh, be prepared for this question. I ask a person, I'd say, for example, "Brett, I say, okay, you're interviewing for this director role on my team and let's say instead you're, you know, tomorrow you're waiting for whether or not you're going to get an offer from us, but instead of hearing from me, you actually hear from your boss's boss.

And your boss's boss calls you and says, guess what? Your boss just won the lottery and resigned. And I want you to take over this team. And I want you to come to me in a week and tell me, here are the things you're going to do the same. And here are the things you're going to change. Good luck. So Brett, what would you say in that meeting in one week?

What are the things that would, you would put on your keep list? And what are the things you would put on your change list?" So I'd let the person answer my follow up question to that, really looks at the things that the candidate might change. And I would say, "Why do you think those things are not in place today?

What do you think is standing in the way of that, you know, whatever your feedback is or whatever change you want to make, like, why isn't that happening?" And what I'm getting at with that is I'm looking for people who think strategically, which means they're, they look for clues outside their own world to understand what, what should happen, what can and should happen.

So I'm looking for people who think system over subsystem. So subsystem thinking typically looks like, well, here's the problem I'm facing in my team, and I think my boss should be Uh, directly addressing that system level thinking is I am facing this problem, but my peer is facing this other problem. The other problem and the one in the team over those are more important to the business.

And so that's why we're focused there. The things that I'm facing aren't actually important. Or vice versa. The things that I'm facing actually do have a bigger role to play in this business. And I think we can and should, adjust our approach, but it's about people. I know I look for people who can think beyond their own world and look for both context and reasoning behind the decisions that they make.

Brett: Do you often create some sort of practical or job simulation or most of your interviewing is behavioral?

Stephanie: I almost always do a job simulation type exercise for leadership roles. That's evolved over the years and I can talk to you about what those look like. For IC roles, I do like doing some kind of exercise. oftentimes it's a data analysis exercise. It can be a product demo. Product demos are really common in, in the world of customer success, management and hiring. You know, in implementation, like an implementation specialist or implementation consultant hiring, we'll do like project management, simulated exercise for a support rep, uh, we'll do, you know, how would you respond to a customer in given situations, exercise, like looking for actual evidence of writing and ability to understand, like how to unpack a problem.

So for leaders, I take, um, slightly different approach depending on the level. So for managers, I look at. A pretty simple 30, 60, 90 day plan and for brand new managers, I actually try to give them a little bit of a clue and I say, okay, I want you to talk about your 30, 60, 90 day plan along the lines of people, process and product.

Walk me through where you would spend your time. I can also, I sometimes do that same thing at the director level, but for senior level hiring, I actually ask for a presentation of some kind. And that can look like a presentation of a business problem that we're facing or like a prompt that includes a business problem we're facing and then asking the candidate to unpack that problem and offer an approach to solving it. I don't expect an external person to have the solution. in other cases, I have asked people to bring content that they know well from a different context and present that. If somebody was recently a grad student, bring me one of your grad student projects and present that information to me.

If somebody did a big project in a previous role that has information that is not proprietary, present that project to me. Again, what I'm looking for there is how do people break down problems, how much subject matter expertise that they bring to the table and how do they present their ideas and solutions in a live setting.

Brett: Going back to the IC CSM type role that you're hiring in the early days of a sort of post product market fit, but very early stage startup. When you think about the folks that generally don't work out, you know, you went through an interview process. You were excited about them, but they were not successful.

Do they tend to group in very specific sort of fail case reasons, or it's sort of like a long tail of a hundred different reasons why Bob or Sally or whomever didn't work out?

Stephanie: I've seen a couple of patterns. One we touched on earlier, which is people who actually don't have a lot of depth in customer facing roles, and it turns out they don't really like working with customers, and so they can be abrasive with customers. That's one of the reasons why I look for previous experience with customers.

The second is people who have a hard time balancing customer interest with business interest, who get really bogged down in the volume or the pain that's coming in from customers. And one of the big roles that the customer facing teams play is funneling all their issues into the into the organization, helping them get solved.

but sometimes people can get overwhelmed with the volume or they can get really frustrated when we can't solve the customer's problem immediately. that ends up being, a problem because they can't balance multiple interests at one time. And they end up with like, um, sort of a heavy heart almost.

the third is people who have a hard time taking feedback. Being in a customer facing role in a very fast moving organization, especially in the early days, is hard. And nobody's perfect at it. And it's really important that somebody, an individual can take feedback when they're told, Hey, I really need you to prioritize X and not Y, or it's really important that we answer customers with this tone and not that tone.

Or when we're escalating issues internally, it's important that we approach our internal collaboration with you know, a very partnership driven mindset, not an accusatory mindset. And I find that people who can take feedback, both like tactical SEALs feedback and behavior feedback do better. And people who have a hard time with that, don't grow and evolve and they end up either not evolving with the organization or they end up, in like interpersonal conflict internally.

Brett: When you think back to some of the early CSMs you've hired in your career that didn't come from a traditional background, are there any interesting stories that come to mind of people that ended up being sort of top 1 percent CSMs that If you were to look at their LinkedIn, wouldn't make sense?

 One of my favorite CSMs who is now a very senior leader in a customer organization was an actor. You know, was actually went to Broadway to train to try and be on stage, and did a quick pivot when he couldn't make a career of it and, uh, ended up on the support team, then became a manager, then became a leader there, then went to the customer success side.

Stephanie: But the qualities, that he brought to the table was a very strong sense of, entrepreneurship, self awareness, and self accountability, and a really big curiosity in others. So he became the person that, went really deep with customers to understand what is the problem they're really trying to solve and how can we build our systems and processes to support those, customer needs.

And he was one of the first people to really help us think about, the concept of like jobs to be done, and oftentimes we talk about jobs to be done in the world of product, but it's very similar in the world of customer delivery and all the teams in the customer success organization, because there are jobs that we need to build teams to deliver.

Another woman, uh, in my first software startup actually came from a nonprofit fundraising. Her interest in the business was because she really wanted to get into, I was in a climate tech business at that time. She really wanted to get into climate tech the skillset that she brought to the table was number one, a sense of real maturity and number two, an ability to talk to customers about, like inspiring change for them and their organization with our product.

And she had a very calm demeanor, and an incredible bias for action, which is something I was a little bit worried about hiring somebody from nonprofit. But she, uh, brought a very strong sense of self awareness and an ability to relate, really deeply relate to customers and what they're trying to do. And then of course use that skill to foster the change we needed them to make internally at the customer. And then the third example, you know, I don't remember where he was first, but, we hired a CSM at Box in the very early days who ended up being the most skilled CSM in the entire organization and he was the person who the product team always went to. And the skill set that he brought to the table from his early career in a non tech space was, deep curiosity on the technology, and he became very conversant. And he actually thought about maybe going to the product team and taking a role there, maybe going to like a super tech, you know, like tier three technical support, maybe taking a role there.

But what he decided was he really liked understanding what customers are trying to do and pairing that with all of the features and functionality of our product. and that made him both valuable to our most strategic customers, but also a really valuable asset to our product and engineering teams.

This particular person I'm thinking of also had a very strong commercial mindset, which is hard to find in people who also have some of these other skills around customer curiosity, deep customer empathy, bias for action, where, people who, like to help customers build their programs alongside our software, Sometimes they have a commercial mindset and sometimes they actually don't like talking about the numbers with customers.

They feel like it's a sort of the fox guarding the hen house moment. But when you have people who are adept at understanding the problem, customers are trying to solve, talking about the value we're delivering, those CSMs can actually be incredibly valuable because they can solve all, they can do your renewals for you, which is great.

Brett: To close out sort of this thought on the first couple CSM hires, how much do you care that they have an aptitude to sort of build the early systems? You know, obviously, maybe not manage, as you said, manage the entire function, but upon one end, you kind of have a CSM that's a firefighter, getting in there, working with customers, onboarding them, trying to make them successful, handling bugs and issues that come up. And on the other, you have somebody that has an eye towards the system that you're going to build as you begin to scale. Do you care much about that ladder or there's just so much firefighting you should focus there?

Stephanie: care a lot about that, but not in my first hire. The first hire does need to be that firefighter bias for action. I think by about your third or fourth, you need to make sure you have that skillset somewhere in your team. And you can be more thoughtful about making sure you, either that skillset emerges from people who you've already hired, sometimes that can happen where there's like a surprising skillset you didn't, you didn't know you were getting, or you go out and look for people who have built systems or who have a more systems mindset, or even in an interview process, they're able to break down a problem in a methodical way.

Those attributes become more important. But it's important to talk about like, where does process come in, in the early days? And my perspective, we've talked a lot about people. And if you think about process, which is sort of a, you know, important category, I'm actually less concerned about great process in the very early days, with two caveats.

There are two places where you do have to build some templatization or at least some consistency, uh, and maybe implement some systems. One is with support tickets. So you need, or some way of customers, like, reaching you if it's through a slack channel or through if it's like an actual support system. You need a systematic way of collecting that customer feedback that's not just an email to a CSM. And especially as the volume ticks up that becomes more important and you also need a way of categorizing the questions that come in so that you can use it to understand like what's happening with your product? Where do you need to shore up features? Where do you need to get more, you know, knowledge articles written or whatever.

So support is like one place that you start to build some process. Like what I mean by support is, what is your intake process? And your, uh, customer issue resolution process? The second place where you need to start to build some processes with implementation and onboarding. And this is actually, a mistake that I see companies make is that they don't codify the 10, 15 step process of getting a customer onboarded.

If you don't have that mindset early of let's templatize this, let's create a checklist, your business can end up really big and you actually don't have a consistent way of onboarding customers. And you can end up with like a really weak understanding of what it takes to get a customer to value.

And what's interesting about focusing on these two processes is that as you start to scale up, you need to think about role specialization. Those, those are the two places where it makes sense to start specializing your roles, support or implementation, because those are the things that are very high volume and highly repeatable.

Brett: What is a V1? Again, it's super early days, a couple million dollars in recurring revenue. What do you think a V1 of the implementation process looks like?

Stephanie: I think it's in a Google sheet or maybe a Monday. com workplace. It's, it's a templatized, you know, 10 step process. The details of that implementation are different depending on the product, but it always includes something like a kickoff call, a requirements gathering conversation. ideally a conversation about who is involved in the customer side and who are going to be the users? A conversation about what are the integrations we need to do.

And then it's planning out each of those steps. What data do we need to gather and who's going to, who's on point to actually deliver those files or to build that API? Next is, you know, who's on point to build the communications, the actual communications that are going to go out to our users when we roll out this product? The last step that often gets missed is how are we going to measure success? if organizations can get in the habit of asking this question from the very, very early days of the business, they are going to be set up way better when the business starts to scale, because you're going to have a stronger understanding of how, like, what is the path to value for a customer.

And you can start to build in like more value based conversations with customers in a way that avoids the CS team being really reactive and only like, ticket focused. But oftentimes that, that question gets overlooked because it's hard to define. Like, what, what is value? And I think even just keeping it simple and very qualitative is sufficient, but having the conversation of what are you trying to achieve with our product and how are we going to know we got there?

And if you can do it with data, great. If you can't, that's okay too. Just make sure you're committed to having that, like, regroup conversation down the line.

Brett: Are there metrics you tend to put in place in the early days of CS that you think matter? Or it's more qualitative until you start to really get to significant scale?

Stephanie: There are always metrics that matter, no matter what stage you're at. And I think this is again, like a mistake, especially that early career CS leaders make is that they assume that the data doesn't matter as much, or they just don't put the time and effort behind making sure they're tracking the right data and holding the team accountable to outcomes.

The number one most important metric is some measure of customer health. That can be a really complex answer in a late stage business, but in the beginning, it's about product usage. And product usage alone is never sufficient, but it is an, a critically important starting point because if a customer isn't using your product, they're not getting value.

It it is a very simple equation. And so You know, usage often looks like, depending on, you know, the business model, sometimes it looks like, how many seats have you purchased, versus how many have we deployed, and how many of those deployed seats are being used? It's a three part equation. As long as you start there, that is really good to drive action with your team.

And so in any given day, if a CSM or an implementation manager or support rep doesn't know what to do, the first thing they can do is go look at their customers to understand who maybe has low usage and start a conversation with them. It's a very action oriented metric. The second thing is, is certainly renewal rate and understanding what is our retention of the customers that we currently have. Um, and Ensuring that, that the customer success organization, even if they aren't the ones writing the commercial transaction, they understand how much revenue are we retaining. Because the whole value of this organization from implementation to CSMs to support and everything in between is to ensure that we're delivering value for customers. The best measure of that value is when a customer renews and ideally grows. In later stages, you can start to look at other metrics like NPS, CSAT, time to launch, and your implementation. Those, uh, can be great metrics. Those sometimes can be, you know, easily gamed, so they don't necessarily provide the right insight for leadership or, or even individual CSMs on what actions they should take.

I worry less about those in the super early days. I mean, as long as teams are focused on usage and renewals, like I think they're in great shape.

Brett: How do you think about where renewal sits between CS, or conventionally it would be sales?

Stephanie: This question always comes up in the world of customer success. And my dividing line is if renewals are primarily just that, a renewal conversation where there's a quick, you know, exchange of papers, a quick conversation, if there's a change in price, but there isn't a detailed negotiation or any complexity with that transaction, that renewal process process should at minimum sit under the CS leader. It can also include sitting in the world of the CSM, especially in early days. However, if that moment of renewal is a really important moment for expansion, then that then becomes a very different commercial conversation and is more about discovery, negotiation, solution building that lives in the world of sales.

And so the question is not, should renewal sit with CS or with sales? The question is, what does the renewal moment look like for a given customer? With that in mind, which team should be closest to that activity? I've gone back and forth on this over the years. And I think the reason why I initially rejected the idea of renewal sitting with CS is because we, in the world of customer success, we really like to hold true to the fact that we are the advocate for the customer. And it can feel when you start to have a commercial conversation with a customer that you're no longer the advocate of the customer. Instead, you're just the advocate of your own company.

And that can get in the way of the relationship with the customer. And my thinking on this has changed. One, because if we're talking about value delivered in the right way over time with a customer, if you're a super small company or you're a really big company, then any conversation about renewal is just an extension of that value conversation.

And it's not a complex commercial negotiation. The other thing is that the whole CS organization, all of the pieces that are built to touch a customer are built to deliver on what the customer is trying to achieve with your product. And so if you have accountability for all the leading indicators, things like adoption, customer satisfaction and accountability for the outcome, which is renewal, then that creates the right combination of incentives for the entire team to be doing the right thing for the customer.

Brett: What about where CS should sit more broadly in the org?

Stephanie: That also is dependent on the phase of the business and the makeup of the leadership team. I am a big fan of say the CS organization reporting right into the CEO, because in those cases, the CEO is really close to the customer experience, no matter what face the business is in super early or operating at scale.

So it puts the CEO right in like in direct line of sight to what's happening with the customer business, and it creates a sense of real accountability and drive for the whole customer organization to be delivering for the mission of the company. The alternative is to have the CS leader report into the CRO, which can make a lot of sense, especially when you have a CRO that is equally focused on renewals and growth.

The challenge is, in a phase where you are all about gaining market share, and most of your growth is coming from net new customers, you need your revenue leaders focused there, not on, you know, retaining customers that can be a little bit slower moving, that can be more about ongoing nurturing and less about hunting.

And so it has to do with like, what do you need your sales leader to be doing? At some point, every SaaS business shifts where most of the revenue is coming from existing customers. your C, if you have a CRO where the customer success teams report up to the CRO and the sales teams, in that world, you, you have a, much more stronger alignment of incentives for ensuring that customer, you're retaining customers in order to make your number and you're growing new customers in order to make your, in, uh, in order to make your number.

.

Brett: Why is it that CS almost never reports to the chief product officer or VP of product? It's a little bit counterintuitive, but I'm sure there are some companies that have been doing this, but it seems even more tightly coupled to the product experience and certainly CS is one of the primary inputs to product roadmap.

Stephanie: That's a great question. I don't know that I have a great answer for that. I have seen a couple of companies where they name the customer organization, customer experience, reporting up to the CPO or whoever's like head of technology. I don't have a lot of feedback on whether that works or doesn't work.

From my perspective, I think that's challenging because customer success is core to the go to market motion. And aligning CS at minimum to the revenue team, and putting it in line with marketing creates a flywheel for your go to market team in a way that I think would be challenging to achieve if the CS organization were reporting up to the head of product.

the organizational problems you're solving, the opportunities you, face as an executive, the alignment you're trying to create in your organization looks pretty different in a product and end organization than it does in a customer facing team. That's part of the go to market play.

and I think it's just, it can become kind of an unnatural alignment of incentives and outcomes. If you're trying to solve for collaboration across these organizations, I think there are other ways to solve it. You know, if not in a reporting structure, then certainly in goal alignment, project alignment, outcomes alignment that you can, that you can achieve some of those objectives by, you know, that you need to achieve by aligning your customer team and your product team.

Brett: Do you have any thoughts or experience with sort of, when you see that there's an adoption problem or a churn problem, how do you get to the root cause if there is a CS problem we have or a core product problem given in so many cases, I would imagine that there's this blurring of responsibility?

Stephanie: So when you're looking at churn, it's really important to be pretty methodical about unpacking why is churn happening. And inevitably adoption is part of your churn problem. But ideally you're capturing some data when you lose a customer, whether you lose a portion of a customer or all of a customer.

And if you don't, if you don't have that data, then you need to go out and collect it. But you need to start to look at and capture what are all the reasons why customers are churning. And you end up with a list of usually between six and eight churn reasons that look like sometimes it's M&A, or loss of budget, or a customer didn't see value, or we changed our stakeholder.

And from there, you actually then bucket those further into controllable and non controllable churn reasons. And then you look at the controllable churn reasons and understand what are all the things we can do to address these. I find it really useful if you've got a really big churn problem to be really methodical about analyzing what's going on before you jump into solutions.

Because from there you can pick which are the solutions that are actually going to get us the biggest impact and which solutions involve multiple teams. 

Brett: When a customer churns, what should a company be doing after?

Stephanie: Well, there's what should a company be doing and what is the pattern I see? the pattern I see is everybody feels really sad and then moves on to the next thing. And of course, that's not what companies should be doing. There should be a r etrospective, understanding why did the customer choose to either stop solving the problem we were solving for them or choose a different vendor for to solve the problem that we were solving for them.

And the answers to those questions will help us design a better product and design a better delivery mechanism. What you can find is or what I often find is, you know, churn usually has something to do with product adoption, relationship management, which really means we aren't talking to the people who are making the decision and making sure the people who are making the decision know the value we're delivering.

And sometimes churn is because of a massive change in priorities, on the customer side. This is actually a really important thing, especially in a, Cycle where everybody's in a tight budget is knowing if your product is solving a nice to have or a must have problem.

If you know that you're a nice to have, then that upfront longterm value conversation and those relationships are critical because that is what is going to keep you in play with that business, versus if you are a must have platform solution, it's actually a lot harder to rip you out and replace you or just decide not to solve that problem. And I think you, design your delivery mechanism, your value journey differently based on, the problem, you know, you're solving, like how, how big is that problem for the customer?

Brett: When someone churns, is there a specific set of questions that you're trying to answer or that you're trying to go to that customer with to get answers?

Stephanie: Yeah, I think there are kind of three ways I would bucket the types of questions you want to ask a customer after they churn. The first is sort of the obvious one, which is, why did you choose some other solution? And that other solution could be a competitor, or it could be they decided to do themselves or do it in spreadsheets or whatever it is. And allowing them to be very honest with you about why and really trying to get at, was it because of features? Was it because we didn't do a successful deployment? Was it because people were not using the product and does a customer think that they're not using the product because we didn't train them properly or because the workflows didn't make sense?

You're trying to narrow in on, is it something about your product? Or is it something about your sales process? Your delivery team? Or your price that made the customer question whether they wanted to keep going? So that's question bucket number one, why? The second is you want to understand how did they get to the, to the decision?

Um, that can give you clues about other companies in the same industry, other companies of a similar size, these are, you know, different types of things we need our sales or renewals teams to be doing, uh, on path to renewal, who was the decision maker? How did they collect information on whether this product was adding value? How did they collect information on who was using the product? What are the alternatives out there?

So it's that process. It's sort of like a reverse medic, if you will. And then the third set of questions you want to ask about is, what are the alternatives? And really understanding how the company evaluated those alternatives. So are those alternatives, again, just using internally, internally built tools? Competitors? Maybe what sites did they go to?

Who did they speak with? Who was involved from our team in that process? Et cetera. All of these questions are great. And it would be amazing if you could get every customer to, like, give you the very detailed list of all of this stuff. I think anytime a company embarks on, like, a, a retrospective interview, with a customer, you just have to approach it with a lot of respect and a lot of appreciation because a customer, in most cases, had to make a really tough decision.

And it's hard to stand in front of people you've worked with for some period of time. You know, they're, they really believe in the founders, or they believe in your mission and they had to make a tough call. So just recognize that there's sort of a human element of this conversation, um, and just treat it with a lot of respect and gratitude.

Brett: Is there anything you figured out about getting customers to be honest with you? 

Stephanie: I have one trick on this and I use it in multiple contexts, but it really comes back to understanding trust and people are honest when they trust you. And one of the best ways to build trust is to let the customer know they're being heard. So rather than going in with like a big panel of senior people or people they've never heard or never even seen before, go in with people that they know and or go in with people that they've at least met before and do the minimum number of people on the conversation.

They don't want to be bombarded. Make it feel a little bit familiar. The second thing is be prepared. So you go in with, "Here is all the things that we know about your deployment with us." And include like the brutally honest stuff. You bought a hundred seats and you deployed 20, or we really botched the implementation, or you were sold on this feature set that we didn't end up rolling out for two years, you know, be super honest and also say things like.

Here's the specific feedback we've heard from you over the year or the years. Use their language and that really diffuses the wall between you and the customer because when somebody feels heard, they're more likely to lean into the conversation in a very honest and trusting way rather than saying open ended, why did you churn or why did you not renew?

You can say, "Here are all the things you've told us. What am I missing?" And, "Okay, if I were in your shoes these are all the things that I was experiencing as a customer, this is the conclusion that I would make. Is that accurate? Is there anything you would add?" So sort of like lead them into the conversation.

And I find that that actually warms them up to be a lot more honest and open.

Brett: When you think about CS in the early days, we haven't talked that much about the linkage between CS and product. I assume it's maybe somewhat informal in the early days. But you have your first couple CSMs. They're spending time with customers. They're onboarding, they're problem solving. What does it look like when CS is really well connected and in sync with product?

Stephanie: It is very informal, it's very frequent, and it can feel a little bit scrappy, but that actually is really fun in those early days. And that's the thing that I like to lean into when you're building a CS organization, because there's nothing more exciting for a CS rep, whatever role they're playing, if they're playing an implementation role or success role or support role. For them to go to the product team and say, "guess what? Here's what I heard from my customer today. Can you help me solve this problem?" And have that, product manager jump in like into the pool with them to like figure out what to do and then present a solution to the customer. That's really fun for people because it feels collaborative.

It's one of the reasons why. you know, we over index and hiring for a collaborative mindset, uh, in the early days, early and kind of young CSM teams. I don't like to over engineer the process of collaboration with product, but I do like to make it like a regular part of a weekly or sometimes daily cadence where, it can, it can look like this, on Monday morning, the product team has their own standup.

The CS organization has their own standup. On Tuesday morning, it's the product and CS standup that comes together. There are actions that are assigned. there are meetings that are set up for the week. And then we have a regroup on Friday where we talk about what was resolved and what's still open.

Those types of processes, if you can build them early, they take multiple shapes, but being quite prescriptive about exactly how these teams are collaborating can foster a really strong sense of connection and really like get that flywheel of feedback loop going. The other way that, this collaboration can be really helpful is when, when the CS organization is the entry point to customer conversations for the product team.

And that's really, really valuable for product to get feedback, to talk about potential new features, to talk about roadmap. To talk about use cases that we are or are not addressing, and the CSMs often, especially if the sales team is not involved in an ongoing basis, the CS team is the entry point into those customer conversations.

As the team grows, you sort of end up with sort of a coordination problem where not every product manager can speak with every CS rep, especially when you, you know, you have a dozen, maybe 15 reps on the CS side, and only a handful of product managers. And so when that starts to happen, you need to be a little bit more methodical about the processes you set up for feedback.

Sometimes that can look like very formal intake processes for, uh, feedback coming in from customers or resolution. Sometimes that can look like, a direct line between say the support team and the engineering team. Uh, sometimes that can look like, a customer product feature meeting that happens say once a month that includes the sales team.

But. You know, I find that organizations kind of know when they need to get a little bit more methodical, a little bit more templatized and, and how they run their feedback loops with product because it just starts to feel really messy and confusing. And so the way you solve that coordination problem is just getting a little bit more, planful and more process oriented and how you collaborate.

Brett: in this sort of theme of rituals, are there any other things that you tend to do across the companies that you work at or when you've built out CS functions similar to what we're talking about that you think might be useful? Sort of anything that you would put in these like little tactical ideas that if someone's building out CS, If they just did these little things, they would probably be better off.

Stephanie: So as an organization scales, it's the rituals that sort of become part of the culture of the team, that make the experience of being on that team and being on the receiving end of the great work of that team that I think, can make a, a huge difference in everything from results you're getting with a customer to what is the reputation of the CS organization within your, within your company.

One of the things that I find so impactful, is learning to be very customer centric from the very beginning. Like an example of this is, uh, Aaron Levie at Box. So from the very, very early days he talked about customers using box on a weekly basis. Every time the business was making a decision, um, he asked any executive or any IC or any manager, " What's in it for the customer?

What will the impact of this decision be on the customer?" And he made a real point of including customer stories and every time he got up in front of the business and I think that when you build this kind of customer empathy in these small moments, like little rituals, once a week you send around a customer story.

Every time you get in front of the business, you talk about a customer outcome, You know, you ask executives to go get in front of customers and talk to them on a regular basis. if you do this early, it builds customer empathy through the entire organization, through the whole life cycle of the business.

It's actually really hard to teach this as like the culture gets ingrained as the business grows. But when you have customer empathy and like a perspective of the customer that infiltrates all sub-processes of your business, I think it makes a huge difference as the business scales.

Another ritual I really like is sort of forcing functions to get teams together. So we talked about, like a product feature request meeting where you get the CS team, maybe the professional services team, the support team, maybe somebody from CSM together with product and engineering and maybe sales.

And you talk about what is the top 10 feature requests we're getting from customers and you talk about what's the impact of these. And you kind of develop, a two way feedback loop that the product team can then go use to develop the product roadmap and the customer facing teams can go and talk to customers about and say, "Thanks for the feedback. Here's what we think we're going to do. And here's what might be coming later." But ritualizing that and like making that a regular touchpoint is super important. Similarly, if you can do get in the habit of doing like an escalated accounts or a red accounts meeting together with sales, that also can be, or become a really good touchpoint to talk about the real issues and force collaboration between teams to figure out what kind of resources we need to go and solve these problems.

these both are sort of heavy handed, but these really important really early in a business. Because it's a habit of, almost, I don't want to say force, but like, it's a moment that people come together to talk and solve problems together. And that can not only drive a collaborative culture, but it can get you, like, really solving big problems early.

And then the third thing, is, I really like rituals that foster like connection and communication, especially as a business grows, or you start to think about international expansion, you have like a big coordination problem amongst people and your CS organization is sort of at the end of the line of a lot of work and the CS team start to feel a little bit left in the dark. You know, the sales organization gets the big like celebration emails when you know a deal lands.

So often the CS team doesn't get celebrated when a customer launches, or when we get a great story back, or we're showcased at their, you know, big company meeting. And so making sure that you're building in these moments to recognize the teams that are doing great work on the delivery side, I think can be really impactful.

Even in the very beginning. Again, it's like these, you know, if you build these cultural habits at the start, showcasing the great work of, you know, the, the people who are talking to customers every day, then that becomes sort of a habit in your organization and can really foster a lot of connection, among people, in in all teams.

Brett: Are there other questions you tend to see pop up all the time when somebody is doing zero to one CS building, or when you chat with founders, they tend to ask this or this, that maybe we haven't hit on yet?

Stephanie: I think the one that I often get is how do you know how big your team should be? Um, what's the right ratio?

The answer to that question is different depending on the team you're talking about. So for support, real technical support, which is break, fix, managing high volume tickets or, you know, in inquiries, uh, and implementations, which is basically repeatable processes. It's a lot easier to figure out how many people you need.

That is like. Honestly, it's a math problem. You look at what's your capacity in a given day, how long does it take to do the task at hand? And you, put the two together to figure out what is the capacity you need and that translates to number of humans you need on the team.

In the world of CSM, it's a lot less black and white. There are rules of thumb, mostly by segment, but it will depend on what's your ACV? What stage of business are you in? Are you operating in multiple countries, multiple languages? how much help and support does your customer need? And how many extra roles do you need? Like, do you need technical account managers or product overlays? My rule of thumb, like my starting point for thinking about ratios is in your most strategic accounts, which are usually more than 500 K. You don't want to load up a person more than between 5 and 10 accounts. For enterprise, it's somewhere around 20 to 25 accounts per CSM. In mid market,

it's around 40 to 50. And then an SMB, it's a, you know, somewhere, and this is a wide range, somewhere between 80 and 120. And each of those require a dial up or a dial down on that ratio, depending on how complex is the technology? How much headroom does any individual account have in terms of growth? How difficult is it to get the renewal across the line? How much programmatic handholding does a customer need in order to get their program really off and running? You have to consider things like life cycle stage or use case.

If a customer has, you know, 15 use cases that you have to solve for, that's different from a customer who just has two in terms of the amount of time that a given CSM has to spend with those customers. But those are my starting points. And I think what I, tell founders and even leaders in growth stage companies is, " You have to start somewhere and be willing to change." Every year when I do strategic planning, I allow myself to review that customer ratio to determine, do we have the ratios, right? Should we dial it up or dial it down? Are our customers getting the level of support they need? You start with the math. what margin number do we need to hit? How many people do we have? How many customers we have? And let's just like start with the math. And then we start with some more qualitative factors like does this math really work? It's really hard, even when you're managing a lot, like small customers, it's hard. to ask a CSM to engage with 80 customers in any given time period. And so are we confident that we're actually giving customers the right level of service if we're assigning 80 of them to a given CSM?

Um, and that helps you think about, okay, do we need to inject other types of programs to serve those customers? Maybe a more self service motion, maybe a digital motion. We start with the math and then we look at those qualitative factors of, are we giving the right level of service to customers?

And do we need to dial up or dial down based on the feedback we're hearing? And sometimes that means reducing ratios and in a world where you can't actually hire more people, then you have to get more creative about how you serve those customers. Sometimes with more digital channels, more self serve channels, or just a different prioritization matrix.

So maybe you just. Say to your teams, look, we are going to categorize all customers into high priority, medium priority, low priority. And you have the leeway to determine where you're going to spend your time based on that prioritization matrix.

Brett: Something we haven't talked about is how you think about comp philosophy on the CS side. is it base or variable? Does it change over time? Any sort of rules of thumb that you've come to figure out?

Stephanie: Well, it definitely changes over time. Most CS teams, and I say that broadly across all functions in customer success, are on like a base bonus structure. And oftentimes I've seen the most impact with incentives where the bonus structure includes some very specific KPIs that often include commercial KPIs often renewals, percentage, um, sometimes expansion, percentage, very often things like adoption numbers or other measures of value.

I am a fan of that approach for CS teams, instead of explicit renewals quotas, unless you have a renewals team, or you, your team is actually running the renewals under customer success. So I think it's important when you think about comp to actually bifurcate, is the CS team or some portion of them responsible for getting a renewal transaction over the line?

Because that means revenue for the company, in those cases, you do want some kind of quota or specific expectation on how much revenue is going to renew, in addition to other leading indicators like adoption or, customer satisfaction. In a world where your CS organization or your roles in CS are more looking at retention percentage or churn percentage.

Those cases, it makes more sense to have almost all like MBO type or KPI based, incentive structures. The thing that I think companies get, tripped up by is when you put a significant amount of comp against a renewals or expansion quota that is going to drive behavior. And if you want your teams only focused on getting the renewal across the line, that is where they will focus.

If instead, it's really important that your CS team is paying attention to product adoption, use cases, integration with other workflows in their business. Then you need to incentivize that behavior in an appropriate way. I've seen, I think in like the early days of customer success, we saw teams like really skew in odd ways.

you know, if a customer success team in sort of a high transaction business was almost solely incentivized on renewals, that's where they spent their time, and then all of a sudden, customers started to churn because nobody was looking after whether or not they're actually getting value.

so it's really important that you are clear about where you want CSM's spending their time and you design your compensation systems to match that.

Brett: Do you think about setting up CS in a particular way when the business model is per seat, which is obviously a lot of SaaS, but not all. Versus I don't know, a usage based pricing product, or a piece of infrastructure, or a system of record, or other things that maybe the NRR is not primarily driven by going from 10 users to 20 users to 1000, you know, to 100 to 1000, et cetera, et cetera?

Stephanie: There are two factors that can really change how you set up your overall CS organization. One is if it's a deep technology, so it's infrastructure or even sometimes it's like cyber security where there's a tons of deep backend integration. That is a very technical team, and so you're going to skew a lot more toward professional services, sometimes technical account management and technical support.

Sometimes even in those cases, you don't really need a lot from a CSM, like a success motion, and sometimes that success motion gets, get shipped over to the sales team. Sometimes I've seen that happen and sometimes that works like that's how snowflake does it. It doesn't mean that you aren't paying attention to the path to value,

it's just really heavy on the tech. In a consumption business, whether it's heavy or not on the tech, the most important thing is product adoption. Because if you're adopting the product, then the customer is going to be paying you and then they're going to want to adopt more. So it's not so much a structural question when you're in a consumption based business, it's really about an incentives and an enablement question. If it's all about adoption, because that's what drives your revenue, then you need the assets, the workflows, the coaching, the product training, the, you know, the customer scripts, that are going to help your teams drive that adoption and drive it fast.

I've talked to, peers who are running these teams and they have an incredibly strong partnership with product and product marketing because, you know, one of the things in any SaaS business that we often run into in customer success is, the product and product marketing teams spend a lot of time working on developing features and then they, they're incentivized on the launch and then they toss the feature over the fence to the customer teams and they say, "Well, go give it to customers."

The problem with that is that over time, nobody really owns that best practice use case of the product. And so the people who design the product don't own the adoption path of the product. And so I do think that consumption based businesses are a lot closer to solving that problem because everybody is incentivized on owning and really understanding that adoption path and solving for that upfront, rather than as an afterthought, which is what I see often, in the sort of classic, um, SaaS business.

Brett: What about any other sort of nuances when it's per seat? And you can almost think about customer success, not just about making overall company X successful with the product, but it's Bob and Sally and Alan, and it's each one of these people. You can't possibly treat an individual that's ultimately paying you 10 a month or 100 a month as a company and focused on them in the same way.

But is there anything that's important about that type of configuration?

Stephanie: Yeah, there's a, there are a couple of things that are super important. The first is recognizing that your product is kind of B to B to C, where you are selling to an admin or a buying team, and they're the ones who are setting up the product, but they are then serving their consumer and that consumer could be an employee, or it could be actually an external customer.

And that matters in your course, your product design, but then in your delivery, you have to think about, how is our product landing with both our buying circle and our admins, but also the end consumer? Are we set up to support both our admins and our end consumer? So our support team needs to be able to intake, tickets, feedback, issues, and, this is probably the most important, are we enabling our buyer to help their consumer be successful? And sometimes that looks like you as the vendor actually developing and designing communication and training. And sometimes it looks like your customer developing those things. I find that. You know, when we're selling to enterprises, they want to take care of that themselves.

They want to write the copy. They want to do the email campaigns. They want to, actually run the trainings. but in smaller companies, they actually expect us to take that on. Training their end users. But you really have to be thoughtful about onboarding is not just your admin or your director, whoever is running the product onboarding includes getting your product into the hands of the end user and helping that end user be successful and that dynamic of who is going to own the experience of the end user is a really important conversation to have internally at your company, like what are we going to tell our customers?

And then also with your customers to set the right expectation from the beginning. One of the ways that that materializes is, what are the self service resources that are available for those end consumers? And often when we talk about digital customer success, which is a really hot topic right now, but you have to design both for your customer and your customer's customer in that, process and the voice, the call to action, everything all the way down to the language you use, the logo that goes on the email, the timing, how does that coincide with other messages that your customer is delivering to their consumers that you have to be really thoughtful and planful about.

But you know, I see when you set up your support team in a way that helps those end users, the customers a lot happier. When you at minimum provide all of the content and the access that, you know, consumers need, if you give that to your admins, uh, that can be, really beneficial for your actual customer. And oftentimes, you know, in a renewal conversation, um, the customer is going to want to talk about how are you helping our end users?

And are you providing the right level of support and representing our brand the right way? 

Brett: You know, an enormous percentage of B2B software has this dynamic of where you have a buyer and then end users, which in many cases is not the same person. Do you think about the CS's role as packaging up the value happening at the end user and bringing that back up to the person who's ultimately going to decide if they're renewing or expanding?

Or do you think, you know, good product generally does that? And so that's not something that generally sits with CS or maybe it sits with sales instead of CS or something like that. 

Stephanie: I think it depends on the product. Because you, the, the, the question you need to ask is where is the value accruing? Is the value accruing to the end user or is the value accruing to the buyer? So for example, let's take Medallia's business that I was, I was in for, four and a half years. the product is a customer experience product and it delivers customer experience surveys to end users.

And consumers touch the product by filling out a survey, and they send that data back to the buyer. Say it's, you know, Marriott or Hilton or Delta Airlines. The value is accruing at Marriott Hilton or Delta Airlines at the buyer. And so our obligation to talk about value is with our customer or our client, not necessarily the end user.

In that dynamic, it's actually the, the company's responsibility or that brand's responsibility to talk to the consumer about the value they're delivering and, you know, doing a, like I say, a closed loop feedback loop on that feedback that they've gotten. So when the value accrues to the company or the buyer, that's where we have a value conversation.

If the value is accruing to the end user, that is about, maybe a better user experience or a better buying experience. Then I do think it's important to try and, quantify What is the value that your end consumer is getting and how is that different before and after working with us? but that also, that doesn't mean that the only value is going to the end user.

There's also going to be some sort of value accruing to the, to the brand or the buyer. I think it's like a double sided coin in kinds of use cases. 

Brett: We've obviously gone deep on kind of zero to one CS and when you think about kind of early scaling and then add scale CS, is there sort of a cliff notes version you can kind of give folks that are listening, a handful of ideas or a couple ideas that are most important or, some of the most common mistakes you tend to see, whether it be people, or org design, or process, or systems, um, that are just really important to keep in mind as maybe you go from two to six, six to 12, 12 to 30 million, et cetera, et cetera.

Stephanie: it's funny when I started my CS career, in 2010, we really didn't know what we were doing. And it was like a hangover from the days of professional services. And it was like, are we support? Are we professional services? Are we sales? Over now almost 15 years, uh, at least in my experience, I think we've gotten very clear on what are the things that matter. The first is onboarding, most of the value is created or at least the, the seeds of value are created in the first 30 to 60 days. Now if you have an implementation that takes much longer than that, that's understandable, but it's the beginning, it's the implementation and onboarding because you have a captive audience who is very motivated.

And if you lose that moment, it's really hard to get back, especially as you're zeroing in on a renewal. So focusing in on getting that right and prioritizing that is the number one most important thing. And in fact, like somebody asked me recently, " Would you give up every other aspect of customer success for the sake of onboarding?"

And I gave like a soft yes, I said, "Well, I also want support, but I would give up almost everything else just to make sure that we're focused on onboarding, like in a, in a real pinch." And what I mean by onboarding is like implementation and getting the customer moving. 

Brett: Why is that overlooked or still not operationalized? 

Stephanie: I wish I knew the answer to that. I, you would be amazed at how many big organizations like over a hundred million in revenue that don't have an operationalized onboarding or implementation function. I usually see that in products that are kind of easy to set up. And when a product is relatively easy to set up, it doesn't take that long.

it's just, it's sometimes it's easier to just like say, "Okay, you know, Brett CSM, you get this new customer today, get them onboarded, and I will just add them to your portfolio." The problem with that is CSM Brett does an implementation and onboarding process once maybe twice a year, because that's how many net new customers you get in your portfolio versus if you have a group of implementation specialists. They do it all day, every day, and they get really efficient and they feed information back to the product team on here's where CS is sort of making up, you know, putting band aids in place and making up for gaps in the product. So here's how we can really improve onboarding and get to value faster.

So anyway, I think it's because it's easy to miss the value of onboarding. And I also see it in companies where they're not actively tracking customer health, which is my data point number two, where you're not maniacally focused on product adoption. it's like onboarding is lost because the adoption moment mostly happens in the beginning.

So we touch on the second thing that I think always matters, which is, I'm going to generally call it customer health, but the nugget of customer health is product adoption. Are they using the product and how often are they using it? Are they using what they bought? That always matters because that's the first thing to get cut.

If they're not using something they bought, they're not going to renew it. If they're using something they bought, it's much more likely they're going to want to buy more. whatever you have to offer. The third thing that always matters is data. And this comes in a couple of forums. And this is where teams and businesses are getting better at this, but I still haven't seen like great every time.

Data comes in two forms and like this concept. One is tracking data and holding your customer success organizations to account on the metrics are supposed to deliver for the business. And this is like my call to action to every early career CS leader is you have to be good at data. Even if you don't like it, you will not progress in your career unless you can go, go deep on the data, understand what metrics matter to your business and how to move those metrics and how to talk to the rest of the organization about your performance as a team.

The other side of data that always matters, but is, I'm going to say most often overlooked is data collection from your customers. Are you collecting all the right information? Are you making sure it gets into your CRM? Are you building like an ability to track user behavior into your product? Because that's the data that will give you the insights that are going to tell you where your business needs to go next.

And that is too often left behind and it's. quite tragic how many very large organizations out there that have very bad data. It's inconsistent, it's inaccurate, it's outdated, it's all kinds of different systems. So, you know, it always matters whether or not companies get it right from the beginning is another question.

Then there's, there's a fourth one, which is people. I think it's really important for founders and then, You know, even executives as the business grows to remember that the customer success team is on the front lines every day. They are taking hits sometimes when things go wrong and they're handling it with a lot of grace and a lot of fortitude and a lot of, customer focused mindset and remembering that these people work really hard and they often take, take a lot of heat,

it can be helpful to just remember to recognize the great work they're doing. Uh, and support them in, in whatever they need because they're, they're doing, they're, they're delivering the value for customers.

Brett: So I would love to wrap up by asking you, when you think about this sort of topic of zero to one customer success building, is there someone who's had an outside impact on the way that you think about all of this? Is there anything that they taught you that maybe we didn't touch on yet?

Stephanie: The whole team at Gain Sight and Nick Mehta.

They've created such great conversation about what really matters at different stages. I think about, The whole customer success organization under John Hurstine at Box, where, you know, I went to Box because at the time they were the best customer success organization in B2B SaaS. They were doing it at scale.

They were very, they had all great technology, had great customer experience, amazing retention. A lot of what I know about how to run a CS organization at scale comes from my time working under John. The other part of what I learned from people is more about team leadership and how to, how to foster change, at different stages of a business.

And I would credit Ben Saites and Ken Fine from my time at Medallia who taught me, you know, when you are leading a team through change or through hard times, it's much more effective to be the cheerleader. Inspiring people to follow you rather than like the screamer behind the the group like pushing people up the hill, pull people in toward you rather than pushing them hard.

and that that's something that I had to learn the hard way a couple of times, but it's definitely something I think about now as I lead teams through growth and change. I'd also credit a guy named, David Love and also, um, he was at Medallia with me and my former boss at LinkedIn, Jonathan Lister in really instilling a discipline of whenever you're solving problems, if it's a small problem for a customer, a medium sized problem for your team, or a big problem for the, for your business. Before you jump into solution building, before you assume you have the answer, really get clear on the problem you're trying to solve.

What is the problem you're solving? Because oftentimes deeply understanding that will reveal is this problem worth solving? Is the solution that we're thinking about doing actually going to address the root issue? and you're going to end up with a much more sustainable, lasting solution if it addresses that, that root problem, because you, cut the, cut the problem at its source.

Brett: It's, it's funny how, how true that is. And for whatever reason, how difficult it is for our brains to sort of behave in that way.

Stephanie: Yeah, it is. And also, you know, I recognize that, you know, we spent a lot of time in this conversation talking about a bias for action. And oftentimes like you think you have the answer, so let's just go do it. And sometimes I think when you have a lot of pattern recognition on a particular issue, that's okay to do, but it's, it's never a good idea to jump into something, especially if you're trying, if you're solving something new by assuming you know what the, what the answer is.

And it's such a habit for me now. And I, you know, people who've worked for me, you know, know that whenever they're bringing Uh, you know, an issue to me or a potential solution. Like we often spend the most time really digging in what is the problem we're solving because we don't, especially in a resource constrained environment, we don't want to spin up a bunch of solutions that are actually going to solve the problem that we have.

So it's probably my, my sort of favorite organizational habit.

Brett: Awesome. Well, thanks so much for spending the time with us.