Can you start off by giving us an introduction to you, Kristin, and what is your role right now?
Yeah! So, my name is Kristin, I'm the Head of Customer Success at Gremlin, and I currently run four functions, and that is:
The Customer Success Managers, they're the ones that own the relationship with the customer. And the relationship goes beyond just contractual; the relationship is understanding business goals, and use cases, and the value of our application across an organization and how to help more folks in the organization understand that value and use that value.
Technical Account Managers, these are the folks that understand the technical portion of the customers use cases that solve with the application itself, i.e., how do you help engineers inject fault to understand the reliability of their system, their infrastructure, and how they go from low maturity within their reliability practice to high maturity.
We have Professional Services, of course; those are for the folks that say “I don't want to do this, do it for me”. Or otherwise, “my technology is deeply integrated, please help me figure it out so that I can actually use your application”.
And the reason why I love my job is that I am a systems thinker. I have been formally trained as a research scientist and I would study how perturbation affects ecosystems, and then, based on that effect, how it affects the organisms living in it. So I actually spent 18 years as a scientist: studying, publishing on our own real ecosystems and when I switched to technology, I realized, “hmm, same thing! Looks like infrastructure is just one big ecosystem and all we're doing is injecting fires into that infrastructure, which is the exact same thing”.
And being that Gremlin uses hypothesis testing and the scientific method to understand how injecting fault results in quantifiable change and subsequent discussion around reliability testing, it was a perfect marriage of my previous career and my current career.
So I would say that's a pretty good summary of who I am, how I think, and what I'm currently doing.
Wow! That is really cool. So with those four functions underneath CS, how big is the Customer Success team as a whole?
There's 10 of us.
So we have one Support Engineer. One Technical Account Manager, which we will be expanding to two. We have three Customer Success Managers and a Customer Success Management Lead. We have another Customer Success Manager coming on board.
We also have another Support person coming on board so my team is growing and it is because Gremlin is a Customer forward company.
I have three people in Professional Services: one Lead and two Reliability Specialists, and they're hiring two more as well.
So it will be [counts] - we’ll be 15.
And how are you organized? In the sense of, are you reporting to Sales or your own division?
I have my own division; I report directly to the CEO.
Okay. I'd like to understand though: what does this mean for you and your team with you being a direct report to the CEO as opposed to going through Sales?
So what that does is, it allows Customer Success to be more than a lagging indicator of Net Retention. It allows me to directly communicate to the CEO about CS functions, and the way that the functions support a customer in getting mature at a practice using our application across their journey with us.
And why that's important is because it's full of leading indicators. If we're helping them use our application to solve a business use case, it's not all about that lagging indicator of getting the renewal. I can actually show the value of all the different things that we're doing up to that point, measure all those things up to that point, and iterate and actually show internally the value of what we’re doing.
A lot of people are just like, “just make the number go up on the lagging indicator”. And if that's all you're doing, you're scrambling the entire time, you're not understanding what you're doing for the customer and why you're helping them.
Fundamentally, you have to know what your application is going to solve, and the bigger picture that that's associated with.
I'm here to make people's lives easier. If you pre-inject fault into your ecosystem, into your infrastructure, you're not going to have an SRE or a DevOps person have to get up at midnight and call three or four engineers. I mean, just think of the salaries alone!
And then the time that you spend on a retro, and the time that you spend pulling your C-suite in… Not to mention the impact on your end users, right?
So, this app that just says, “oh, hey that's broken”, has a HUGE trickle-down effect.
The only people that are telling the customers that succinctly when they're using our app is Customer Success. And it takes all those functions to do those things.
If I was just reporting under revenue, it would be all about the numbers, and so it would be me pushing my CSMs to do work based on, you know, “just get the numbers! Just sell!”
And if we're selling to people that don't need us, and we haven't solved value for them, they're going to churn!
So then we're really just chasing our own tails, right? Yes, we're selling more but we're churning more, that's exactly what happens across multiple organizations.
It's about solving their problems with the application.
And the ARR will come with that.
I see that. So, if you were to summarize Customer Success: what does it mean, and how do you know if it's working? How do you even measure it, do you measure it?
Customer Success is the successful implementation, adoption, enablement and maturation of your product to do a thing that has a business impact for your customer.
And really the way that you should measure it is expansion. A lot of customers will start to use your app on a single team. And then they're like, “Oh, this is really making this easier. I think I want this - depending on your space, of course - I want this other team to use it. Now I want to put it in this environment, or this environment.”
In our case, people are like, “oh, we're scared of what you do. We're going to put it in the Dev environment.” Yay! Great! Okay, well let's get you into QA now, let's get you into Staging and now we're going to put you into Prod!
It takes time for them to trust that your application is safe. But once they do that is a natural expansion because there's a team that's working in Dev, and there's four teams working in Staging, and then how many teams are touching Prod? All of them! That is success. Real customer success.
That's a natural extension of the use of the application across the organization because you've proven out their business goals, the value of your product, and that you're impacting their business outcome, you're driving unit economics for that company.
It's very interesting that you pointed out expansion as the way you would know if it's working.
How have you seen Customer Success evolve in the last two years?
Oh, I'm not a good person to ask. Whatever company I'm in, I look at the problems that they have and I try to solve those problems. I
I did attend the OnDeck Fellowship where we talked about a lot of what's happening, and it was fantastic because it was the first time that I opened my mind up to to the larger industry, and I have this set of books over there [points] that I would really like to read, but I can't tell you really where the trends are going across the industry.
I can tell you how I think you should solve problems and I think the industry should know that if you don't solve the problems your customers have using your product, they're going to leave you.
OK, so let’s take that point of view. How do you see it changing in the next 5 years?
I think people are finally starting to realize that we're driving outcomes for companies, and their business outcomes, the impact of your app on the ultimate business KPIs that that organization has.
You should make their cost per user go down.
Or whatever measure, whatever KPI they use to measure their business success, your product should be impacting that KPI and you should be able to figure out how you do that.
Is this a change in mindset, or do you see this more of a change in process and tooling, what is it? What leads to this, or what is the main driver for this?
Hmm. Well, for our application we're in a new space, that's kind of what I specialize in: new spaces.
We have the C-suite, asking us, you know, “how do you create a reliable practice across an organization?” And they're looking to us to define what you need to do beyond just the application.
They're looking to us to help them define how to build those practices so that value is above and beyond the actual application because having a practice of reliability in an organization allows them to maintain a thought process across everyone.
It allows them to build a culture around reliability, which is good for us because if we're the ones defining it, they want to use our app! But if they're building a culture, it's actually impacting their bottom line, less incidents, reduced time to detection of an incident, reduced mean time to resolution of an incident, less people being unhappy because they're on call because code may be shipped without checks and balances.
Those are all things that make their overall costs go down and you don't necessarily always have ways to measure it. You just have to show them that these are the things that you're changing. However CS measures it, we should be able to affect those KPIs by the use of our application, and show how regardless of if it is qualitative or quantitative.
You're doing something proactively. Software is a proactive response to a problem. It's always an upfront problem to try and make that problem go away. That problem has a bottom line, it has a positive effect on the business.
It's just that simple. Being able to articulate that across the different personas, is what will make your Customer Success -- and your Marketing, and your Sales folks -- be able to communicate the value of your product.
So what is the best and the worst way to set up your Customer Success team to this end?
How much money and resources do I have?
All right, well at a very high level, definitely start with Support. You need someone that can run tickets.
But when you set up Support, make sure you understand what Support actually means. Start a ticket, finish a ticket, escalate a ticket, close the escalation.
Following that, understand whether it's a customer problem or your problem.
A customer problem or your problem -- or an app problem, I should clarify -- that is an application problem, software application problem, or your customer has a problem: “you promised me a feature and you didn't deliver”.
Those two things will take different pathways and they will take different representation across your org so you have to understand those processes.
So I would start with Support, and then you'll start to understand the next thing that you need. And I would say some sort of an Account Manager.
When you have an Account Manager you need to make sure that your transfer process from your sales cycle is good! The worst thing you can do is say, “Hey, I'm your Customer Success Manager, so what did you talk about in the sales cycle? Who are you?”
No, that's not cool. That's just disrespectful of customers. “Let's reset. Let's ask you all the questions all over again, and waste yet another hour with 10 people on the phone.” That just cost your company $300,000. [thumbs up]
No! [shakes head] Don't do that! Say, “we heard you say, in the sales cycle, X, Y and Z, here's how we're going to implement the application for you, here's how we're going to solve X, Y and Z. And as we're solving X, Y and Z, we're going to find A, B and C and that's what we'll move to next.”
So you need a Customer Success Manager who can run those use cases -- A, B, C, and X, Y and Z -- and then ultimately get to six month mark.
And then you have an Executive Business Review. You can do Quarterly Business Reviews, but I find that six months is fine, especially when you're in your first year, your app is solving a complex problem or takes time to stand up.
You can then take your use cases that you've been working with them and tie them to the business relevance of why they bought your product. That's what the EBR is for: showing the value based on the use cases that you solved, that they identified in the sales process as the reason why they bought your product.
And then the last six months after that EBR, is the A, B and C out of the X, Y, Z, A, B, C -- you continue on those use cases. And you say, who else in your organization can we help because the EBR was so successful everybody was like, “you did solve our problems! You did what you said you would do. Woot! Can we get a discount?”
And the CSM should have the ability to have those contractual conversations, so they have Sales blood, but they're people that want to develop long term relationships with your customers and understand that those relationships drive renewals and expansions. They want to get to KNOW people, because behind the use of your product are the hands on keyboards and the relationships they have in the customer org.
Those are special folks -- they’re more special than me for sure!
And then, based on the technical difficulty of the application that you're creating, you might need Professional Services or TAM [editor’s note: Technical Account Managers], because at some point Professional Services will be when your customers say, “can you just do that for me, it’s too hard!”
I built a managed service department within a software company, because our target audience was marketers, and we had a couple very complicated applications that required skills outside their job duties, like an analyst. They said, “we want to be able to give you all the copy, all the images and have you just take care of the technology”. And so of course I said, “Yep, can do that for you.”
Next, you can choose whether you need a Technical Implementation Specialist based on your agents or however you deploy your product, like how challenging or adaptable and or easy to break when deployed due to over creative use, or challenging types of integrations. Essentially how difficult is the code under the hood.
If you have an SDK, if you're implementing something in somebody else's application and you have a Software Developer Kit that needs to go into iOS apps and Android apps, then you may need an Implementation Specialist because placing code into somebody else's code can be very challenging.
But you can start small and lean though, you know, like one Support Engineer, one Customer Success Manager, or maybe two Customer Success Managers, they can bounce ideas off of each other because they're relationship-driven, so providing a mechanism for an internal relationship is also really important.
Don't have them report to Revenue. Have them report directly up. I think that's critical. Have a voice for Customer Success, otherwise it becomes just another mechanism for money and that doesn't sell value.
What would you say is the most controversial opinion that you hold about Customer Success that you wish that other folks would just hurry up and catch on to already?
You have to hold your customers accountable to doing the things that they have to do to be successful in your application. You've got to figure out a way to make them say that they're going to do the things. So that if they churn you know what is hard and what is not, “They didn't do X, Y or Z because of... That's why our account failed.”
You’ve got to find those reasons for churn so helping your customers be accountable helps you understand why they leave you. Were they unable to do anything with your app and have you tried all the stops? That is a reasonable reason for having churn.
Interesting! What is your take on Customer Success being responsible for keeping the customers happy? Is that the role?
You mean happy as in “happy-feel-good”?
I guess what does “keeping the customer happy'' mean to you?
Oh, yeah. So, customers buy software to solve a pain point.
Making sure that you actually solve that pain point that they purchased the application for makes customers happy! You actually make their lives easier like, “sweet, I don't have to go to work and feel that pain!”
It translates to being happy, and the younger generations really value that! I'm old, so, you know, whatever, just solve the problem. I'll go home and make my own happiness but for other generations it's completely tied into how they feel, and how they feel at large about their place in the world, and for them that's important, and that matters a lot.
And I think we'll see more of that going forward, which actually is better for the human species anyways.
What is the one story you want us to tell us about Customer Success life that you feel like we haven't asked you about? What would you like to share that we haven't asked?
Sometimes customers just need to be listened to.
They just need to be heard.
And it doesn't mean anything more than that, than sitting down and letting them talk to you about whatever it is that they need to talk to you about.
Sometimes they're just mad that they're not going to get a feature because it's a one-off, and that's a bummer for them. And that's okay to just sit there and be like, “yeah, I hear that. I wish I could prioritize that on the roadmap for you. I would if I could.” And then, you know, sometimes they get mad and then they'll get it out, and most of the time they say, “but it doesn't make sense for you to do that as a business, I understand”.
And then you move on!
So just listen! Sometimes you just need to listen. That's it.
We know that Customer Success Specialists say that they want to be superheroes and save the day for their customers. If you had a superpower with respect to Customer Success, what would it be? What would you like the ability to do?
I think, if I were to create a superpower that I don't necessarily have right now, I would say… I was just working on it earlier today actually, that's funny...
Objections are hard, because if people have good data about why they're not doing something I'm usually like, “OK!”
And really good Customer Success Managers know how to handle those objections really well.
In the beginning, once you get CS off the ground, or if you haven't hired a CSM yet, provide anyone working with customers the objections and have them just bounce them off the customer and see if it works.
I guess the other thing that took a while for me to figure out, was customers want to give you their opinions! You can have working sessions where you invite customers -- it's like a mini customer advisory board.
And ask their opinion, “what do you think about this idea? We're thinking about doing this along our customer journey, do you think that will work?”
And then when you have a whole bunch of customers in a group, one will say “no”, another will say “yes” and then another one will say “maybe”. You'll watch as the solution for how your customers want it to be solved comes to a conclusion through their collaboration, and they'll give you the answers, because they're the ones using your product, right? It's so cool!
I felt like I had to know all that stuff ahead of time and I was like, “No, I just need to ask them, they'll tell me!”
I can't believe that one took me so long to figure out. Now I'm like, “let's get a customer advisory board together! Let's do a working session! Let's get their opinions! Let's have them tell us what they think because they have such great ideas!”
Well, you know, not all the time but most. Any time you say, “I would have never thought of that, that is so good, let's implement that” is great.
And then you can test it with other customers and see if it resonates.
Interesting. In these sessions, where does Product come in? Do they come in at all?
You can have Product join! Because eventually, what a lot of Customer Success does is fill in where the product gaps are, or where the product doesn't show people how to implement in-app, adopt, and evolve in-app.
So your CS people are driving those initiatives, the larger stuff which you just will never be able to get into the app, sorta like, “here's what you can get in the app and here's what you can get with the CSM” and eventually you want the gap to get smaller and smaller and smaller.
But when you first start out there's a lot that people want your app to do that it won't be able to, and the CSM will solve a lot of it. Special people the CSMs.