Guest: Manuel Harnisch – Delivering Customer Success For Technical Products

[00:00:00] Jason Whitehead: Hi everyone, and thanks for joining us for another episodes of the Jason’s Take. We’re here talking about bold customer success and have a lot of great conversations around that. I am joined today by my co-host, Jason Noble, based over in London.

Say hello, Jason.

[00:00:13] Jason Noble: Hello, Jason. Hi there. Everyone. Really excited to be here for another episode and another great.

[00:00:19] Jason Whitehead: Absolutely. And today we’re very excited to have Manuel Harness here joining us today. So welcome Manuel. Little bit of background. Manuel has grown and led several CS teams frequently at companies that have very technical products built for technical users.

And he’s really had an expense extensive experience in this area and we’re excited to have him here because, Many SaaS companies that we talk with, their technical staffs are in their product team and, building for the B2B space, they’re often building functionality that’s intended for non-technical users, such as front office staff and sales folks and all that great stuff.

But we don’t often talk about what it takes to make customers with very technical products successful and what that means for customer success phones. So we’re gonna change that today by looking at how to do customer success when you have a very technical product with a very technical. Manuel, thanks for being here today and say hello, and please just give everyone a quick overview of your professional background, your career, and any experience you’ve had, building and leading cs.

[00:01:16] Manuel Harnisch: Yeah. Great. Thank you. And hello, Jason and Jason. I call this the Jason Square podcast. So this is very exciting. Very happy to be here. And yeah, so my background is I’ve been in the in the tech space for the better part of 20 years now. Most recently built and led a CS function at a company called People Data Labs.

Prior to that built one and LED one at Kenk and spent about nine years at seven one. And this is the old cell days when you still had on-prem appliances and you would ship know, put software on and ship that out and then get installed And, Back then we called what we do now post sales and support, right?

These days it’s all about success because it’s all about recurring revenue. Yeah, that’s a little bit about my career and what I’ve been doing, and so far so good. I’m still enjoying it and hoping to do it a couple more decades here. But but yeah. Fantastic.

[00:02:01] Jason Whitehead: Thank you for joining us.

So let’s just jump right in. Since so many of the products that you’ve worked with and teams you’ve built, it really has been extremely technical products with technical experts as your users. How would you compare that to building CS for more of a front office type product or more business type users that have less technical expertise?

How do you approach it differently and what are some of the big

challenge?

[00:02:21] Manuel Harnisch: Yeah, so I, I think the interesting thing and really the differentiator is you have a lot more skeptics when it comes to technical products that you have to overcome. Every company I’ve been a part of over the last decade or so, has always sold to engineers, whether they were network engineers or they were developers like would doing now at f.

And, having those types of personalities means that you have to overcome a much larger barrier with regards to technical expertise, technical trust, and really getting those folks on board. A lot of times the buyers are not really the people that will end up using or implementing either, right?

So that, that’s another sort of dichotomy and really it starts with, having people on your team as the vendor that can speak at the customers level at the engineers level, and they can build that report. Rather than just just being, say a customer success manager that sort of models through, runs the meetings but doesn’t really get deep.

And so it’s all about building that that, that trust, that relationship, and then being able to deliver value in a continuous basis. A lot of times CS teams nowadays they focus on the QPRs, they focus on the presentations, and I think those are still valuable and those can still be important.

But if you have a very technical product, you gotta make sure that you can. Delivered a technical value first and foremost before you go to the, to qbr.

[00:03:34] Jason Noble: With, and you’ve got technical teams. How do you get that customer success mentality and way of thinking on them? Cause quite often it’s not something that’s very natural to a developer.

It’s not the background they’ve got, when they’re an engineer, it’s a very different mindset. How do you go about educating and training them and helping them get aligned with what customer success really is and what we need to be.

[00:03:55] Manuel Harnisch: Yeah, that’s a great question and I think the, as with anything in life, the answer is it depends on the situation, but you end up having to be less direct in some ways with folks like that because we come in and say Hey, you have to do it this way and that’s because we say it’s going to be that way.

