In Episode 9 of The inSide Scoop, we talk to Rav Dhaliwal who describes himself as a “recovering software executive” with over 20 years of management and executive leadership experience in enterprise software. Let's see what Rav has to say about CS constantly being at risk of becoming the ‘everything department’.
Don't want to listen this time? We've got you—check out the handy transcript of this interview below. Don't forget to follow The inSide Scoop over on Spotify!
- Connect with Rav on LinkedIn
- Read Rav’s The ‘everything department’ article here
- Read the eBook: The Technology Stack For Customer Success Teams
- Rav's 'can't live without' tool: Calendly
Remco (00:00): I'm super happy to talk to Rav Dhaliwal today. He's been on this podcast before. If you haven't listened to that episode, then please do. And today he's back for another episode that's looking like it's going to be a really, really interesting one. So hey, Rav, welcome again and thanks for joining me.
Rav Dhaliwal (00:17): Thanks so much for inviting me along, Remco. Excited to have a conversation today.
Remco (00:22): So am I. As always, we start with a little bit of guest background, or what makes you uniquely qualified to talk about these topics. So can you tell us a little bit about yourself and your background and what you're currently doing?
Rav Dhaliwal (00:33): Sure. Whether I'm uniquely qualified, I guess we'll leave that to the listeners. My background is I like to describe myself, Remco, as being a recovering software executive. So I spent about 25 years in enterprise software. Started my career with all the usual suspects, some giant corporations like IBM and Microsoft and Salesforce. And then for about the last 11 or 12 years, it's been all sort of hyper growth startups. My career has been really focused on sort of sales and what we now call customer success, used to have different names before. And now I'm in the world of venture capital, specifically European venture capital. Helping to sort of find and fund sort of the next generation of sort of intelligent computing enterprise companies.
Remco (01:23): Awesome. And you make it sound like it's an addiction there, just a little bit.
Rav Dhaliwal (01:28):Ah, maybe, yeah. I haven't thought of it that way, there is something I'm sure as we go through the conversation, strangely compelling about working in the startup space. It's exciting.
Remco (01:41): Yeah, it definitely is. So before we get into the topic, a quick full disclosure section. How do you know inSided?
Rav Dhaliwal (01:48): That's a great question Remco. So I was introduced to inSided and specifically Robin van Lieshout, founder and CEO back at Gainsight's Pulse event in Europe, I think, in 2019. Robin and I were introduced by Dan Steinman from Gainsight, who at the time was European GM, he's now back in the States, I think as Gainsight's chief evangelist. And Robin was really looking to engage with people like myself, like Dan, part of inSided's move towards focusing much more on a CS buyer. And he very kindly invited me over to spend the day with the board and some of the leadership team including himself in February last year. That was in fact, my last international trip. Sorry February this year. The last international trip before obviously, the pandemic. We have maintained sort of contact ever since, you guys have been kind enough to invite me now twice onto the podcast. And we'll talk a little bit about Robin and I worked on a little bit of a project earlier on the year, which I'm sure we'll get into it later.
Remco (02:48): Yeah, absolutely. The new ebook. So we'll definitely get into that a little bit later. But first, I wanted to talk to you about an article that you wrote back in November, it was published on the Scottish Equity Partners blog called, the everything department. Briefly, I think it touches on how SaaS companies scale and what that means, obviously, and also specifically how that reflects on a customer success team. Ultimately being at the risk of becoming an everything department. So if you will, can you briefly explain to our listeners what it is exactly that you mean when talking about an everything department?
Rav Dhaliwal (03:26): Yeah, it's a great question. So first you should point out, and just a quick shout out and thank you to the team at Scottish Equity Partners, they're a growth investment firm, highly respected, really understand tech, and they do a growth series. So they asked me to write this article as part of that growth series. So yeah, big thanks to them. The idea behind this idea of the everything department is that as, and I'm going to just talk specifically about software startups here. But as software startups, especially enterprise ones grow and scale, obviously focus on product and engineering. But then the focus starts to shift to sales and marketing. And this is perfectly normal and understandable. But if you're not optimizing for thinking about the customer beyond sales and marketing, what can happen is, you'll get to a certain size and complexity or volume of customer. And then lots of things you hadn't anticipated happen or lots of needs that the customer had that you hadn't thought about start to crop up.
Rav Dhaliwal (04:31): And they typically don't have an organizational owner because they're... You weren't anticipating that these things would be needed. And so while you're sort of scrambling around doing best efforts of grabbing people to help with these issues or needs that customers have that you haven't thought about, you can suffer a lot of business problems. So you could have really slow deployments or you could actually have a lot of product issues causing the customer pain. You may even start to see some churn for example. And so their natural instinct then is to say, "Well, let's just build a function or an organization to take care of that." But given that they've built that organization, most people call it CS ends up not being built for productive reasons, it ends up being built as a reaction to these unanticipated needs and problems.
Rav Dhaliwal (05:21): And so the team ends up owning everything that didn't have an organizational owner, and sometimes wasn't wanted by other parts of the organization. And that's kind of what we mean by the everything department. It's a team that's customer focused, but that grows out of a reaction to unanticipated issues or needs or challenges, and then either ends up owning everything that doesn't fit or wasn't wanted elsewhere in the organization.
Remco (05:47): Awesome. Okay, or actually, not really awesome.
Rav Dhaliwal (05:49):Not awesome, yeah.
Remco (05:49):So basically, they just end up doing everything that all other departments either don't have the time or resources for. Or they end up just having to very reactively jump on every issue that you would find while scaling an organization.
Rav Dhaliwal (06:04): Exactly. The way I describe it sometimes is, if you think about a car production line, and you think about selling software and you have a go-to-market production line in software. So in cars, you've got raw materials, manufacturer, assembly, et cetera. In software, you'll have your product, engineering, marketing, sales, SDR, BDR, et cetera, and success. And success tends to be at the very end of the production line. And really, what the everything department is, is like saying, well, if we were making cars, Remco, and you were right at the end of the production line, what I'm saying to you is, "Well, Remco, your job is to make sure this car we've built gets delivered to the customer on time, that's your first priority, and then you need to teach them how to drive it, because our car is slightly different from other cars they may have driven. Whilst you're doing that, could you also be responsible for ironing out any defects in manufacturing or assembly that happened further back in the production line? And while you're doing that, can you try to convince them to maybe buy some add on features to the car or maybe a metallic colored paint, and then try and convince them to buy a new car next year?" So that's essentially what an everything department is doing in a software company, if we were to use the analogy of a car production.
Remco (07:22): That's a good one, probably me at least in that production line would end up with me burning out. Probably, I would guess.
Rav Dhaliwal (07:29): Yeah, correct. Yeah,
Remco (07:30): So maybe as a follow up question, I'm now wondering, do I also have an everything department at my company? Or at least how do I know? How do I find out?
Rav Dhaliwal (07:41): Yeah, it's interesting. So as part of this growth series, we kind of presented this idea to a whole bunch of sort of leaders and founders. And we sort of tried to provide some guidance on like, how to maybe assess whether or not you have an everything department. And I think a couple of useful things, especially for the listeners to think about is to assess that, does your CS function actually have a defined mission? Does it have a very crisp definition of not only the value it's adding to customers, but the value it's adding to your company's bottom line?
Rav Dhaliwal (08:14): So I think that's the first thing and I'm sure through this conversation we'll talk more and more about this lack of a common definition for CS. I have one that I'm very fond of, but there isn't really an industry definition. And that's because CS is very contextual to both the company, its product and the stage the company is in. So that's the first thing I would say, is do you have a defined mission? And related to that is, does your CS function have materially important targets? So does it have a Northstar metric, or metrics it's aiming for that are actually important to your company's bottom line. So that's not always revenue, revenue definitely plays a very strong part of that. But if you're a very early stage company, even a... You may only have a handful of customers, some of the most important metrics to you are going to be around product and feature usage and adoption.
Rav Dhaliwal (09:06): So whatever stage you're in, do you have a materially important target as a CS team? And I think another key thing is to] whether you're in everything department or not. Do you actually have access to important data that helps inform your decision making? And this goes back to this idea of being reactive or proactive? What data helps you to do, is to look at patterns and look at where you need to make a proactive intervention. If you don't have access to good data or any data, then you're very likely an everything department. And I think the last couple of things are just around internal alignment, and specifically in alignment with sales and product. So do you have a hard handover from sales? Are you actually not part of the sales motion? Are you not integrated into the selling effort or even have visibility to the pipeline? And do you, the sales and CS have any common kind of alignment?
Rav Dhaliwal (10:02): So if sales is aligned around industry vertical, but CS is aligned and segmented, say around employee size. That's a mismatch in alignment. So you're not working on a common set of customers. And I mentioned the product there, do you have a formal feedback mechanism with the product? You're typically a CS closest to how people are using the product? Are you an island that doesn't really interface with products? Or do you have a rolling mechanism to feedback what customers need and the challenges they're having? So those are sort of five or six things that I think make a useful checklist. And I think if you have one or two of those where your answer is "No, I actually don't have those." That does tend to strongly indicate you might be in an everything department.
Remco (10:45): Wow, so many good things in there. So maybe a couple of questions from me. So first, you mentioned your definition around CS. So you did get me curious, a little. Do you have it top of mind?
Rav Dhaliwal (10:58): Yeah. So I think CS is really a group that is focused on accelerating the business value customers get from your product. So by value, we mean material bottom line value. But they focus on accelerating that faster than if the customer has left to their own devices. So we could sell something and leave the customer to it. But if we add CS into the mix, that definition I feel of what they do is we are here to accelerate the speed at which the customer sees value. And because their mission is to keep and grow that customer forever, they're creating the conditions to keep them growing.
Rav Dhaliwal (11:36): And so that's the definition I'm most fond of because it, I think, speaks to the value you add to the customer and the value you're adding to your bottom line. And it talks in a non-specific way. Because CS is contextual, it will vary depending on the company about how you're going to do it. So you're going to do some sort of acceleration. That acceleration might be you bring certain deep technical skills to accelerate the customer's value. It might mean you bring project and change management skills to help the customer accelerate value. You might bring consultative skills, that helps them to model their workflows in your product in the most efficient way. So the thing that you bring, or the things you bring to accelerate may be different. But the cool thing I think every good CS team is trying to do is speed up the time it takes for the customer to see value. In a year-long subscription, if it takes them 10 months to deploy the product and see value, that puts you in a very high risk situation. Maybe we can add CS to the mix, and they can help the customers to see value in 30, 60, 90 days.
Remco (12:40): Yeah, I love that. And I especially also love that definition. Because I think it's a different kind of more visionary kind of mission, which is easier to get behind than the general things you usually hear around CS saying, "Okay, so no, no, we're largely focused on only increasing product adoption on our largely focused-
Rav Dhaliwal (13:00): All outcomes, which is very generic.
Remco (13:02):Exactly. Yeah, that's what you usually hear in CS world is, "Yeah, we're responsible for these outcomes, if not all of them." And I think this sort of neatly covers a bit of a visionary thing.
Rav Dhaliwal (13:13):I hope so. Yeah. I mean, it's the idea that really we exist to help speed up the process by which the customer sees ROI, real business value, something that they can materially point to and say, "We can do this faster, cheaper, gaining or revenue." Whatever it is that's important to them, but that you can then circle back and go, "And actually, this is how we are adding to our bottom line. We're driving net revenue retention." For example, is a classic metric.
Remco (13:41):Exactly. It's like driving the business forward versus managing a few metrics.
Rav Dhaliwal (13:47): Correct. Yeah. So this is the challenge going back to your original question in the premise of the article is, if you're an everything department, you're never going to get on the front foot of driving material value for the customer or for your own company. You might end up over indexing on doing lots of manual workarounds or filling in product gaps by working hard and doing manual things, that will help the customer, but it won't necessarily add to your bottom line because it's purely reactive.
Remco (14:20):Yeah, exactly. Yeah. I love that. And then maybe one final question before we move on. So you mentioned does CS make data informed decisions? I think that's a super important point. And maybe we cover it a little later on, but I just wanted to mention it here as well.
Rav Dhaliwal (14:35):Yeah, sure. And just on that, the use of informed there is very deliberate. I know in tech, we like to say data driven decisions. I'm not a big believer in just using data to drive your decisions, especially in CS where there are so many softer skills at play. The data may be telling you something and it may make you have an intervention, but the type of intervention you make might be based on other factors like the stakeholder, the changes in political dynamics in the customer, what their business is going through something that the data can't show you. So, I'm a really big believer that when we get to that topic around data, being informed by data is important. Using it as the only source by which you make decisions can be actually quite challenging.
Remco (15:19): Yeah and I was speaking to (will not name names) but to another VPs CS the other day. And they were basically explaining that they were struggling, because they weren't actually the owners of certain types of data or data sources that they actually required to do their business well. Because they had to go to different types of departments. And they were basically owning the applications or the data. And they had to actually ask them to give them certain views
Rav Dhaliwal (15:50): And that's a very, very common challenge, which is why I made a point of including it in the list of questions to ask yourself to determine if you have this sort of everything department.
Remco (16:00):We'll definitely cover that later. I'm first now going to backtrack a little bit. So at the start of the article, you dip your toe into how SaaS companies scale through product and especially go-to market fit, could you explain that process a little? And maybe also how a customer success team then evolves along that journey?
Rav Dhaliwal (16:19):Yeah, sure. So certainly, now that I'm on the investing side of the fence, investors tend to toss around these phrases, product-market fit, go-to-market fit, and it can get a little bit confusing, people will have their own sort of spin on them. But essentially, and I'm just going to speak now, from my experience of being in a number of companies that sort of scaled quite rapidly. In the very early stages of a startup, you have a kind of a version of your product, you're still iterating on it, you maybe have a handful of what I call friends and family sales. So you've sold to people through who you know, or through maybe your investors and your network have connected you to.
Rav Dhaliwal (17:00):And but really what you're focusing on is trying to reach what we call product-market fit, which is how do I build the best product for the target buyer and the target user that generates the most value for them and for us, right? That's the mission that you're on. And so, where CS plays a part in that, a really important part in that is actually, we talked this idea about acceleration, is you may not have that many customers, but it's important to have someone who's working with them because you need to be able to feed back what you are learning to accelerate the product-market fit. Product people have hypotheses about what customers need and how they need that capability. And you need to have a really rapid cycle to test those hypotheses, accept the ones that fit and then discard the ones that don't, because in the early stages it's make or break.
Rav Dhaliwal (17:52): So even though your function may not be called CS, you need someone and sometimes it is a person in product who's wearing the CS style hat, working with these early customers to help accelerate your product-market fit. Actually, there's gaps here, when we put our product out in the real world. These are some gaps, or these are the things that are actually working well that we need to double down on. It's just as important to understand which features aren't adding value, as it is which ones are, so you can orient the roadmap around that to get product-market fit. Now, you could argue that a good SaaS company never reaches product-market fit, they're always iterating. But they will get to a certain critical mass where actually the product, the sort of maturity and capability that's currently reached really suits our target audience that we're going after, and our target buyer really well. And we're starting now to see, we're landing more and more customers beyond the sort of friends and family and people we know. That's normally the signal to start ramping up what's called your go-to-market fit.
Rav Dhaliwal (18:54): And that is really building a sales marketing engine. What that really should be is a sales marketing success engine. Because at that stage, that's where the risk of the everything department comes in. You focus on the sales and marketing piece, and you forget the customer piece. So you really want to do all three. And what CS should ideally be doing at that stage and focus on in that stage, is this idea of how do we accelerate time to value? How do we get this thing deployed, configured, users onboarded, up and running, in the quickest, most efficient way possible? Because that will then give us the opportunity to understand what else we can be doing with the customer, whether we can sell them more capability, getting them to consume more of the service. So that's kind of at the beginning of the article. Why I framed the article in terms of that journey. So ,you have a hypothesis about a product, you strive for product-market fit and CS helps you accelerate that product market fit. When you get to a product-market fit at least in one sector or segment of customer, CS can really help accelerate the value that customer gets, so you can continue to iterate and learn more.
Remco (20:02): Thanks for that. So what I was thinking as you were explaining this is, so why do you think do we fall into this trap of basically saying, "Okay, let's just figure out how we grow first and get all these customers on board, and then we'll figure out how we're going to deal with them later." Why do we consistently fall into this trap?
Rav Dhaliwal (20:22): Yeah, it. I don't think there's any one answer. Some of it is historical, I think, Remco, in so much is not so long ago pretty much for anybody to get venture capital money, they would have had to come from sales or marketing, it's very different now. Typically people who do get backed are product engineering tech people. In the first instance, in the olden days where it was basically sales and marketing people built companies, that's what they knew, you optimize for sales and marketing. What happens now, where you have maybe more product lead founders, they've never run a business before, they've never been in sales before. They then rely on their ecosystem of investors and advisors to work out how they should build a company, and a lot of that ecosystem with the exception of people like Scottish Equity Partners and some of the other funds that I know who are very forward thinking and understand the importance and power of customer success. They're not being told, actually, you need to think about sales marketing and success, you just got to optimize on top of funnel and keep the new revenue growing. And it's really the forward thinking investors and the forward thinking advisors are saying, "Yes, you need to do that. But you also need to lay the foundation for net revenue retention. So we don't want to be losing these customers in a year's time."
Rav Dhaliwal (21:35): So I think it's a lot of it is historical. And I think actually, Remco, a lot of it goes back to the fact that we don't have a crisp cogent agreed industry definition of what CS is. How would you know to build something if you don't know what it is? Sales is very well understood by everyone. Everyone has had an experience with sales, you don't need to define it for anybody. You pick up the phone and ask strangers for money, that's your job. Marketing is very well understood. In tech, engineering and product is very well understood. Success is not. So if something isn't understood and doesn't have a clear definition, it's quite natural for someone to not think about it.
Remco (22:14): Totally makes sense. I agree. Awesome. Thanks for that little bit of background there. I really like how you at some point in the article also mentioned that while a company and CS team scales, not only does the amount of customers and people and processes grow, but more importantly also the pace and frequency of which you do things grows rapidly or even exponentially. Could you elaborate a little bit on that?
Rav Dhaliwal (22:37):Yeah, sure. And this kind of goes back to a point you made earlier, Remco, about the addictive nature of this style of business. I think one of the reasons why startups are very seductive places to work in a lot of cases is the speed of change. So large organizations, global multinational organizations, they're really structured and optimized for predictability and efficiency, because they're just so big. And so they have to, whereas a startup is scrappier and nimble and is figuring things out. It's all about building. And the thing is, people think that scaling a business is actually about adding people. And that's kind of why I wanted to make the point in the article, that it's people and pace. It's two things, it's not just adding people, it's the pace at which you have to add them. It's not just shipping features, it's the pace at which you have to ship features. It's not just onboarding customers, it's the pace at which you have to onboard customers.
Rav Dhaliwal (23:33): And that is often overlooked. Because generally when you think about scaling, or people talk about scaling, what they're really talking about is growing the headcount in the organization, and I just wanted to make that distinction because adding people can actually have the reverse effect of slowing everything down. Because it takes time to find them, hire them, onboard them. So you want to factor in the fact that scaling means everything that you do from building the product, marketing it, to selling it, to onboarding it, just starts to happen quicker.
Remco (24:01):Yeah, I think that's a great point. And I think that's also interesting, because arguably this is exactly, I think the one thing that people always forget while scaling. And this is also the one debate that we usually have when we talk to either customer success leaders or however the function is called at that point of smaller organizations. Where we really advocate you need to figure out your process also for and plan for a bigger company basically early on, versus actually trying to do that when, yeah, pardon my French, shit hits the fan. And you have no more resources and everything is basically locking up, then you're too late.
Rav Dhaliwal (24:42):Yeah, exactly. It's a very fine balancing act. And it's a real timing act. If you get the timing wrong, if you start to scale too early that's detrimental, and I'm putting my investor hat on here. You say you start scaling up you go-to-market fit before you have product-market fit, you're going to burn a lot of money and probably end up having to a lot of people because the product wasn't ready to sell and scale. Conversely, and normally the reverse is more often true. You wait too long to scale up your go-to-market effort. So you've got a great product, but you're not doing well enough selling it and getting it out there and getting people to onboard it. So the timing of these things is really, really critical. And the timing sometimes will make or break a company.
Remco (25:23):Yeah, exactly. Which is an awesome bridge to the next section, which is about the bad side of scaling. So what typically breaks from a CS perspective, what gave you headaches as a former CS leader?
Rav Dhaliwal (25:36): Oh, that's a really terrific question. So going back to the overall theme of the article in our discussion, I think one of the things that has typically giving me the most headaches is, well, my team and I are owning and doing things that actually don't add any impact toward the customer or to the business. So we have to set about on a mission now to find those things at home, or stop doing them, or figure out a way to automate them. That's a huge challenge. And that really leads to another big headache, which is we're just reacting all the time, we don't have maybe as you gave the example, the right data to make informed decisions, we haven't disintermediate ourselves from these things that we just ended up inheriting that we shouldn't have been doing.
Rav Dhaliwal (26:17):One of the other really big headaches. And this has been a common thread in my career is internally people not understanding what you do. And so if they don't understand what you do, and you're too busy just reacting and getting on with stuff, it makes the challenge of getting resources, people, tools, data that you need that much harder. So one of the big headaches is just the time and effort it takes on the internal change management effort. But I would always advocate that you do it, that will actually be materially more important to you and the company to get everybody to understand what it is that you do and why you need these resources. And I guess one of the biggest headaches is if you kind of don't address this stuff, if you don't start actually stopping doing things or moving things that you shouldn't have been doing elsewhere, not educating the internal organization about what it is you do. You can and I've seen this happen in other companies, you can see a phenomenon where everyone else in the company assumes that the long term health of customers is the responsibility of a particular department, the CS department, because they've got the word customer in there, customer and success in their title, right?
Rav Dhaliwal (27:28):That is something that's what I call a silent killer, because if the rest of the organization is in this production line, because when I've done my bit and I've done what I've asked and I handed it over, and when after I've handed over I do not care, because I've optimized for what I've been asked to do. Because at the end of the production line is the people who are responsible for the long term well being of the customer. Those organizations may have a short run at being successful or a medium run, but they'll ultimately fail.
Remco (27:54):Yeah. So that touched upon change management, right? And you mentioned that as well. I always think change management is an interesting one, it's often talked about in customer success as well. So how does a CSM or how do you as a CS leader actually do that? How do you handle change management within your organization? And also, to what level or to what bar do you need your organization to understand what you do as a customer success manager?
Rav Dhaliwal (28:23):That's a really great question. I was on a call the other week where... The other day actually where this question about change... I think change management is a little bit like customer success, you can ask people for a definition, if you ask 10 people you will get 10 different definitions. But at its core, the way I like to describe is, project management is about the delivery of tasks, change management is about the delivery of behavior change. What you're trying to do with any change management effort is to change the behavior of the target audience. And that's why I think you hear a lot in CS terms, because if you introduce a new piece of software into a company, what you're actually doing is introducing in a change in the way certain people work. So that's why change management skill is very, very useful.
Rav Dhaliwal (29:04):A very big part of change is, first of all that point I made earlier, driving awareness of the change. Awareness of the CS function, what does it do? What channels can I educate people on? Can I go to the sales and marketing team meeting and stand up and do five minutes on what the team does, right? That awareness should also explain what the risks are associated with not having the function. So actually, guys, if we didn't have a CS function, these are the risks to the business. That's just as important as explaining what you do. You want to be doing that awareness ongoing constantly. It's got to be reinforced, reinforced, reinforced. Classic example is, I don't know a single sales leader that does not ring a real or a virtual sales bell every time a deal gets close to the add value. Why is it not a CS leader doing the same every time one of their customers renews or renews and expands? That's an example of what you could do to drive awareness.
Rav Dhaliwal (30:04):When people have an awareness of what you do and you're reinforcing that, they will hopefully have more of a desire to engage with you, because they understand the value that you are driving. And I think those are just kind of that communications effort, that ongoing education effort, is I think something that's often lacking because the CS team is so busy just firefighting every day, their focus is outward to the customer. And they don't have the time or the resource or the inkling to focus some of that effort internally, to educate what they're doing and show the good value that they're adding.
Remco (30:37):Yeah, I was about to say, because it's such a seemingly easy answer, or an easy thing to do. But it's probably very, very costly in terms of time. But yeah, you need to start somewhere obviously.
Rav Dhaliwal (30:50):You have a quarterly all hands or a company all hands, why can't you get a slide in there in one minute to say, "Hey, this is what we're doing. This is what the team does." It doesn't have to be that big. It's more about reinforcing the message. Now, almost every company in the world has some form of internal collaboration or communications channel, use it that's what it's for.
Remco (31:09):That's fair enough, called me out on that one there. Definitely needs to be done. You made the struggles very clear from a leadership perspective. But how does this actually affect just regular CSMs? Assuming you have the right people of course.
Rav Dhaliwal (31:23):Yeah, of course. I mean, it can just be very demotivating. If you're reactively firefighting, it's really tough. It's even tougher, if people don't understand that's what you're doing, or you don't get any recognition for it. That can cause good people to leave, go elsewhere, will definitely cause drops in productivity. So I think that's one of the biggest impacts of not focusing on these things that are missing or that need fixing is it will really cause your team to struggle, it will just not make their working lives particularly pleasant if they're reactive all the time, and they don't... Actually, being reactive all the time, it's very hard to understand the purpose of your work. And if you don't actually understand the purpose of meaning of your work, you're not going to be engaged in it. It will just wear you down after a while. And that's the thing I've always worried about the most as a leader is, how engaged is the team? Can they see the outcome? Can they see the purpose of what they're doing? Because otherwise, they'll very quickly get demotivated.
Remco (32:25):Awesome. So you recently co-wrote an ebook with our CEO, Robin. And it's meant to be a first step at defining a customer success technology stack. So focusing on technology and software that's actually purpose-built for CS teams. Can you give a brief overview of your thoughts behind that, and maybe also touch upon how purpose-built technology can actually help customer success teams facing problems? For example, while they're actually scaling their business.
Rav Dhaliwal (32:57):I'm assuming everyone listening to this will have seen the announcement about Gainsight and obviously their investment with VISTA in becoming the first sort of CS technology unicorn or billion dollar valued company. And Nick and the team..
Remco (33:10): Major milestone.
Rav Dhaliwal (33:11):Yeah, huge milestone, great for the profession and obviously huge kudos to, to Nick Mehta and the team at Gainsight. But it did sort of highlight to me, and I think to Robin as well, that even though CS in it's sort of current form has been around for probably over 20 years, that it's still remarkably underserved by technology. Sales has its own tech stack, marketing and HR have their own tech stack. CS does not have a tech stack, it begs and borrows and uses little bits of existing tooling. And that's what I think will need to be addressed in the coming years. If the profession is really going to mature and actually be in a position to start driving a broader understanding industry wide of what it does, it's going to need the tech that helps it enable that to be a force multiplier.
Rav Dhaliwal (34:04): So in the same way that CS teams are an accelerant of value to their customers, purpose built technology is an accelerant to the work that the team does. It helps them do more with less, it helps them use data to make smart decisions, all those things that marketers have access to, salespeople have access to, CS people currently don't really have a lot of access to you. You gave an example earlier of a leader who has to go to other departments and persuade them to get what they need. That would not be the case if they had purpose built technology. So the kind of thinking behind the ebook was, "Well, why don't we amalgamate what we know. And what we know works well in terms of existing technology at these different stages we talked about the product-market fit, scaling stage, the growth phase, the go-to-market fit stage, and that will give people a sort of a practical guide and then maybe we can set out a vision for what we think purpose built technology for CS would look like and see if the readers chime with that vision or see if they have any thoughts about it. Because that I think is really where the profession needs to go now. It needs to start defining itself and defining the tech, it actually needs.
Remco (35:14): Yeah. And we also use the words purpose-built, obviously, religiously for this. So yeah, I love that you basically saying a purpose built technology for any function can also act as a business accelerant.
Rav Dhaliwal (35:27): Yeah.
Remco (35:28):And from that perspective, it's obviously a shame that barring CS tooling like Gainsight, for example, as we previously mentioned, there isn't much else, which is weird, right? So why do you think this is the case? Why do you think that CS teams have so far pretty much been underserved? I would actually say underserved by technology, is this an organizational problem? Or do CS teams just simply not care? And are they fine with using other types of technology that's actually not built for a CS team but for marketing, for example?
Rav Dhaliwal (36:01): No, I don't think it's a case of the CS teams don't care. I think it's goes back to the core of there isn't a industry wide understood cogent standard definition for what the team does. If you have a function that hasn't got a definition, how are you ever going to build software for it? I could build software for sales, because I know what sales does, I can build software for engineering, I know what they do. And this isn't the problem with CS practitioners, this is because CS is highly contextual. What it takes to make a customer successful is different depending on your product, your service and what stage your company is in. And so that's why I'm driving this idea of a common definition, I think would be incredibly valuable, because then you would have very smart people out there and entrepreneurs going, "Ah, actually I can help be an accelerant there, I can build a product or a set of tools or capability that will help these kinds of groups in their mission to accelerate value."
Rav Dhaliwal (36:59): So I think it boils down to that, that lack of definition. And I think it's also tied to the fact that the lack of definition leads to this everything departments syndrome, the everything department syndrome means you are firefighting and reacting, which means it's harder to get a budget for things. So you're just going to beg, borrow and steal the existing stuff you can get your hands on. So I think it's kind of almost out of necessity.
Remco (37:21): Exactly. So we're stuck in this vicious cycle. That is taking us back to tooling that are definitely not built for CS teams, unfortunately. That's a grim scenario.
Rav Dhaliwal (37:34): I can think with people like yourselves at inSided and some other entrepreneurs I'm talking to you right now, that is starting to shift. So I think people... And I think actually COVID, may have been a bit of an accelerant there. Because companies have started to realize, "Oh, with this kind of really crazy situation we all find ourselves in, I've got to double down on my existing customers."
Remco (37:58): Yeah, exactly.
Rav Dhaliwal (37:58): And so, there's people out there that I'm talking to that are building specifically for the audience here, because there's been a sudden realization that actually without my existing customers, I'm not really a viable business. And so hopefully, I think we're starting to see a shift in the change there.
Remco (38:18): Yeah, and I think we are. It's a fun, sort of... Let's call it a fun fact. So Gainsight, obviously is one of our customers as well. And when they at some point submitted a G2 review for us, that review actually got declined by G2. Because they actually saw Gainsight as being one of our competitors. And they really are not. So this is... I think that's an interesting sort of top level view on how at least the technology market for customer success is perceived out there. We're all basically building the same thing while we're really not.
Rav Dhaliwal (38:50): Yes, indeed. Yeah. That's a great illustrative example. Thanks, Remco.
Remco (38:55): Yeah, awesome. All right. So I see that we're out of time, I quickly want to do the lightning round as well. But first off, thank you for sharing your wisdom with us today, again, Rav. I'm sure there are a lot of topics that we’ve yet to cover, but unfortunately, our time is already up. So one thing that we always do at the end of the episode is a lightning round, four but in this case three very quick questions, and possibly even quicker answers.
Rav Dhaliwal (39:21): Okay.
Remco (39:21): Are you ready for them?
Rav Dhaliwal (39:23): Sure.
Remco (39:23): Awesome. Number one, what's the one piece of technology that's currently missing from a CS perspective? Or the one thing that existing tooling can't do?
Rav Dhaliwal (39:33): Tell me how my customers are feeling.
Remco (39:36): Ooh, sentiment.
Rav Dhaliwal (39:37): Yes.
Remco (39:38): This is a good one. Yeah, this is now normally done manually by CSMs? I guess.
Rav Dhaliwal (39:42): Objectively, manually, yeah, maybe broadly with a blunt tool like NPS, but yeah, we really need some tooling that is keeping tabs on that for us on an ongoing basis.
Remco (39:52): Awesome. Yeah. Anyone listening who's working on this, definitely let us know we need it too. Number two, favorite tool you can't live without?
Rav Dhaliwal (39:59): Oh Calendly, 100%, amazing.
Remco (40:01):I totally, totally guessed that you were going to put Calendly there.
Rav Dhaliwal (40:05):Yeah.
Remco (40:06):I knew that. And this is also the way that I usually grab in contact with you.
Rav Dhaliwal (40:11):Yes indeed.
Remco (40:13):And then name one person in customer success that should be on this podcast next.
Rav Dhaliwal (40:19):Really great question. This person is not a customer success person, but they should be on the podcast. It's Mark Roberge, who was their former CRO at HubSpot, is now also an investor. His book, The Sales Acceleration Formula, I think, is actually one of the best CS books that's not about CS out there. And I think he would be an incredible guest and have a lot of wisdom to share I think.
Remco (40:41):It's already a great title as well. The CS book that's not about customer success.
Rav Dhaliwal (40:45):Yeah.
Remco (40:45): Love it. Okay. I'm definitely going to try. This will be a major win to get him on. But let's see. Awesome, then... Yeah, there's nothing left but me thanking you for your time, Rav.
Rav Dhaliwal (40:55): Oh, my absolute pleasure. And I hope it's been useful and thanks again for the invitation.
Remco (40:59): No worries. Thank you.
You’ve been listening to The inSide Scoop. For more episodes or webinars check out our Webinar & Podcast page and learn more about customer success communities.