Episode 226 Oct 202665 min
Manuel Harnisch has worked through every big shift in B2B software, from on-prem appliances to SaaS, data and now AI. He led customer success at Kentik, People Data Labs and FOSSA. We talk about winning the renewal in the first 90 days, using data to get sales to walk away from bookings that would never pay, taking GRR from 70% to the mid 80s, and why customer success is the real sales team.
The episode in 12 points. Each timestamp plays the video from that moment.
Sales promises can run ahead of what the product delivers. What makes a customer feel good about a purchase is reaching first value, and what that looks like differs from customer to customer, so capture it in a programmatic way. If you are three months in and still talking about connecting systems, that is a red flag. In the rapid fire, Manuel named first value the most underrated CS metric.
At SevOne, every update had about a 99% chance of breaking something for someone. Great people, great customer relationships and a strong vision kept customers around anyway. But when the market moved to SaaS, a long-time customer still left, and even pointed Manuel to the company they were moving to: Kentik.
People trust people and buy from people. The product still has to deliver, but ultimately the relationships come first.
Manuel Harnisch
With perpetual licenses you made the money up front, so post-sales care mattered less. In SaaS you re-win the business every year. At Kentik, Manuel insisted that post-sales show up the way pre-sales did: CSMs and CSEs who could talk to the customer at the same level as the AEs and SEs, with a seamless handoff between them.
Renewals, in my mind, are won in the first 90 days.
Manuel Harnisch
Nice-to-have products get dropped when times are bad, so the product has to solve a core pain. On top of that, Manuel trained the Kentik team to ask what customers would be doing two or three quarters out: new PoPs, data center build-outs, international expansion, things mentioned in public filings. Getting ahead of that capacity is how existing customers drove about 20% of new ARR, with peaks near 50% when remote work hit in 2020.
At People Data Labs, a few large multi-year bookings went to unfunded startups that paid once or twice and then stopped. Manuel took the invoice data to the founders: a booking from a customer with no capacity to pay is not really a deal, and keeping it on the books only means a write-down later. The cases were few by count but large in revenue, so the fix was clear gates, not a blanket ban.
Everybody can have an opinion, but if you bring data, it's a much stronger argument.
Manuel Harnisch
Seed-funded companies were still welcome, but on full prepayment. Insisting on monthly or quarterly billing became a red flag. Other options were supplying only as much data as the customer could afford and growing from there, a much smaller commitment on both sides, or an equity stake as a backstop. Each was worked out deal by deal.
People Data Labs sold data that customers build products on, so they needed engineers, not just relationship CSMs. Instead of a separate SE team, Manuel made the pre-sales engineer the same person who supports the customer after the sale. Whatever was promised on data could be delivered, and that continuity led to larger deals.
Before a deal reached CS, the team had to know what the customer was doing with the data, what their ingestion process and systems looked like, which engineers they had and who owned success: a C-level sponsor or a VP of Product. Tracking that gave CS a warm start. The other half is mindset: sales that chucks deals over the fence is toxic for the customer relationship.
At FOSSA, four generalist TAMs split around 120 to 130 customers, each doing everything, so the noisy accounts got the time and the rest got what was left. Manuel reorganized into CSMs and CSEs with clearly defined books of business. Small, self-serve customers got no technical resource, and the ones with real technical needs got the most. More integrations got done, value came faster and GRR moved from about 70% to the mid 80s.
Customer dossiers for the top 50 accounts used to take two people a month and were outdated the day they were finished. AI can now build them on the fly from calls, email, tickets and Slack, with a human reviewing and probing. That lets one CSM carry a much bigger book, perhaps alongside five forward deployed engineers, but cadences nobody reviews still put customers off.
Champions buy from other people, and they renew with people, not necessarily with AI.
Manuel Harnisch
Many founders believe their product is good enough to not need customer success. But anyone can out-execute you tomorrow, and shipping faster is a race to the bottom, like competing on price. The reverse is also true: a top power user that nobody talks to can drop to zero overnight, because they were quietly switching away and nobody had the relationship to hear about it.
Outcomes, happiness and NPS are directionally interesting, but they do not matter if customers don't renew and accounts don't grow. Some of the best CSMs Manuel has seen were burnt-out salespeople who wanted to go deeper. He has been saying CS should be revenue-forward for 20 years, and leaders are only now coming around to it.
None of this stuff matters if people don't renew and you don't grow accounts.
Manuel Harnisch
Two options per question, no third answer allowed, and only one follow-up.
The one follow-up: if not QBRs, then what?
Edited for readability: filler words removed and grammar fixed, nothing cut. Click any timestamp to play the video from that point.
Hello everyone, I'm Dhiraj, and welcome to The Second Year. In this show, I talk to customer success leaders and ask them what worked, what didn't, what failed and what has changed since they got into this. Today's guest is someone super special. He has done something super crazy: he has been part of every major tech revolution of the last 25 to 30 years.
Welcome, Manuel, and thank you so much for doing this. How do you feel today?
Thanks, Dhiraj. Thanks for having me. I feel great. It's Friday, right? And this is one of the last calls I have, so I'm ready to go.
Awesome. Probably the last for me too, but we're in very different time zones.
Yes, that's right. You're closer to midnight, for sure.
Awesome. Manuel, help us understand you as a human being first. Outside of work, who is Manuel, and how did you end up in customer success?
Well, outside of work, I've turned into quite the runner over the last six years or so. You wouldn't recognize me from before 2020. I was quite a bit heavier. I enjoy trail running. I try to do anywhere from 60 to 80 miles a week in total, and I compete in various trail events from time to time. That's a big part of my life. I also travel around different places in the US. I'm currently in Albuquerque, New Mexico, and I spent the summer in different places in Southern California. So that's me outside of work.
And how did I get into customer success? Well, how does anybody get into customer success, right? You sort of fall into it. It wasn't a conscious decision. I grew up with a knack for technology. I got my first computer when I was about ten. It was a Commodore 64, which really dates me, because that thing was already outdated when I got it. I hacked around on it and learned a bunch of stuff, and a couple of years later I got my first proper computer. I just enjoyed it, and I knew I wanted to do something with technology and computers since I was probably fourteen or so.
I didn't quite know what. For a while I wanted to be a programmer, and then somebody pulled me aside and said, that's not where the money is. At least at the time it wasn't. Maybe it's different now. They said, you should be in technology, but you should be customer facing. So that's how I stumbled into it. I did my first startup in 2008, in support, and then pre-sales and post-sales engineering. From there it morphed into customer success.
Awesome. Do you feel betrayed that this person told you that's not where the money is?
I'll say this: I probably would have been a really mediocre programmer. Back in the day, when I was 16 or 17 and first got hold of a DSL connection that was faster than dial-up, I started to learn to program in Perl. Before that I learned Pascal, Turbo Pascal, which was really common in Germany as the entry language back then. I didn't know what to do with that. But then Perl came around and I thought, this is really cool.
I started building something, and when I tell people this, they laugh at me. This is around 1999, 2000. I started writing community software, with the idea of a place with forums, a chat, maybe a bulletin board, where people have logins and all that. A couple of years later, somebody else built exactly that. It's called Facebook.
I never launched my early version, because I'm one of those people who learn as they write, and every time I learned a new concept, I decided to rewrite the code. So I never got to a point where I had anything to ship. Long story short, I probably would have been a really terrible developer. I'm a bit of a perfectionist, and it just never got off the ground. If I think back, was it the right decision not to pursue it? Probably. I probably would have been pretty mediocre.
Awesome. Good perspective. There's one question I ask almost every guest on this podcast before we jump into their career. What is one thing that changes between the moment a customer signs and the ninth or tenth month of their first-year contract? What changes the most, that most CSMs miss?
I think it's the definition of first value for a customer. Of course you have the sales process, and lots of times there are promises that maybe exaggerate what the product can deliver. But ultimately, if I put myself in the customer's shoes for a minute: when do I feel good about a purchase? When I get first value from what I've bought.
What that looks like can be very different from customer to customer, and not capturing it in a programmatic way can be a differentiator. If you're three months in and you're still talking about getting systems connected and you haven't delivered first value, that can be a huge red flag and a huge miss for a CSM.
And which was the first account that taught you this?
The first account? I can probably give a more recent one. At a company where I was full time, we had sold to a defense contractor, and they had a very specific idea of what value would look like. The reality was that we could not meet their deployment requirements. In that particular scenario, the person who brought us in had budget to spend, but they weren't really committed to staying there long term. Then they moved on, and the account got handed to somebody else.
We came back in and said, here's what you need to do to even get to first value, and they said, we're not doing any of that. And I thought, okay, this is a pretty clear misalignment between what we can do and what your expectations are. That's a recent example, from the last couple of years, but I can probably think of other ones too.
Got it. Manuel, jumping into your career: in your first job, you told me you made 150 calls a day to German customers of American companies, probably at 3 AM in the US, just to get satisfaction survey responses. And out of those 150 calls, you would get maybe two or three responses a day.
That was a good day. That was a good day if you got two or three.
Perfect. So help me understand: what does it take to get time with customers who think they don't owe you anything?
What does it take? Gosh, this was back in 2002, long before the internet. We were literally calling people's landlines. Back then there wasn't much incentive for a customer to give you any feedback. When you called them, they'd say, why are you calling me? Often you didn't even have their direct contact information. This was long before Clay and all the enrichment tools that can get you information on a specific person.
So it was often, hey, we want to make our product better, you owe us that information, Mr. Customer, we want to hear from you. But there was nothing to give them. What we've seen since is that customers often get rewarded for giving feedback. I get a bunch of companies reaching out on behalf of products I've used and bought, saying, we'll give you twenty bucks to give us some feedback. Okay, great. That actually gives me an incentive.
The last thing I'll say on this: the customers who want to give you feedback will find a way to give you feedback. They don't wait for the phone call from a survey company. They come to you and say, hey, I have some thoughts and I want to share them. Those are the people you should listen to.
Absolutely. Now moving on to your first official job, which was SevOne. You told me a beautiful story from there. One of your customers told you they were moving from SevOne to Kentik, and that you should explore Kentik as your next thing. How did that conversation happen? What went wrong with that account in the first place, and why did the customer tell you to look at Kentik?
Yeah, and let me add a bit of context. I spent almost nine years of my career at SevOne in total. This conversation probably happened about seven and a half years into my time there, so not at the very end, but towards the end. I spent a lot of time and effort with them over the years, helping build up the product, giving feedback, streamlining a bunch of things, and obviously working with customers and helping them get value.
The reality, and this is unfortunate, is that the company had gotten to a point where it was really difficult to ship enhancements, for various reasons. The number one reason was what I would call tech debt. Every time we wanted to change something, make enhancements or add new features and functionality, there was a risk that we would break major things. In fact, it wasn't even a risk, it was almost a guarantee. If we shipped a new update, there was a 99% chance it would break something for somebody, and we didn't know what was going to break.
It became very clear that the old waterfall style of development was going to be very difficult to sustain for a company trying to grow. Think back to before continuous integration and modern CI/CD pipelines. You had versioned software, and you weren't constantly testing things. Automated unit tests were a foreign concept to us at the time. So lo and behold, we had gotten to the point where the software was pretty brittle. It would do things, but it would often break, and if you touched it to change something, that was more or less a guarantee of disaster.
But we had a great relationship. The reason we were so successful despite all of that was that we had great people, great relationships with customers, and we were selling an excellent vision. That's what got us to the scale we were at.
When we had that conversation, this person, whom I had worked with as a customer for many years, said: hey, we really like you, but we're going to pivot away from this technology, which was on-prem and in an appliance format, towards a more SaaS-friendly way of doing things. This is the company we're going to choose. They're still very early, and it sounds like you could really benefit them and vice versa. That's basically how I got introduced there.
The last thing I'll say is that people trust people and buy from people. The product still has to deliver, but ultimately the relationships come first.
So you would probably call that a product failure, but not the product team's failure. It's more about how the technology evolved and how people's requirements changed over time.
Yeah. It's hard to have a definitive root cause for this. Maybe the best way to put it is atrophy. This is true for humans too. If you let muscles atrophy, meaning you don't exercise them and you're not vigilant about your training, they're going to decay over time. I think the same is true with technical debt. If you're not watching it like a hawk and constantly looking to improve things, it's unfortunately going to deteriorate. I think that's what happened there, along with lots of little decisions along the way that influenced how we got there.
So a mix of a lot of things. You arrived at Kentik after leaving SevOne, along with one of your customers, because they kind of asked you to join, right? What was... sorry, do you want to correct that?
Well, to be clear, they hadn't bought Kentik yet. They were going to, independently. It's not like I made the introduction or that I had to choose. They said, this is something we're doing. They still had a one-year contract left with SevOne, so there was runway. But it was a decision they were making.
Okay. What I'm pointing at is a broader problem. You saw one of your customers leave your technology for someone else's. What did you want to solve first at your next job, so that this doesn't happen to you again?
Yes. Well, I knew the delivery format would be very different. Kentik was SaaS-first and SaaS-native. There were no appliances. They did some on-prem deployments, but those were still run as a SaaS cluster, meaning we had full control and made sure customers couldn't modify things. I think the most important early realization was that in a SaaS model, you constantly have to re-win the business. Yes, they signed at least a one-year contract, and you convinced them to do that. But then you have the renewal coming up. And renewals, in my mind, are won in the first 90 days.
That means you have to deliver value very, very quickly, and you have to make sure customers trust you and that what you promise in sales is what you can ultimately deliver. So I overemphasized that we have to show up post-sales the same way we showed up pre-sales, deliver on those commitments, and build a team around that. We had AEs and SEs on the pre-sales side. We needed CSMs and CSEs on the post-sales side who could talk to the customer at the same level, with a seamless handoff between the two functions. That was a really important part.
Compare that to the old appliance model at SevOne. You would ship these things and there was a maintenance line, but you made all the money up front. They were perpetual licenses, so it didn't matter as much to take care of customers post-sales. You still wanted to, because you wanted the maintenance line, but once they signed, you could move on to the next thing. That's just not true in SaaS. And quite frankly, it's not great for relationships either.
Absolutely. And when you compare on-prem to cloud-native SaaS, do mention the years, because otherwise the audience will wonder who these two people are, still talking about on-prem solutions and the transition to SaaS.
You know, it's funny. Kentik was acquired recently by Infoblox, which still primarily sells on-prem appliances. So this is still a big business.
That's awesome. Nice. I found an interesting fact on your LinkedIn. You mentioned that at Kentik you built something that got you 20% more ARR from your existing customer base through upsells and expansions. And in some peak quarters it was actually 50%, not 20%, averaging out to around 20%. So, two questions. First, what did you do to get that 20% average ARR increase from the existing customer base through upsell and expansion? Second, was there a pattern among the quarters that gave you those 50% peaks? Can you generalize the insights from those two things so the audience can take something away and use it at any company?
Yeah. I'll start with the generalization. This is probably one of the most obvious things somebody could tell you, but I think it's also one of the most important: you have to have a product people want. What do I mean by that? Lots of companies out there are building nice-to-have products. Hey, this is a workflow improvement. Okay, great. But what happens if something else comes along and does it slightly better? People will switch to that, or they might abandon it. Or, if times are bad, they may decide it's not important enough.
I've seen that. Later in my career, I saw a different company whose whole product was built around a nice-to-have for the legal team. That was fine when times were good and less important when times were bad. So I guess the meta takeaway is that your product has to solve a real pain. It has to be a painkiller. It cannot be a vitamin. There can be vitamin components, like, hey, this helps my lifestyle, and that's great. But it has to solve a core pain in your business. We had that at Kentik, and to this day I'd say they do. Observability, knowing what your network is doing and preventing outages is critical.
Now the 20% piece, and I'll get to the 50 in a second. I think the most important aspect was that we trained the team to be inquisitive about what customers would be doing two or three quarters from now. What do I mean by that? The main customers were deploying this to monitor their data centers and their edge. Customers would often plan data center build-outs two or three quarters into the future. We would ask, hey, what does your roadmap look like for the next year? How many new PoPs are you opening? Are you expanding internationally? We read this in your public filings, or we read this in a blog post. I trained the team to be as proactive and inquisitive as possible.
That allowed us to go to customers and say, this is what we understand, you should plan capacity for it, and we can make sure you have the monitoring capabilities. The other thing we told people was that it takes us a bit of time to scale up our infrastructure. So if you have those plans and need us to monitor that, let's get in front of it now, so we can support you once you're ready. That's a big part of it.
Now the 50%. By the way, these percentages are revenue contribution as a percentage of the total for the quarter. Most of our business still came from net new logos, but there were some quarters where we produced half of the net new revenue for the business. There were definitely some interesting times. If you all remember 2020, Q1 was kind of, what the hell is going on? Then in Q2, when everything shifted to remote work and working from home, a lot of our customers said, we have massive build-outs, massive demand on our networks right now, and we need to build it yesterday. That really helped.
Externalities can totally influence your overall billings, and I know this was true for other companies as well. There was a whole platform, what was it? Not Greenhouse. The house party app, I forget what it's called now. You may remember it. Everybody hung out there and did remote meetings. It basically came about during COVID and then disappeared, but there was massive demand for something like that. Clubhouse, that's what it was called. So yes, externalities like regulation can have a big impact on your business as well.
So if I summarize: the 20% relates directly to coaching your team to be inquisitive about your customers' goals and how you can help them achieve those. The 50% was mostly the impact of broader happenings in the industry or the world, and how you capitalize on things like that for your business.
Yes. In this particular case, that is largely true.
Got it. Awesome. Manuel, moving to your time at People Data Labs. This is the best question for me, at least, and I'm really curious about the answer. At People Data Labs, you got sales to stop signing customers who matched the profile of companies that would end up not succeeding with your product. Let me tell you very honestly: most CS leaders fail at influencing this decision at the table. What made you able to convince the committee to approve it, to leave some money on the table and not sign customers like this? Where did you find the problem, how did you approach it, and how did you convince people?
Yeah, that was certainly an interesting scenario and an interesting time. Here's the reality. There's a saying: anybody can bring opinions, but if you bring data, that's gold. There's a different way to frame it, and I forget how it goes now. But in any case, everybody can have an opinion, but if you bring data, it's a much stronger argument.
We had a few what I'd call large-scale bookings where, upon closer inspection, we had delivered what we sold them. We were selling data, and we delivered the data files. But after talking with finance and looking at where the invoices were, they hadn't paid. Or maybe they paid the first bill. They were on installments, paying monthly for a multi-year agreement. You'd get one or two payments and then no payments for six months. And you're thinking, well, okay, why?
You follow up and look, and you realize we sold this to a startup that was unfunded at the time. A company that probably had, I don't know, $500,000 left in the bank, and this is an expensive product. A couple of months later they were supposed to raise a Series A or something like that, and they ended up not being able to, but they didn't tell us. Nobody wants to tell you when they miss that.
So now you have a decision to make and an interesting problem. Do you consider that revenue? You made the booking, but what do you do now? It's a three-year commitment at, say, half a million dollars a year. Substantial. It wasn't a massive situation, but we definitely had a couple like that, where we sold something, a big booking, and then no payments came. In some cases they wouldn't respond once we delivered the data. They may have paid for the first year, but it was unlikely they would pay for the future.
So I brought that data and basically said: look, while I agree this is part of our ICP, we need to do a better job qualifying whether somebody can actually pay us. Just because you get a booking doesn't make it a deal. I could come to you right now at your org, sell you a half-million-dollar deal and book it. If you're never going to pay me, if you have no capacity to pay me, that's not really a deal.
So it was effectively a conversation about what we wanted to do with this. If you want to keep it on the books as a founder, that's your prerogative. But in terms of ethical revenue recognition, we should not take that, and we should do a better job qualifying some of our customers. That goes back to KYC and understanding where customers really are. There was some resistance. People said, maybe they'll pay, maybe they'll get funding. And I said, then you may have to take a write-down later, which will hurt your valuation and other things. So you might as well clean it up up front and set clear gates. So yes, it was informed primarily by data.
Got it. Perfect. What was your source for understanding this? Did you change the ICP from, say, seed-funded to above seed-funded? Or even if they were seed-funded, were you running certain qualification checks to find out whether they'd actually be able to pay you? If that was the case, how did you do it?
Well, one easy one: we were fine taking seed-funded companies, but we would make the payment terms full prepayment in advance. If you can prepay us, it's a qualified deal. If you're not willing to take that as a term and you insist on quarterly or monthly billing, that's a red flag and something for us to consider.
There are other ways to potentially mitigate it. You almost take a covenant on a company like that: okay, we'll still do the deal, but we'll only supply as much data as you can afford on an ongoing basis, and as you can afford more, we'll give you more. That's another possibility. Or you propose an equity stake as a backstop: if you don't pay us, we own X percent of your company or something like that. We were willing to consider that in some situations. So there were ways to tighten it and still take the deal, but we had to work it out on a deal-by-deal basis.
And since you said this came out of data: I'm sure it wasn't 100% of the companies you signed from that cohort that didn't pay. There would be a split between companies that didn't pay and companies that did. What was that number? Was it convincing enough for anyone to agree? If it's a 90/10 split, I think people will agree just by looking at the data. What was the number, and was the conversation difficult?
Well, what it ended up being was a small number by count with a large revenue commitment. Those are usually your most strategic customers. So the conversation circled around: what if we still take those deals, but at a much smaller dollar amount, with a much smaller commitment from our side?
Got it. Fair enough. And on LinkedIn you mentioned that you built a system at People Data Labs that got you 33% additional revenue on an annual basis. What were the key levers for such a high number? Was it similar to your work at Kentik, or something very different given the industry nuances?
I think the key similarity was that we needed people who could speak at the customer's level, who were engineering focused and could actually help them integrate the data we were selling. Keep in mind this isn't a consumer-facing dataset. People build products on top of it or integrate it into the products they're building. So having not just CSMs, who are relationship focused and can negotiate, but engineers on both the pre-sales and post-sales side who can deliver the value being promised, was a key takeaway.
The one thing I did differently there compared to Kentik: at Kentik we had an SE team that was separate from customer success, and I had a CSE team, a customer success engineering team, as part of my remit. We worked well together, had clean handovers and everything worked out. At People Data Labs, within my first couple of weeks, it became clear that we needed an SE team going forward, because we were going upstream in terms of sophistication.
I made the decision to have that be the same persona. Your pre-sales engineer also supports your customer post-sales. It's not as much of a heavy lift, and you don't constantly have to help them, but you have the full context. Whatever you promise data-wise in pre-sales, you can actually deliver post-sales, because you own the same thing as the SE. That's ultimately what I think led to larger deals and more success, because customers had that continuity.
Since you mentioned handovers: to be honest, I feel it's very difficult for anyone to say their handovers are well coordinated. The reason is that handovers are usually handled by humans, and humans have different perspectives. What one person interprets from the same information is very different from what another person interprets. For this revenue to happen, you definitely needed a better handover system. Was there a key thing you put in that layer that helped the team do a better job?
Yeah, and I'll frame this by saying a lot of this was pre-AI. All of these businesses were pre-AI, and AI has made this a lot simpler now. But it was about having a defined set of things you should ask for, the things that need to be known for a customer to be highly likely to succeed. What did that look like? At People Data Labs specifically: what are they doing with the data? Are they building a product? Are they using it in their own processes? What does their ingestion process look like? How sophisticated are they? What systems do they have in place to take this on right now? What engineers do they have? And who is ultimately going to own the success of this? Is it a C-level initiative? A VP of Product? Who are the people and the systems, and do we know them from the sales process?
By requiring that as part of the handover process and making sure we tracked it, it became a lot easier for the team to say, okay, we feel confident here, we have a warm introduction and we can hit the ground running. To me it's both a systems challenge and a mindset problem. I've seen other organizations where sales says, we do our thing, and as soon as we get the deal, we chuck it over the fence, good luck. I understand motivationally why that is, but that mindset is really toxic for the customer relationship. You want your sales team to be invested in the success of what they just sold. And at the same time, you want your CS team to be excited about the customer they're about to get, instead of thinking, here's yet another one where we have to figure out what we actually sold.
Fair enough. Awesome. Now your time at FOSSA. Your LinkedIn says that when you got there, retention was pretty low, GRR was around 70%, and you moved it to the mid 80s. Can you walk us through that project briefly? How did you figure out the problem statements, what did you do to solve them, and how did those results come about?
When I first got there in October 2022, the team were what I'd call generalists. They were defined as TAMs, technical account managers. The idea was that they would handle everything from renewal negotiation to executive relationship mapping, champion tracking and those relationships, to technical implementation, working with the engineers to actually get the product into their CI/CD pipelines, and so on.
I think we had around 120 or 130 customers at the time. Don't hold me to that number. With four people, split equally, that's really tough, because any one person ends up with about thirty customers. Of course a few are really noisy and demanding of time, and everybody else just gets what's left over.
I've seen the TAM model work selectively when you have very large, very strategic customers who need somebody to embed themselves deeply. But then a TAM typically has one, two, three, maybe five customers in total. That's the capacity they have, because they work deep. That wasn't where we were at FOSSA. So I looked at the team and the skill sets and thought, maybe it makes more sense to have relationship-focused people who can negotiate, and then technical people. Most of the people we had were actually really technical. They just weren't CSMs in the traditional sense.
So I decided the team should be organized as CSMs and CSEs, similar to what I'd seen before. I hate having a cookie-cutter approach, but with highly technical products, and FOSSA is super technical, Kentik is super technical, SevOne is super technical, People Data Labs less so, it makes sense to have a technical specialization and a relationship specialization. I decided very quickly that this needed to apply here too.
We realigned some of the folks on the team. We had a bit of a downsizing as well, and then rehired some people to get to that model. Then we had very clearly defined books of business for the CSMs. Some customers got no technical resource. If you were spending a small amount and were more or less self-serve, you didn't need one, so we didn't spend time and effort there. The customers where it made sense, who had technical challenges or just needed extra help, got the most technical resources. That basically helped us get over the hump with a lot of them, because we were more focused, we got more integrations done and ultimately got value to those customers faster. That was the build.
Got it. So if I summarize, the major problem was the process and the team structure. You broke it into two divisions: one focused on implementation and the technical side, and another focused mainly on the commercial and relationship side. Now that AI has come into the picture, do you think these two will exist separately for any kind of business? Your answer could be different for different kinds of businesses.
I think what AI has done is allow us to be a lot more efficient and do less of what I'd call busy work. One example: we did an annual review of our top customers, and I had the team put together what I call customer dossiers. Here are the key players, here are the key conversations we've had with them, and a bit of a SWOT analysis: where were we really great, what are the risks, what are we hearing? That generally fell on the CSMs, but they had to go to all the different parts of the business, and obviously talk to their customers, to assemble it. It's a heavy lift. We're talking about doing it for 50 customers with two people. It was a month-long process.
The challenge was that it was outdated the minute it was finished, because more stuff happened. Two weeks go by and there's more information. In a case like that, AI can build it for you on the fly, as long as you're very clear: here's what I need you to do, and here's how often it needs updating. It can gather all the data sources: your call recordings, your email exchanges, your tickets, your Slack channels, all of it, as long as it's connected. Then a human still reviews it and says, yes, I agree, or, I have a slightly different view, and inspects and probes it, without spending a massive amount of time on it. That lets people focus on what they're best at, which is building relationships and doing the follow-ups, rather than gathering data. I think that's one of the biggest enhancements and advances.
I think it also lets you automate the long tail a bit more. We're always talking about scaling customer success and digital customer success. You can do that much more easily with AI now, because you give it the playbook and it puts the sequences and cadences together. But I think it's important to still have a human in the loop. I certainly receive a lot of cadences from companies I've bought products from, and I think, this is totally not relevant to me, and I can tell it's not human audited and reviewed. So it's of very little value to me. In fact, it might even make me not want to work with those folks anymore. So you still need people as a guide.
Then on the engineering side, look, there's all the code generation. Think of what engineers used to do, like, hey, I need to integrate this into my pipeline, to go with the FOSSA example, or at Kentik, I need to write a script to connect these two APIs. Engineers would spend a lot of time on that. With AI, you've been able to make that much more efficient and effective, and so increase output.
Absolutely. What I think about this scenario is that for an extremely technical product, CSMs won't exist. A forward deployed engineer will, and they'll need to build relationship skills. So engineers will have to elevate themselves to also handle relationships. On the very non-technical side, CSMs will probably take care of most things, because they're already excellent at building relationships, and they can handle the little technical bits that come up, because, as you mentioned, APIs, webhooks and playing around with automations are probably super easy now. Do you agree, or do you disagree, at least on the heavily technical part?
What I'd say is that the role of the CSM has shifted in some of these organizations, so you can carry a much larger load now. Even with a super technical product, there are still things you should track beyond what the forward deployed engineer does. You still want to understand their budget cycle. You still want to understand their business, the headwinds and the tailwinds and all of that. But any one CSM can now have a much bigger book of business, with maybe five FDEs to one CSM. Maybe that's the right ratio. It depends on the business, obviously. But a one-to-one ratio on key accounts is less important now that you have more leverage with AI.
I think that's the biggest thing. The job of a CSM has shifted, but the importance of the role is still very much true, because at the end of the day, champions buy from other people, and they renew with people, not necessarily with AI.
Absolutely. Super helpful. Since you moved on from FOSSA, you've been working with a lot of different founders as a fractional CCO. You probably have a lot of insight from working directly with founders of smaller and larger teams. Across all of that, what do founders miss most about customer success, that they really shouldn't miss in the first place?
Look, this is changing. My experience over the last year, if I look back at last October versus January versus the middle of this year, was constant evolution and constant shift. I think that's the meta takeaway. There's a lot of flux right now, and things are changing on a monthly cadence, sometimes faster.
The one thing people underestimate, or maybe the hubris I've heard from founders, is: we don't need customer success. Our product is so great, we're doing all the right things, we don't need people to help customers. That can be true for a very specific subset of companies and products. But the moats are gone. Somebody else can out-execute you tomorrow if they have a slightly better idea and a slightly better angle. The one thing that can still differentiate you is the relationships you build with your customers. I think people have largely underestimated the value of that. They think, if we just ship faster and do things faster, we'll stay on top.
That's a race to the bottom. It's similar to the old days, when people asked, what's your differentiator? We're cheaper. Well, somebody else can always drop their price to the point where they push you out of business. So you had to be differentiated on features and functionality. These days, I think you have to be differentiated on your relationships and how embedded you are with your customers. This is where the whole forward deployed engineering concept is really a differentiator. So I'd say that's been the biggest thing: founders saying, we don't need people, our product can do all of it. And now it's shifted, and people are realizing that maybe they do need to invest in some of these relationships again.
Very true. I'll give you an amazing story. I was speaking to an account management lead last week, and he said: you can check with anyone in my company about this customer, and they'll tell you it's probably going to churn, because they haven't been using the product. But two months ago I signed an expansion contract with them, and next year I'll do it again. I asked, what's the reason? He said, it's my relationship. There's nothing else. They only use the product for three months of the year, and they'll still keep paying me for the entire year, because I've been promising and delivering what they wanted every single year until now. That's very, very true. No one can take away relationships, at least in businesses where ACVs are on the higher side.
Yeah, I think that's exactly right. And the counterfactual is true as well. You can have a customer who is your top power user by every objective metric, but nobody ever talks to them. Then one day everything drops to zero and everybody asks, what the heck happened? It's because they were actively working to switch away from you, but nobody talked to them about it, so you had no insight into it. People aren't going to tell you that unless you already have some other relationship with them.
Manuel, now some fun before we close. I want you to tell me one best customer story and one worst customer story from your entire career so far.
One best customer story. Well, okay, I'll go back to the SevOne days, because that's where I had the longest history, and when you work with one customer for many years, you meet some people along the journey who are just outstanding. Comcast was a customer of mine at SevOne. That was one of the biggest deals the company signed, about two weeks after I joined. I ended up being the person who actually put their boxes together, brought them on site, deployed them, and then built relationships with the initial technical champions. That lasted five or six years. I think we went from an initial million-dollar deployment to tens of millions of dollars of product deployed there.
I still talk to the main technical person there, even though he's retired now. He used to live in New Jersey and moved to Tennessee. I still text with him every once in a while. We became almost close friends as a result of that relationship. That's both a business success story and a human success story. I really like that one.
The worst one. I won't name any names, because I don't think that's the right thing to do. But I've had the same company as a customer at three different businesses I was part of: Kentik, People Data Labs and FOSSA. That's sort of the full span. This particular company would tell you everything was great. They'd be super nice to you and invite you to all kinds of key conversations. I learned this the first time they were a customer. Then they would spring it on you out of nowhere: hey, we're churning half of the revenue.
What? You were talking about an expansion last week. And they'd say, yeah, but we've been secretly building this other thing, and we decided we don't need you for it. Okay. The first time you get that news, it's really not great, but we understood, and we actually ended up winning some of it back later. Then at People Data Labs they were a relatively small customer, and they did the same thing to us. So, okay, there's a pattern here. There's a set of people who will tell you nice things and smile to your face, and then do something else.
By the time I got to FOSSA, I thought, I've seen this movie before. On my first day, looking at the customer roster, I said, there's going to be churn here. People asked, what do you mean? They're talking to us all the time, they're super happy. And I said, I can guarantee you right now they're going to churn. And guess what? Six months later, the exact same thing happened. That was an interesting learning, and probably a situation I wouldn't want to repeat. But you learn.
That's sad. Can you tell me one contrarian opinion you hold about customer success, one that most CS leaders would probably disagree with, but that you keep believing anyway?
My contrarian opinion is that customer success is the real sales team. What do I mean by that? A lot of people think of customer success as, we need to deliver outcomes and create customer happiness, NPS scores and all these things. Those can be directionally interesting, and there are certainly metrics you should track. But at the end of the day, you have to be commercially minded. None of this matters if people don't renew and you don't grow accounts.
To me, some of the best customer success managers I've seen were salespeople who were burnt out from constantly pushing product and wanted to go deeper. That's not what a lot of leaders see. Historically, I think some of them are coming around to it now: all right, we need to be revenue-forward. And I'm saying, I've been saying this for the last 20 years. That's the whole point of these relationships: to create commercial value. So it was controversial at some point. Maybe it's less controversial now.
True. Absolutely. I remember one part of our earlier conversation, where we were discussing how products have evolved with AI. I said something and you laughed. The statement was: no one wants to write a 10 to 15 word prompt when they can get the same information in two clicks. A lot of people debate on the internet whether the future is UI-less, only chat, or a voice bot or something like that. What's your take?
Gosh. I recently joined a company called AIcelerate, which has a Gen Z kind of mindset when it comes to interfaces. I think it's almost generational. Younger people are very comfortable just asking the system a bunch of questions and getting fed information piecemeal, or big walls of text. But if you're more visual, you need to see the big picture first and then interrogate it. That's more my style, and I think that's largely still where businesses are.
So is the world going to go completely to chat? I don't think so. It's the same as the way you organize your computer. I know people who have no idea what a file system is or how to organize their files. All they do is use the search in Finder. But there's a benefit to having an organizational system and being able to find things that way too. So I think chat is going to keep rising, but I don't see it completely replacing systems with a UI and the capabilities they have.
Got it. And what's your prediction on jobs because of AI? It doesn't have to be about CS. In general, what do you think happens to jobs because of AI?
Look, things are moving so quickly that it's really difficult to make a definitive prediction. But here's what I'd say. None of the apocalyptic scenarios people have been putting out over the last two years has really come true. I think people will be able to do more with AI, and it will enhance their capabilities. I don't expect people to be replaced by AI, for the most part. Will there be some roles? Perhaps. But I see it on a daily basis: people write things with AI or put together reports, and you look at them and think, half of this stuff, who looked at it? Does it make sense? So I would expect roles and responsibilities to shift, but I don't expect a massive displacement.
Okay. I'm a bit on the other side. I honestly believe there will be a massive displacement, but it will displace current jobs, and new jobs will come up. That has happened every time. When the internet boom happened and when the SaaS boom happened, the earlier theses were that they would remove a lot of people, but they created new jobs for people to focus on. That's what I see this change bringing. A lot of current jobs will definitely be cut, is what I think.
That brings me to another question along the same lines. I'm not sure if you're aware of this debate. On one side, OpenAI and Anthropic are joining hands to keep AI at non-dangerous levels, building a committee that makes AI safe for people. On the other side, people like Michael Burry, who predicted the 2008 crash, point at them and say these are all fake, and that this is just a way for them to save on their AI compute spending so they can all make margins together. Which side are you on?
Well, Michael Burry has been predicting the next economic apocalypse for the last ten years. It's a different one every year. What's the saying? A broken clock is right twice a day. So maybe that's part of it. But I do think all this safety talk, these companies basically screaming, regulate me, is part of them trying to establish their moat. Once you're regulated, it's very clear what you're allowed and not allowed to do, and that lets you displace competitors.
I honestly think the real answer longer term is going to be sovereign AI models: LLMs that run locally on your own hardware and don't require cloud hosting, unless you're doing frontier work. Look, the vast majority of people using AI right now don't need the latest LLM. Opus 5.5 is good enough for 99% of the things you're probably going to do. So we'll get to a point where you can just run that locally, and I think open source will have a huge impact on the world there.
Great. Awesome. This part of the podcast is called the rapid fire. I'm going to ask you questions, usually with options, and you have to answer decisively with one of them. A lot of these have a mix of two answers, but if you were at gunpoint and could answer only one, what would it be? That's the whole exercise. On my side, I'm allowed to ask you why only once. Every other answer stays, what do we say, a mystery for everyone.
Okay. Sounds good. Let's do it.
The first one: health scores, signal or theatre?
Mostly theatre.
QBRs: keep or kill?
Kill.
CS reports into sales, product, or stands alone?
For most companies, standalone.
Is churn usually a product problem or a customer success problem?
It's usually a combination. So I'm going to be non-committal...
No, you have to answer one. You have to answer one.
Okay. From my personal experience, it's usually a product-market fit problem. So a product problem.
Got it. Should CSMs carry a quota, yes or no?
Yes.
Does the renewal conversation start in month one or month nine?
Month one.
Most overrated customer success metric?
NPS scores.
Most underrated customer success metric?
Time to first value.
NPS: useful or not? I think you've answered it already.
Here's what I'd say about NPS. The absolute number is completely useless. The direction is what matters. Is it getting better, staying the same or getting worse?
First thing you would cut when your team is bandwidth-crunched?
QBRs. If the company mandates them.
Thank you. Onboarding: owned by customer success or a separate team?
It depends on the size of the company. At small companies, I think it absolutely needs to be owned by CS. As you get bigger and more specialized, it's a separate team.
Which customer success task does AI take over first?
Reporting. Building customer dossiers, that sort of thing. Which it already has.
Yeah. You clearly have a very strong opinion on QBRs, and you want to kill them. So help me understand: if not QBRs, how would you deliver customer value?
Well, when people say QBRs, what does that mean? It's usually a long process to put together a deck that then gets talked at in the meeting. A CSM pulls it up and talks at the customer for half an hour about all the great stuff we've done, and then maybe there are ten minutes left for Q&A. Those are the QBRs I've always seen. Almost nobody asks for that. I've sat through these on the receiving side and thought, I got zero value from this.
I think a better way is to have a periodic sync on business value, and just to talk to your champion on an ongoing basis. If your champion is willing to talk to you monthly: hey, this is what we delivered last month, this is where we see things going. Make it more informal. Then if they say, I really think we should have this executive-level conversation, and I want to invite you to it, great. That's a QBR I want to have. That's an actual QBR that makes sense. But if you're just doing QBRs to check a box, hey, we delivered this QBR, there's no value for the customer, who might in fact get pissed off, nor for you, because all you're doing is talking at them.
One practice we follow internally: rather than believing in QBRs, we share every small win with their teammates in the Slack channel we share with them. Then whenever we have exec-level discussions, all we have to do is pull all those conversations into a single page and share it with them: this is everything we achieved together, and this is the broader picture, with numbers.
Yeah, I think that's a much more effective way of doing things. But some companies insist on delivering QBRs, come hell or high water.
Yeah. Their intentions behind it are always good, but the way the team perceives it, it becomes a checklist item, and that destroys the purpose of having it at all.
Yes, that's right. That's right.
Perfect. We're at the final point of this conversation, Manuel. As I told you earlier, if I have to summarize, you've gone from calling people for satisfaction surveys to leading customer success teams at very large companies. And you've been part of the entire technology evolution at the right time. You were part of hardware tech, then on-prem solutions, then at the junction of SaaS-native companies. When SaaS and cloud became evident, data became very important, and you were at People Data Labs. When data became so publicly available, security became a bigger concern, and you were at a compliance business. And now you're working in AI. So you've been part of all the right businesses at the right time, while growing to a very senior stage in your career. What would you advise someone figuring out their career today, inside or outside CS, so they could have a journey like yours?
Oof. That's a really tough question. The number one piece of advice somebody gave me early on, which I'd pass on, is to find areas of unique value for yourself. Where can you add value? Whether it's a particular skill you have or are looking to develop, or a particular insight. That's getting harder, because it's much easier to just know things these days and develop insights. But lean into your uniqueness. It could be energy. One of the things that convinced me to join AIcelerate is the level of energy one of our founders has. It's just phenomenal. I thought, okay, that is a clear differentiator that not a lot of people have. So lean into those unique differentiators, build from there, and find people along the way to support you.
This is an open invitation to anybody: I'm quite happy to meet with people one-on-one, answer questions and help them in their careers. I'm a big believer in that. I was the fortunate recipient of some coaching early in my career. I would have loved more, and maybe more formal coaching, but that is an open offer. I'm happy to help people along their journey.
Thank you so much for your time, Manuel. It was wonderful speaking to you, and thank you for sharing all these insights today.
Thank you for having me, Dhiraj. This was great. I appreciate it.
The Second Year is a podcast by RetainSure.
All episodesWe use first-party analytics to see which pages are useful, and advertising tools to measure our ads. You choose what we may use. How we use cookies
Your browser sends a Global Privacy Control signal, so advertising is switched off by default.