You’re probably going to run into a brick wall relatively quickly. Engineers don’t like to be told what to do from the get go. They, you have to earn their trust and you have to earn that relationship. And so one of the things we were really successful at doing this at Ken Tech, Was to bring in folks that had done the job of the customer in the past, right?

Like they were peer coordinators. They ran large scale networks and so forth. And so they could immediately, get get a base level of trust established because they spoke the same language, right? Like they, they understood the acronyms the short text and so forth. And they, they could get that established like right away.

And then from there, it was just a matter of Hey, I actually know what your job looks like. I’ve done your job. Let me show you some of the things that have worked for me in the past. And also let me help avoid some of the mistakes that I made. Because that’s one of the things engineers don’t like to necessarily.

Learn all the lessons the hard way. Some of ’em do, but for the most part, they’re open to, if somebody comes in with a base level of understanding and they’ve done the job before they’re willing to listen a lot more closely in, in that scenario. So those are some tactics and some strategies that I think are working really well.

[00:05:15] Jason Noble: Have you found it? Is it, does it take time? Have you found it quite quick to do that? Or is it something that, that takes a long time to do and it’s very degrees of success?

[00:05:23] Manuel Harnisch: I think it depends on, again, it depends on the personalities that are gonna be involved early on. I actually think that a lot of times you can set yourself up for success in that regards early on by involving the people that will ultimately work with you post-sales in the final closing stages.

And that’s something that we’ll be doing a lot more here at fasa as I get up to speed and build up the team in a function. For fasa, the buyers are usually the legal departments and like the procurement procurement is always involved, but legal tends to be the buyer, the economic buyer.

But engineering tends to be the ones that ultimately have to implement it, right? Like software engineers have to deploy the product and get value from it. Legal buyers it for compliance reasons and do a cya, right? And so involving those engineers in the final closing stages, It’s a lot more, it will have a lot better outcomes down the line because that way they won’t feel like this is something that’s being crammed down their throats.

They’re not seeing it after the fact. They’re involved in the final decision making process. That is that is definitely a better approach than just surprising people.

[00:06:22] Jason Whitehead: I’m curious, since you, you’ve brought that up, having so many non-technical buyers involved and who make that buying in renewal decision in there, how do you approach things differently when, or do you, when you have a very technical product, so you’ve gotta be able to create technical value, but prove business value and have those mixed discussions.

What’s, what have been some of the challenges around that? What are some things you find that work really.

[00:06:42] Manuel Harnisch: The reality is I’m just getting started here at Foster, so I don’t actually know exactly what that will look like just yet, but I have some hunches, right? Because looking back at PDL and also at kenk a lot of times the economic justification did have to happen more so with the finance departments, right?

It wasn’t so much legal there but they had to show proofs. Now the The space was a little different because at Ken Tech, at least, we could always say if you don’t monitor your environment, you don’t know what’s going on, you might be missing a lot of things that you know are either bad or that could be improved, or, Hey, we’re really doing well over here, and us being able to show value that way.

So the ROI was always like, Hey, this is a, this is like a CYA to some extent, but also here’s a way to identify future opportunities and maybe some cost cutting measures or expansion into new markets. What I think is gonna be really interesting here at fasa we, we have obviously compliance piece.

So what we do is you install this into U C I C D and your development pipeline, we will then scan your code base and make sure that, you’re complying from a license perspective against all open source licenses that you might use. And every software companies, there’s whether they know it or not, is using some sort of open source, right?

So that’s the first part. But then the second part and this is becoming more and more prevalent, is around security, right? A lot of these open source projects have zero, 80 vulnerabilities all the time. Unless you subscribe to every single one of ’em on, on GitHub or respective websites, you’re not gonna know about that.

And so the value there is that proactive notification to both the engineers, right? So they can actually take mitigating steps. Earlier on, but also to legal and compliance so they know what might be coming down the line, right? Hey, is this possibly a giant leak potential for us? And so do we need to start, PR early?

Do we need to have communications out? Because a lot of this is now also a matter of just government reporting, right? More and more if is happening in that space. It is going to be an interesting challenge, right? But I think this product at least speaks to both the engineers because it makes their job easier and it gives them peace of mind, but also to legal and compliance, who is ultimately the economic buyer.

From a, from an insurance perspective when

[00:08:41] Jason Noble: you’re building up a, an organization in CS than in, in a more technical organization, how do you, what kind of people do you look for? Are they very experienced? Are they earlier in their career? And then how do. And this is always a challenge, but how do you find the right mix of technical business and customer focused skills?

Cause that, you said earlier in the intro, there’s ways of doing it, but it’s challenging to do to get that right balance. And when you’ve got someone who’s naturally more technical, it makes it more challenging. But really interested in kind of a couple questions there for you.

[00:09:13] Manuel Harnisch: Yeah. And my thinking on this has evolved over the last five to 10 years.

I, it used to be much more common to try and find sort of one person that could do all of these things and then just scale that one person to a sizeable team. We did this a little bit of can and also people data labs in the past and you end up with sort of CSMs that are also more technical to some extent.

But then you also still had to have. Yeah, what we would call customer success engineers that were like purely technical, but could also talk to customers to some extent. And they would work in tandem. So as CSM and the CSE would work with their given account base and ensure that they’re delivering value there.

I think. It’s become increasingly more difficult to try and find customer success engineers that are also really polished and able to talk to customers. And they’re also becoming a lot more expensive, which I think, it’s just the way that the market’s going. And then on the CSM side, know, finding folks that are both like able to map the account, have those relationships and so forth, but, and also be able to sell to some extent and negoti.

Negotiate renewals and find upsell opportunities and actually be able to run a call and hold their own in certain minimally technical situations is tough. And so I what I’m thinking. Might be the future here is to specialize more early on. A lot of companies do this at scale they’ll have like CSMs that are purely non-technical and they are the account manager.

And then they’ll have, implementation engineers and they only work on the implementation side. And they may have a project manager that maybe working only during certain parts of the customer life cycle. And then of course they’ll have a renewal specialist or an upsell cross-sale specialist that comes in when those situations open up.

And so that’s usually something you can do at scale. But I’m thinking about of doing this earlier on, especially in this kind of company where, the engineers tend to be developers. Like they’ve written code. They live in GitHub. They understand. You may only need one or two of those, right?

For a given startup to cover your entire customer base until you have several hundred customers. And then have one or two really strong CSMs to be the account managers and maybe one renewal specialist upsell specialist. That kind of helps out. That’s the thinking I have. As, as you think about all of that though, in a earlier stage startup, it’s hard to hire people that have no experience.

Especially on the engineering side. You have to have a base level understanding of what’s going on. And you can start making some bets and Bringing on some more junior folks as you have established a team. But making making a complete blind bed early on and just hoping might set you back too far.

So for now we’ll focus on people that have done this before and then have, couple years experience. But as we get bigger, they’ll be promotion paths and, even bringing in folks that have customer success. I

[00:11:54] Jason Noble: like that, and I think that really makes logical sense. As you start, you’ve gotta get those right people in.

If you, how do you go about if you can’t find the right skills in the team and experiences that you want, particularly when you’re early stage startup, how do you go about building those skills and developing those skills and which, who do you see as the most important first

[00:12:13] Manuel Harnisch: hires?

Yeah. So I think what’s good about customer success is there is a fairly established community at this point, especially on the CSM side, right? Anybody that’s more on the account management side of things. There’s resources out there. There’s Success Hacker, there’s, the various CS platforms that gain, that has a really good program.

Catalyst has a customer success coaching program. And so forth where you can both do some recruiting right? For folks that are early in their career, but also help existing folks that you may have on the team that, may have inherited did to get some coaching and some additional resources.

From the outside on the engineering side I think. This might be controversial, but I am, I’m a big believer in, in, in hiring some folks from your customers, right? If you find a superfan or two, like that’s on the engineering side in some of your customers, and it’s not going to be a detriment to that customer’s business, try to recruit them over because they already love your product, most likely, otherwise, they probably wouldn’t be talking to you about that. And they might be willing to take that risk to come to a smaller startup and really accelerate things. We were very successful. At doing that at Ken Take two, folks actually came over from existing customers and they’re still there.

They’re still some of the best engineers that are that I ever hired over there. Shouted to Dan Kelly and Dustin Bayer who are the ones that did that? And so that’s another that’s another avenue of approach that you can take. Cool.

[00:13:36] Jason Whitehead: I’m curious talking to you as well too, so if you’ve had very technical customers with engineering backgrounds and skills and all of that knowledge What is it that they actually want from a CS team?

Where does it, they need help and that they can’t do for themselves. And other than technical support, what is it, Are they looking for subject matter expertise in the field? Are they looking for additional technical expertise in customer success? Are they looking just air cover with their internal business users?

What sort of,

[00:13:58] Manuel Harnisch: what’s the goal? Yeah. So again, I think it depends on the product. What I do know at fasa a lot of our time will be spent early on in the implementation onboarding cycle. Because unless you implement and are in the C I C D in the development pipeline there’s no way for the product to work, right?

And there’s a number of things that just have to happen and have to be configured that have to be set up and that, have to happen both on our end, on a, and on the customers and in order for that to to be true. And a lot of that happens early on, but then, Later on it’s about just making sure those things continue to work over time at at Chemex, similarly we had that as well where, that product, you would send data from your devices and then it would do a bunch of analysis and and you would be able to use it in EY and APIs and so forth.

But in order to get that set up, you had to configure, protocols on your routers and switches. In order to export that data. Some customers knew exactly what to do. And those were the easy ones, but the vast majority of them required some sort of handholding, right? Every router and switch has a slightly different self version to commands might be slightly different.

Having the expertise to know that difference and being able to help customers along that. And then also, and this is, it sounds silly, but a lot of times you have to overcome some compliance concerns on the customer. What do you mean? You’re gonna send metadata about all of our network traffic out to some cloud provider, right?

Is that safe? Can you help me understand that? And that’s actually a challenge. We’ll be seen here at Fossa more and more so as well, because now everybody uses GitHub and GID lab in the cloud to do the development. Some people have that on-prem, right? So there’s a unique set of challenges to come with that.

Once you’ve passed the onboarding piece though, it’s all about showing customers, Hey, this is the business value that we actually found. Like you have so many vulnerabilities that we’ve identified. You are out of compliance for, these software licenses. Here is our recommendation as a vendor who’s done this, hundreds of times with other customers on how to remediate them.

And so that’s truly where, the power of customer success will come. And that’s more down the line because you’ve gotta get through the onboarding piece. But that’s when you become truly an consultant and an advisor to your customers. Very

[00:16:07] Jason Whitehead: cool. Very cool. So I’m also wondering then in such a technical environment, you mentioned sometimes they’re doing implementation work, sometimes they’re, IT changes after the implementation’s live.

How do you draw a distinction between customer success and customer service and support type piece and where do you draw those lines? And even just internally how do you need to manage your teams and workload

[00:16:24] Manuel Harnisch: differe? Yeah so interestingly again, it depends, right? At Kenk it was when I was still there, it was all under my umbrella.

We had support, we had one person that ran a reactive break, fix inbound ticket queue, and then everybody else was more proactive. Similarly at People Data labs we shared the support queue. Between myself and my technical services manager, and there wasn’t a lot of support cases that came in and everything else was more on the proactive side.

Here at fasa, we have a separate support team right now that actually reports in under the product leadership. That may be the way that we keep that down the line. It may eventually move under me. I don’t know what that will look like yet. But ultimately, It is distinctive workflows, but it tends to be the same value space, right?

And me as a customer, like I have an issue right now I want to have that resolved. What’s the most natural thing to do is I’m gonna reach out to my customer success manager. You as a company may not want that. They may want them to. Goes through a certain process, but ultimately you’re trying to make that as easy as possible for your customer.

I think the differentiator though is is it proactive? Are we helping a customer achieve a certain outcome? Then it’s customer success. Is it reactive as in Hey, I found this issue. I’m gonna tell you about that, and I expect a resolution that’s more service or support. But at the end of the day, you really are there to help the customer resolve their concerns and to get value from what you’re providing.

[00:17:46] Jason Whitehead: Absolutely. Absolutely. Also as I’m listening to, I’m wondering, in the more technical companies where everyone has to have some technical chops behind them there as well too, how do you work with your internal leadership and executives to communicate the value of CS internally?

Do they instinctively get it? Or do they, is this a big sell for them? Cause I know like in a lot of, front office facing applications, there’s obvious. A lot of folks who don’t have the technical skills and interest, but have a lot of business acumen, and sometimes in more technical companies you get some of the leadership who are very tech forward.

[00:18:18] Manuel Harnisch: Yeah. Yeah, so that’s an interesting one I always look at when I evaluate companies like, what did, like how did the CEO or like one of the co-founders of grow up in terms of like their career journey. We were super fortunate at Ken Tech with a Friedman who had been the CT of Akamai for, the better part of a decade.

Had run, other internet service providers and built the first ISP in Philadelphia. He’s a nerds nerd, as we used to say. And so like he got it. And he was a big proponent of making sure that, customers get technical value and. It was never really a question.

PDL is, was a little bit different. The the idea that was like, Hey, we don’t actually know what will work yet. We’ll just build a bunch of products and see which ones work for our customers. And guess what? This data product ended up being the one that took off. And both of the both of the co-founders, they were more the tech, sorry, wanted a business side of things.

And it, it became a little bit more of a challenge, but we were able to, bring in a lot of other. That were early on in the company to be champions of of the technical side of things. our ceo, and it’s actually a solo founder company, which is unusual, but also a nice challenge to see is more on a technical side.

So he understands like he understands the problem space of open source. The compliance and security aspects from a technical side. So I think we’ll have a lot less concerns around the technical value there. I think where challenge will lie is the the account management aspect of that and really making sure that we’re not just focusing on the technical things because I think we’re doing that reasonably well.

But also making sure that we don’t lose champions. We understand that the customer’s business the macroeconomic impact of what might be happening, the overall shift in, say the economy, for instance, every company these days is the tech company to some extent, right?

If you’re a car manufacturer, like it may not be your parent, but guess what more and more car software also relies on open stores, right? And having that where all that understanding I think is critical when it comes to taking care of a customer as a whole, where it just, the technical pieces.

[00:20:12] Jason Whitehead: Cool.

[00:20:13] Jason Noble: Great. Thank you. Do you find what’s the responses of your customers and the feedback from your customers are is it working? Is the model working when you’re speaking, having these technical conversations? Does the model of customer success in a technical organization work?

[00:20:26] Manuel Harnisch: So in, in perfect fairness, I am literally just starting here at fsa, so I don’t have the answers to that yet. I think, going back to both people, data labs and Kenk, I would say a lot of times the yes it does work because. Yeah we would make sure that the technical value as well as the business value that somebody had signed up for was being delivered.

I might now be missing part of the question, so I’m lost my own thoughts here, but does that answer it? It

[00:20:55] Jason Noble: does, yeah. I’m just curious cuz. The majority of customer success is probably on, on the more non-technical side, and I think it’s quite easy to equate success for customers there but the outcomes and value that we’re doing from a technical point of view can be very different.

I’m just curious into how you’ve seen the success of customer success in more technical organizations.

[00:21:16] Manuel Harnisch: Got it. I think it all so there’s always a business outcome that somebody wants when they buy your software. Or they buy your product. And a lot of times yes, it can be just like a front end thing and that’s fine.

And it’s, it can be relatively easy to explain that. And in those cases, like you can just get away with just having a CSM run the whole thing. Where it’s different is if what you’re providing, like in order to get the business value from it, you have to have a certain level of technical implementation happen or it may even be very complex, right?

Like going back to the people data labs for a second there was like, there wasn’t a ui, like the UI was very limited. It just told you how many API policy made and what your API keys were and maybe some other stats, right? Everything else that we did was in the data, right? So you would either do API calls, which would give you the value, and you had to implement them into your product in order to.

Look up people or extract other information, or we would deliver it as a giant flat file into some cloud storage. And then you as a customer would have to download that into your data pipeline and and implement it, right? And so that itself is a very technical task, right?

Because you have to make sure that you’re paring in a certain way, like you’re cleaning the data a certain way, you’re storing it a certain way and so forth. And In order to ultimately get to the business outcome, which may be like, Hey, I want to build this app and I want the to do these things and I need this data for that, you had to do all the technical steps.

And so in, in cases like that of course you have to make sure that it works. Technology wise, it’s interesting. The customers that would fail at at that company were the ones that were trying to outsource all the technical development, right? They’re like, Hey we’re buying this. We understand it’s a technical product, but we’re gonna outsource all of the technical work to some third party developer.

And nine chances outta 10 is, that wouldn’t work because those people were not bought in into the mission of that customer the same way as, say, founders who are. And so I think that’s like the proof that, you have to overcome those technical implementation challenges.

[00:23:11] Jason Whitehead: Wow. That’s interesting stuff. No. Thank you so much for being with us. We’re just about out of time here. I really appreciate you sharing your experiences and insights. Before we go, we always like to ask a bold challenge question, and this one for you is, what’s the single most important action that a leader of a technical CS team should take to ensure that their team is delivering a high impact CS service?

So if you’re leading a technical team as the leader, what’s the most important thing for you?

[00:23:37] Manuel Harnisch: I think you need to be, you don’t need to be the smartest person in the room, but you need to be able to understand what your technical folks are talking about and you need to be able to challenge them on some of their assumptions and thinking.

So I like to think of it this way. Just know enough to be dangerous, but don’t be the smartest guy in the room. .

[00:23:55] Jason Whitehead: I like it. That’s great. Great advice. Before, before we go, we wanna invite you as all of our guests, if you would like to share a shameless plug for your projects yourself, your background, anything of interest, any outside activities that you’re really interested in.

Please just go ahead and tell our audience what’s of interest to you and how they can get in touch with you if they have questions.

[00:24:13] Manuel Harnisch: Yeah, Sounds good. The get in touch part is easy. I’m on LinkedIn, so you can just hook me up the manual harnish and send me a message there, or M Harnish at top.

Surf that info. That’s another quick way to get ahold of me. In terms of shameless blog, I am super excited to be starting here at fasa. And so like this is gonna be all about fa. If you use any sort of open source software in your development pipeline if you are, building big projects if you’re going through digital transformation, you should seriously take a look at what we can provide not only from a security perspective, but also from a compliance perspective.

Relatively easy to get started, get implemented, and then, to the right value from. From the products that down the line, it, the way I try to explain this to people that aren’t in the industry is like, it’s like buying insurance, right? Like you, you buy life insurance with the hopes that you’ll never need it.

But guess what? If you do need it it’s there. So think of it from that point of view. And that’s just for the compliance piece. The security piece is obviously a lot more day to day. So yeah, that’s the shameless plug. Fantastic.

[00:25:11] Jason Noble: Such the, that, the background there, talking through kind of the technical side of it matter is just great cuz.

I, I think platforms and products are getting more technical, particularly when you look at big enterprise solutions, big organizations and you need to understand how we get that break and what’s the right thing to do. And those examples you’ve talked through I think are really useful and quite different from a lot of how a lot of us deal with customer success.

So really insightful conversation.

[00:25:37] Jason Whitehead: Yeah. Thank you so much for being here. Really appreciate

[00:25:39] Manuel Harnisch: it.