In The Trenches: Interview with Steve Lau & Rameez Ansari

5:08PM Aug 23, 2022

Speakers:

Steve Divitkos

Steve Lau

Rameez Ansari

Keywords:

product

business

saas

customers

steve

transition

built

market

premise

people

pricing

sales team

felt

piece

selling

feature

price

question

point

sales

Steve and Rameez, welcome to the show.

Thanks for having us.

Thank you, it's great to be on.

Yeah, it's great to have you. Maybe to start out, I'll mention that one of the reasons why I was excited about having you guys on today is that the two blog posts that I wrote, specific to the topic of transitioning a software company from on premise to SaaS, both technology and pricing, are among the two most read blog posts that I've published. So clearly, we've hit a nerve within the community somewhere. So I want to take the next hour or so to really double click on what you guys did that made your journey so successful. But before we do that, let's set the table a little bit. And maybe if you guys could give us a brief bit of background on yourselves. What brought you here today, and maybe somewhere within your background, you can touch a little bit more specifically on how you found yourself within the on premise to SaaS transition?

Yeah, sounds good. Why don't I take a first stab at that reason you can jump in. Early career for me, was sort of the typical finance background. So I started my career in investment banking, and then quickly transitioned into private equity, where I actually had the benefit of being cubicle mates with Steve Divitkos for a good year two. Ramees's, his early background, I think he grew up in his family business, effectively diesel power generator, Assembly Business and really learned the ins and outs of working in an SMB type organization from a pretty young age. From there, he went to BCG. And then both of us decided to transition our careers into doing our MBAs at the same time. And so I spent a couple years at Wharton and Remeez spent a couple years at Stanford.

And neither of us wanted to go back to to Blue Chip private equity or consulting. We really did not, equally passionate, dislike for for going back to those backgrounds, nothing against private equity or consulting.

But we definitely dedicated those two years to try to figure out what we could do that was entrepreneurial, ultimately landed on the search fund model is one that ticked a lot of boxes for us, and was sort of the path that made the most sense. And so we raised the traditional search fund ended up searching for about a year and a half or so, and ultimately acquired a small on premise software business based in Fort Myers, Florida. The business was called Desco, which we later rebranded to Field Edge. But what Desco did was effectively workflow software for small HVAC, electrical and plumbing companies. So it did everything from dispatching technicians, to invoicing and quoting and actually did a bit of the accounting as well, too. So pretty comprehensive. But from there, how we think about the journey, it was really like creating a startup within the resorts, that of an old school company.

Because we knew that we needed to transition the business from on premise to SaaS, and we can talk about the reasons why throughout this podcast, but we were really all in on that transition. So over the first six months of acquiring the business, despite the sage advice that a lot of our investors gave us in terms of not doing anything in the first six months, he actually dove headfirst into a SaaS transition, launched a product six months later and effectively transformed the business over the next three years leading up to an exit three years post acquisition.

Yeah, it's so interesting to hear how quickly you dove into that transition. Because, as you correctly point out, the generally accepted wisdom is to take six to 12 months to kind of do no harm until you start making major changes. But we will get into that. And Steve, you mentioned the catalyst for making that change. Maybe again, in the context of table setting. Maybe for those who are listening who might not necessarily be terribly familiar with this, let's take a step back. Can you guys please explain what is the difference between on premise and SaaS software? And why is SaaS generally preferable to on prem? And why did you decide to make that replatforming decision when you did?

Yeah, no happy to do that Steven. So on premise or client server technology, these terms are often used interchangeably. Or what it refers to is each end customer running on a specific and unique instance of the product or, or software. And this is quite different from SaaS. SaaS generally refers to end customers running on a single source of code. And multiple end customers all run on that same version of the software, which is typically hosted on the cloud, right. And so a lot of people call this single source, multi tenant. And then the last piece, I think that's worth mentioning here is that the pricing model, the subscription pricing model, is also something that's become quite germane to the world of SaaS, you can read theoretically,you can price an on premise product in a subscription manner as well. But it's harder to do for various reasons.

And so subscription pricing has also become kind of synonymous with SaaS. Now, in our case, as Steve was mentioning it's interesting, right? So we came in, and we inherited this, we inherited this on premise product, and the on prem product had been built, call it, you know, we bought the business in, and Steve, correct me if I'm wrong, I think, early 2015, close in late 2014. And so the on premise product had been around for about a decade plus, and the legacy code had become, you know what people would, in slang, they would say it had become like spaghetti. And basically, what that meant was the legacy code that we inherited, as part of the the on premise product was just incredibly messy, and complex and cumbersome to work with. And so what that meant was to do any updates, let's say we wanted to respond to customer feedback, or launch a new feature, it would literally take, it wouldn't take 10 or 20% longer.

It would take 10 or 20 times the amount of time relative to if they were working on a clean, new architected product on a modern technology stack. And so, you know, we were kind of faced with a situation where we walked into the business, and we had to make this decision, do we clean up the code, which people used to use the term. And it's worth mentioning, neither Steven nor I, you know, we're technologists or our technologists, right. And so not only were we relatively new at the CEO game, but we were completely brand new at the on premise SaaS game. And so we weren't, we were certainly making a bunch of mistakes along the way, as we were figuring this out.

To add an example of how non tech savvy we were, and I won't name names or who it was, but one of us did not know that hashtags do not have spaces in them. Between the words and that's, that's sort of tech newbies, we were.

You guys have no idea how long it took me to explain that to Steve Lau. But, and so we were, and so the situation was, you know, do we refactor the code, which basically means like, clean up the code and organize the legacy code so that you can work with it in business speak? Do we refactor the code and make it more usable, so that, you know we can kind of reduce this 10 to 20x time it takes to do updates, and, you know, still takes us quite a long time but less cumbersome? Or do we just build a net new product? And then the other issue we were facing was that everybody was running on a different instance of the Legacy product, there were literally 16 different instances of the product. And so every time a new feature would get launched, it had to be built in a way that it was backward compatible.

And then all the support techs would have to be trained on 16 Different versions on the platform. So you can imagine the the complexity and so to us, it became quite apparent. I mean, our industry was a high growth industry. And so it became quite apparent really quickly, I think it was a no brainer. For us, it was pretty stark, I think in other instances, there's more nuance. But in our situation, it was just immediately clear to us that if we wanted this company to have a future, in the midst of a high growth industry, an intensely competitive industry, we absolutely needed to build a net new product and a modern technology stack. And one that was SaaS and multi tenant. And that's what we set out to do.

Very interesting. You essentially, you declared bankruptcy on the old code base. And we're gonna get into specifically how you did that. But before we get into the details of the transition, I want to ask one more question about the why. And more specifically, I want to kind of speak to CEOs listening to this who are contemplating making a similar transition. So are there any circumstances under which you would not recommend making a transition to SaaS? Said another way, are there any situations where it might be best to simply leave the on prem software as is? How would you advise As a CEO who was wrestling with a similar question?

I think look, the the on prem to SaaS transition is is a far from trivial transition. And then particularly for, you know, the typical search fund CEO, who's as I mentioned earlier, like first time CEO gig for me and Steve and you don't want to change change a ton in the business. So I think the degree of difficulty in the context of many business decisions that you got to make along the way, the degree of difficulty of the on prem to SaaS transition is kind of like a nine on 10. Pretty darn hard. And so I think that's the first piece, I would say, on this point on this one. And then the second one is that in our case, the decision was pretty obvious, because high growth industry, you know, competitor running really fast on a beautiful modern product themselves. So we were just going to let get left behind in the dust. But let's say you're in a low growth industry, with less competitive attention.

In that situation, you might be able to get away with changing the pricing model, or figuring out a way where you provide a hosted version of an on premise product, or rewrite the front end, but take more of a bite sized approach. I think the other instance would be if you work in a in a highly regulated industry, or an industry where the specific customer context. So examples of that are there specific kind of areas in GovTech, or in FinTech, where the data needs to be stored in a way that, that it's on prem and, you know, kind of privately secured. So those would be the examples. But in almost all other instances, I think that if you want to be aspirational about the narrative of your business, in an industry, that's a high growth and competitive industry, I feel like your hand does get a little bit forced at making this transition. And it's not an easy transition to make. So you've got to go in with your eyes wide open.

Yeah, one thing to add to that, though, is sort of in this may be common knowledge, but the multiple arbitrage that you can achieve is quite meaningful, right. And just to use one data point, in our case, you know, we acquired our business for roughly five times EBITDA. But we ended up exiting for north of eight times revenue. And so that multiple arbitrage created a tremendous amount of enterprise value for us. And I think that's been a SaaS transition.

And I think you'll get that multiple arbitrage that arbitrage are so important, Steve's talking about, but I think you get it, as we realized, for a couple of different reasons, right? You get it because you turn the on prem revenue into subscription revenue. And so now you have this. And so there's, you know, as the same goes, right, like $1 of one time revenue is equal to four or five times are the other way around, I guess. Right? So $1 of on prem revenue is equal to five times recurring revenue. And so you'll get it because you change the pricing model to subscription. But the other reason you get it is because you change the fundamental narrative of the business. And now you have a competitive technology stack that can be easily updated and easily maintained. And you've got your customers running on that single source of code to separate two very separate reasons that lead that combined to this multiple arbitrage.

Yeah, that's really important. I think when people talk about the on prem to SaaS transition, they kind of conflate a few things. They talk about SaaS revenue, but really what they're talking about is subscription revenue. And what they don't realize is remains to your point, you can price on premise software on a subscription basis. And that takes you some of the way there. But I would argue that it takes you less than halfway there. To your point, the reason why you got the multiple arbitrage is not just because your revenue was more recurring in nature, which it certainly was. But the economics of running a SaaS business are far more attractive than the economics of running an on premise business. As you correctly point out, let's say you add one new feature while in an on premise business.

In order to benefit from that new feature, all of your customers need to upgrade to the newest version. And most of those customers probably won't want to upgrade because maybe they don't want that feature. Or maybe the upgrade is too long and too expensive. Whereas as any Salesforce or Dropbox or HubSpot user can tell you, you know, you log on the next morning and you just happily enjoy the new feature, you can see how the economics change so meaningfully from the perspective of the software vendor.

That's exactly right.

Okay, so at the beginning stages of your transition, you present I mean, you had hundreds of customers on what I'll call the old product, which was funding 100% of your revenue. And you had zero customers on what I'll call the new product, which was funding 0% of your revenue. So with that dynamic in mind, how did you guys think about how much to invest in your old product versus how much to invest in your new product and maybe you could speak to any challenges that might have presented themselves as a result of whatever decision you made.

Yeah, you know, for us, a lot of this was our decision in terms of how much to invest in the old versus new, a lot of it was informed by sort of context around our specific market in our company. So for us, as we mentioned earlier on, we were up against a really fast growing SaaS competitor that had raised a boatload of venture capital. And so we needed to get to market really fast on our SaaS product. And the other piece of context that allowed us to go really all in on the new product, and I would say, if I had to approximate, you know, I would say 95% of our dev work, or more was on the new product, and the balance on the old product. And what allowed us to do that, partially was also the retention rates, right, we had very strong retention rates on the old on premise products, something like, you know, low 90%, gross dollar retention figures and sort of call it 115 ish percent net dollar retention figures. And they weren't moving very much at all, they're quite steady for a number of years.

And so we believe that the customers on our old product weren't really going to go anywhere. And so we went all in, on the new product, the the time that we did spend on our on, on features or bugs on the old product. The one thing that we did that was different was that we marketed the hell out of the work that we did on their old product. And so while we did far less on the, on the old product, the visibility on what we did, and also the importance of what we did, because we did a lot of customer surveys, and did sort of customer voting on which features they wanted on the old product. And so we we ensure that the customers felt like, as much as we could felt like that we were listening to them when it came to the old product. And then when we actually delivered on a few of the items that they asked for, we made sure that they knew about it. That still led to a bunch of kicking and screaming, because it was super obvious to a lot of our customers that we were still spending less time on the product and developing the product. But it certainly helped cushion the negative impact of that.

Now, I mean, you mentioned the customer's kind of kicking and screaming. I mean marketing, the new features and functions that you put into your old product was certainly one strategy that sounds like you employed. Is there anything else that you guys did to manage pushback from your existing customer base? And did it end up impacting those retention metrics at all, once all was said and done?

Yeah, it's interesting. So you know, on the retention metrics, one of them, as you well know Steve, one of the awesome things about niche ERP software is that it's super sticky. Right. And so I think that there was this difference between I think, if you took the NPS off our if we ask the question a different way, and we said, how was the NPS or the overall health of the customer relationship changing? I would say that the overall health of the legacy customer relationship, because of the product was certainly being affected. Right, they wanted updates, we weren't giving them as frequent updates. But it didn't translate into retention, because niche ERP was just so embedded and so sticky. The other reason was, we certainly did do a couple other things.

So one other important thing that really helped Steve, and Steve Lao's team dealt with this one was, we ended up reclaiming probably 50 to 75% of the legacy customer base, on the features that already existed in the old product. The old product, the old product, actually quite broad and deep. And one example is the thing had the thing and the ability to produce, I don't know, 270 reports or something out of the box. And SQL queried, you know, we queried the data, and only about 10 or 15 of those reports were actually being used. And then everything else was basically just being completely ignored as if it was never in the product, just because we had never trained the customers.

So on that point. It's interesting, because when we did serve the customers, and they sort of gave their feedback on what sort of whether its reports or features they wanted, literally 60 to 70% of what they asked for. We already did. They just didn't know that we did it. Right. And so that sort of reinforces renews his point on the retraining piece that helped.

Yeah, the retraining helped. And then the other piece was, you know, just not only marketing what we were building on the old product, but you know, kind of being quite open and visible about hey, by the way, we're also building this new thing. And particularly where we thought it would be applicable and taking those customers under the tent and getting their input and collaborating with them on the new build, which got them excited about the company's future and onboard, but with the new SaaS build.

Yeah, what I'm hearing is both the blessing and the curse of an incredibly feature rich product. On one hand, in part, it's one of the reasons why retention rates are so high. On the other hand, I had a very, very similar experience where I'm just kind of making up numbers here, but they'll be directionally correct, I would estimate at 85, maybe even 90% of our customers probably used 20% or less of the functionality embedded within our product. How about retention? Once all was said and done? Did retention stay steady as you suspected it would?

It did. For the most part, it really looked like a flatline. And pretty steady overall.

That's great. So we're more than six months in now, you have put your heads down and built v1 of this new SaaS product, as it was becoming available for customers to purchase. For how long did you guys continue to sell your old on premise product? And, you know, why did you make the decision that you did in terms of, you know, should we keep selling it? Or should we not? And again, what did you learn from asking your sales team to sell both products? If you ever asked them to do that at all?

Yeah, I think we rip the band aid pretty quickly, once the new product was solid enough that we felt it being, you know, doing a good enough job at a customer's company that it was sort of steady, and it wouldn't blow up. And we felt like, hey, we can distribute this across hundreds of potential customers. Once we felt comfortable at that point in time, we effectively stopped selling the on premise product altogether. From our perspective, why take a customer on prem, that's worth a fraction of what that SaaS Customer or that customer would have been worth on the SaaS product. So it was a pretty clean break. It was it wasn't it wasn't easy. And reviews can probably give a bit more detail on the sales teams transition. But we certainly rip the band aid off as quickly as possible.

Yeah, I think that, you know, the reason we were also quite binary with the with the approach was or extreme, you could use the word with the approach, the go to market approach was because we didn't want to confuse the go to market team. I think if you give salespeople sales, you know, they're phenomenal at kind of positioning the product, and they're phenomenal using the arrows in their quiver, as you know, as you guys well know. But I think that it can become quite tricky, if you give them alternatives, they will almost always go to the path of least resistance. And so we were just really clear with the go to market approach, which was, we're only going to sell the SaaS product. And there's these very specific exceptions scenarios where we can look at the on premise solution, because at no point in our in the future, would it ever work otherwise. And I think that that clarity really helped.

One quick follow up on that. When you guys first released your SaaS product. Was there any change to the market into which you sold the early version of that product? And the reason why I asked that question is because it is common for CEOs in similar scenarios to kind of go down market. So target smaller companies with earlier versions of products under the assumption that smaller companies will have a simpler set of problems to be solved and would be happy with a smaller set of features and functions relative to their larger peers. Was there any change in the market into which you sold it early versions of that product? Or do you just kind of dive right in?

So no, that's a great question. I think the the change was probably not as stark for us. As for maybe other more enterprise software businesses, but longer sales cycles and Meteor enterprise software products right? Because even before we bought the old product we were selling mostly to smaller and mid sized H vac shops, H VAC plumbing electrical shops. But certainly we what we did was we launched a pared down version of the workflow, we probably covered about, you know in the initial release, we covered about 50 to 60% of the core workflow of the Legacy product, maybe 50 to 70 percent. And then the and we focused on the the most important aspects. And then the other pieces we added were and where we really differentiated was the user experience, the simplicity and ease of use. It was just screaming modern and easy to use. It was almost we used to, we used to joke it was like Amazon and QuickBooks or Instagram and QuickBooks had a baby, right.

Like it had the ease of use of, of B2C software and the workflow depth of enterprise software. So short of it is, we launched with about 50 to 70% of the workflow core of the Legacy product. And then we differentiated with user experience. And then we also differentiated with this thing that we call value orientation, where we really focus not only on helping these contracting businesses run their business on our software, I mean, that we felt was table stakes, and you had to do it, right, that was the price to play. But also, even more importantly, to help these businesses grow and make more money. And so things like managing their online brand and managing their marketing dollars, managing the way they're priced, managing the way they're sold, each backup planning business while they were at a customer's house using our mobile app with a visual price book, so on and so forth. So that's the way we thought about to go to market. And then basically, what we did was we gradually expanded that core and went up market after we got that initial feedback.

One additional follow up remains, that's such an interesting answer. And when you joked that, you know, if Instagram and QuickBooks had a baby, another question popped into mind that might come out of left field for you guys. So apologies in advance, but I do think it's an important one. Earlier in the conversation, you mentioned that you're you effectively declared bankruptcy on your old codebase. It was complex, hard to update, hard to add new features and functions, lots of technical debt, etc. And then on the other hand, you mentioned your new products was slick, and it was easy to use, it was built on a modern tech stack, etc. Let's talk about the developers who actually built this thing. Presumably, the old product and all of its merits and problems were built with our by I should say, a group of developers. Did you entrust that same group of developers to build this new product, that seemed like it was step changes better? Or were there changes that were required within the dev team to get from, you know, the problems of the old product to the merits of the new product?

Yeah, yeah, it's such an important part of the transition from on premise to SaaS, which is the way we think about building the org to do the new build. So I'm glad you asked the question. So we inherited a team that had expertise in dotnet, and C Sharp code. Again, neither Steve and I are are technologists. So I hope you don't ask us to explain the details of architecture code. And so it was interesting, right? We inherited this team, and the team was actually the architect was phenomenal in our tech diligence, the feedback, you know, came out really strong that, you know, this gentleman was really good at how he thought about architecting the product. And so ultimately, what we decided was, if we wanted to build a new product, or net new product agnostic of a technology team, right, let's say we could have picked any technology team without any constraints.

We would probably have built it on, you know, maybe we would have built it on on, you know, no GS and hosted on AWS. And what that means to us now is it's a modern tech stack, you know, hosted on best in class infrastructure. But because we inherited a dotnet, C sharp team, these guys had a ton of business logic experience, right. So they knew the ins and outs of the domain. They knew the ins and outs of Field Service Management, both on the desktop side and the mobile side. And so neither Steve nor I had domain, and there was no product function in the business. And so we felt that it was just one extra gamble to take, which was, you know, hey, let's actually bring on a new team or augment this team. We just felt that there was no way we could discard this business logic, which was so instrumental. And until we decided to stick with this team, and the team did wonderfully.

And so we built the new product dotnet C sharp, but we were forced to host it on Azure. And I think the team did wonderfully because they already had the business logic. And then they were able to, they were able to really effectively transition their skills to to the world of building a net new SaaS product. Now the one caveat to all of this, Steve is, it did cost us a little bit in the end. The way it cost us was our hand was forced tried dotnet C sharp code. So because of that we were forced to host on Azure. And as we, as we realized, and you know, I'm sure there's people out there who are Azure fans. And look, neither Steve nor I, or agile are hosting infrastructure experts cloud infrastructure, and by any stretch, but because of the hosting and infrastructure decisions we were forced to make. And the code base we picked, we had quite a bit of infrastructure pain during that first year.

And so when we talk about infrastructure pain, and there was certainly doubt more downtime than we would have wanted. There were more outages than we would have wanted, there was more lag in the product than we would have wanted. And so there was this constant battle around, hey, you know, the product went down for three hours. And this is the second time this month that's happened. And when you're in, you know, the blessing and the curse of selling mission critical ERP software, you cannot afford to go down. It's super sticky, but you cannot afford to go down. And so anyway, we certainly dealt with that. And eventually, we were able to clean it up. But it took us a little bit longer than it would have if we had the luxury of going with the most modern tech stack, with the most modern infrastructure.

Yeah, the other piece worth mentioning there is I think we were fortunate that the team that we inherited, was actually invigorated and excited by having the ability and the opportunity to work on a new product in a SaaS environment. And I wouldn't say that's necessarily the case for all on premise type companies and their development team, right. Some of them might be very comfortable in sort of what they're doing and resistant to the change. But it was quite the opposite for our for our team. And so I think that really helped in terms of the energy. In addition, I think, we also brought on VP of engineering, who was actually a gentleman who helped us during diligence, and he was very fundamental in helping build the new product and sort of taking the reins of the existing team and helping to augment the team, quite game changing from that perspective.

He was incredible at being able to straddle both. And you might have been coming later to the Steve but you know, we'll speak to it in brief right now, which is that, you know, this gentleman we brought on, he was just instrumental at straddling technology and business. And so I think, particularly for search fund CEOs who, you know, acquire a technology business who may not have a technology background, in Steve and my case, or even if they do, I think being able to find this type of business executive who can, who can have the technical depth to be able to really work closely and earn the respect of your, of your chief architect and of your of your engineers, and of that entire team. And the bar there is obviously high, but also have that kind of business agility to be able to talk pricing and go to market and, you know, feature creep and get the customer feedback.

Things that are actually material versus not go into rabbit holes of like things

It is very rare, like just such a scarce like, you know, we could spend, we could spend two hours talking just about, you know, the importance of being able to find that resource and we were lucky enough to bring that person on board. And I think we could have tried 10 times and fail 10 times. So I think there's certainly an element of luck. I mean, we certainly search far and wide, but there's certainly an element of luck and being able to find such a phenomenal leader.

Yep, you know, it probably sounds borderline cliche to say this, but people drastically underestimate how important cultural implications are in successfully navigating this transition. And we will talk about that in further detail in a few minutes. Before we do though, I want to double click on another sales question, because this was something that I struggled with quite a bit in in trying to affect a similar transition in my business, which is the issue of sales compensation. Now, how did you change if at all the comp plans of your sales team because they went from one pricing model to a very different pricing model? They went from selling one product to a similar in one respect in a very different in another respect product? How did you think about changing the comp plan for the sales team? Did you encounter any unanticipated challenges related specifically to Salesforce compensation?

Yeah, it was interesting. So you know, this is a little bit maybe not, not entirely specific to the on prem to SAS transition, but, you know, one of the but it is closely related. One of the things we encountered was when we came into this business, the sales reps were being paid on is on residual income streams basically. And so and so it was that dreaded situation where, without selling a single dollar of new business, you know, the reps would make, call it between 150 to 200 grand. And then the variable portion was the extra 50 to 70 grand on top. Yeah, already fat and happy. And so that was again, you know, it's one of those situations, search fund CEOs you come in, and we've gotten this really great kind of piece of advice, which was, from a federal more experienced CEO who said. Listen, you come in, and you're only as good as a search fund CEO, you kind of gotta hit you, you've got to hit your revenue numbers, and you've got to hit your budget.

And, you know, it just adds so much more wind in your sails. If you can kind of go out, nail those first 1, 2, 3 quarters, and earn that credibility with the board and just get that confidence in yourself that you can go and deliver on the P&L. And so you don't want to mess with the sales team. And so basically, what we did was we didn't mess with the sales team for the first year, we kind of let this let this situation even though it was pretty messy from a pretty backward compensation structure, we let it run for the first year, we didn't make any changes. But what we did in parallel is we built a bench. And all the new sales reps that we bought, were on a new and highly variable compensation structure so much closer to that 50/50 base OTE split, that we that we try and strive for, with account executives. And so you're building up this bench of sales reps and cleaning them up. And then that's how we that's how we manage this transition with the launch of the new SaaS product.

I think I'm gonna go back to your point around culture, which is that one of the interesting things was we didn't even fully know how to price the thing, right. And so we knew that we needed to make it worth their while to sell the product, there needed to be, call it a strong account executive should make in and around let's say, a 150 in low mid market SaaS a year. 5050, let's say base and variable compensation split, but we're changing prices, do you keep changing your commission commission percentage all the time, and that becomes super messy, super quick. And so what we did initially was we brought our sales reps, we work really hard to bring our sales reps under the tent. And we kind of said, Hey, listen, for the next three months, all bets are off, we have no idea how to price this thing, we're going to make sure that if you guys do well, you're going to get paid. And you're going to make what you should be making if not more, you're going to have the opportunity to sell a fantastic product here that's going to be market leading.

But we just need you to be on board with a constantly evolving and messy and changing situation. From a price perspective and a commission percentage perspective, we're really clear with that. And I can't tell you how much that helped us out of the gates, I think if we took the opposite approach, which was Hey guys, this is this is the way the new world is going to be and it's not going to change. And then if we went back to them every 45 days with our tail between our legs, it would be just so much more difficult.

I think one of the one of the key things that for me is you did during this, this whole transition, and it was very difficult. And but one of the key things that I think led to this being successful was was finding a champion, a champion culture carrier, someone who had been in the company for a while, who had the respect of pretty much everyone on the team. And you worked really hard to get this individual alongside. And that really percolated throughout the organization, the sales organization, and I think without that person that would have been much, much harder for you to execute that.

Yeah, he was incredible. He was he was incredible and instrumental. And I think it goes back to the point that both you were making about culture, right? And I think people use the culture word. People use the culture word really broadly and and you know, we throw it out all the time, but it particularly in the case of sales, compensation, and change management as part of sales incentives to having that champion in place. You're absolutely spot on Steve,instrumental.

So to make sure that I'm understanding this correctly, did you guys have a period during which you had some percentage of your sales team selling the old product under the old commission structure and some percentage of your sales team selling the new product under the new commission structure? And if so, how did you manage the potential of an us versus them type of mentality?

We opened up the new product to the entire sales team. We established strict guidelines or relatively clear guidelines, I should say, around those few situations where it would be okay to position the old product. But we were pretty clear, hey, listen, 90% of the time, we're going to sell the new product, because we wanted more and more of our new customers to be to be on the on the new and more valuable revenue stream and an infrastructure. So we were pretty clear with that delineation. And then what we did was with the old comp structure was the old comp structure, but it became kind of less relevant, because they weren't selling the thing that as much right. So everybody was kind of focused on, on Hey, what how are we going to get paid when we sell the new thing? And then what we did was when for the new product, we kind of said, Hey, listen, for three months, we're going to mess around. And, you know, if we're going to experiment with pricing, it was interesting. We started off at 75 bucks, a customer per month for the mobile app.

And then I remember talking to the sales guys, Steven. Steven, one of our sales, guys, and we said, hey, guys, like, what do you think? Do you think that you're getting a ton of pushback on this price? And they said, now we got to jack it up. We think we can sell just as much could but jack it up. And so this afforded us the opportunity to really experiment with pricing, which is, you know, a whole separate discussion. And so for the first three months, we played around with pricing. And we basically told our reps, listen, we will effectively in a way make you whole will take care of you for a quarter just be on board, it was small dollars to the business, the no skin off our backs, right. And it was the right and fair thing to do for the reps as well. But we wanted to make sure that when we finally established at that structure, at the end of three months, there was a good and right price that was properly optimizing what we had built, with willingness to pay in the market, and that it was also fairly compensated in the team. But we knew we couldn't get there on day one. And there's other ways to skin the cat, we could have done a break pricing analysis, we could have done a kind of a big study on on sales, compensation and all of these things.

Or we could have spent half a million bucks on like, yeah, [inaudible] doing a pricing study, and I don't know if that would have been a better answer.

But let's let's talk about pricing a bit more. Rumeez's? Like, how did you guys arrive at the initial price for the first iteration of the SaaS product? And what if anything, catalyzed, I mean, certainly, it sounds like feedback from the sales team was one of the primary catalysts for you to revisit that pricing. But What process did you go through to arrive at, you know, price v2, v3, and v4, to the extent that that happened? Walk us through both the initial pricing decision, and then any subsequent pricing decisions that flowed from that.

Yeah, we were pretty, you know, for us, we took a relatively simplified approach to pricing the new product, right. So we felt that there was one competitor in the market, who was leading the pack, you know, they had raised a ton of venture funding, and they were leaving everybody else behind the dust, and they had that already strong product. And so what we built was comparable to that business, to what they were selling. And we wanted to be perceived as comparable to that business, we didn't want to be perceived as a discount brand. And so it was important that we priced in a way that our price point was fairly in line with the price point that this other competitor already educated the market on.

And then the second piece was we wanted to make sure our sales team was comfortable with it. And then the third piece was we wanted to make sure we experimented with it so that we could optimize around willingness to pay. So I think those were the three pieces, we played around with, let's go higher. You know, as Steve mentioned, like there's a bunch of these consulting businesses that specialize in it actually, these these shops that have come up that actually do a pretty good job that specialize specifically in pricing for SaaS products. And we got pitches from all of them. But we just felt that, you know, we could get to the same or better place by experimenting and iterating rapidly. And that's what we did.

For us. This is worth mentioning, it was much easier to do for us versus many other types of businesses, just because of how quick our sales cycle was right? Like for us. I think our sales cycle waypoints wait three months sales cycle. So the ability to iterate super quickly, was something we had the ability to do versus like Gulf tech company. You can't really do that because the sales cycles are one year, sometimes a year plus long.

Now, did you guys ever consider relating the price of the new SaaS product to the price of the old on premise product in any way? I mean, in my experience, both firsthand experience actually doing this, as well as secondhand experience, you know, benefiting from stories like yours, I know that a lot of CEOs, at least in the first iteration of the pricing decision, try to relate the price of the new product to the price of the old product in some way, shape or form. Did you ever attempt to do that? And why or why not?

We just felt that that we didn't as the short answer, we just felt that that would cause, we wanted our pricing pitch to be just super clean, and simple for the customer to digest. But our customers, our customers, were not CIOs of big corporate, you know, they were people running people working 60, 70 hours a week, you know, working their butts off to build a great contracting business. And then trying to fit a software purchase decision, you know, as part of that intense week or month that they're having. And so they wanted, they were craving simplicity in the product, they were craving simplicity in every part of their customer experience, whether that was while they were being sold to, whether that was the product that they were using, or whether there was the customer support that they were getting after the fact.

And so even in the sales presentation, you know, we had a simple, you know, kind of perspective, which was, look, there's kind of, they bring up that often bring up other lower end competitors. And you kind of say, Hey, listen, look, there's us, there's this other competitor, here's how we differ from them. They're also, you know, kind of great business, we don't bash them everyone. But we've got a ton of domain experience 30 years that they don't, this is this is the this is a top tier, then there's everybody else, we shouldn't talk about everybody else. And then here's how we're different from the other competitor. And here's how we price. And that was that.

Yeah, yeah. The other piece worth noting, in terms of rationale for why we did not link, the new SaaS pricing to the old on premise product was for us, we knew that the biggest source of value creation wasn't in converting our existing customers onto the SaaS platform. That was meaningful, for sure. But we had something like I don't know, 3000 ish plus or minus customers on the old on premise platform, which is a lot of customers. But this is in the context of a market with 300,000 of these HVAC, electrical and plumbing type companies. And so for us, we optimized around the dollars we would get from selling a net new customer onto the SaaS product, versus the ability to convert an on premise customer onto the new SaaS product.

That is a great segue into our next group of questions as we transition away from sales and pricing to issues related to customers and product. So let's double click on what you just mentioned, the conversion of existing on prem customers to the new SaaS products. Once all of a sudden done, guys, what percentage of your on prem customer base did end up converting to the new SaaS product? And how did that differ from your initial expectations? And maybe any general takeaways you might have from from that experience?

Yeah, I mean, Rameez why don't I quickly comment on this, you can jump in. But from our perspective, and this, this touches a little bit on what Rameez spoke about earlier, but, you know, the old on premise product had been built for over a decade, and was incredibly deep enrich and functionality. And there was no way that our sash product was was was going to get there. And so we knew that if we ever transitioned in on premise customer onto our SaaS platform, within the first call it six months, it would have been a disaster of an experience for them. Even though the ease of use, and the additional functionality was great. It certainly lacked on a lot of the core sort of workflow type stuff that, you know, those customers would have been quite accustomed to. And so our focus certainly was not on actually transitioning, any on premise customers to the SaaS product, during the time we were operating. If I were to guess, in terms of how many customers actually made that transition, I would guess, like low single digit percentages of our overall customer base.

Wow. Wow, so interesting. And so from a feature and function standpoint, you'd mentioned that your old product had, you know, decades of development horsepower underneath the hood. How did you think about new feature development specific to the SaaS product? Like it certainly sounds like you weren't targeting pure feature function parity between the two products. But presumably, you learned a lot about what features and functions your customers used versus those that they didn't use. So when you're looking at the blank slate of feature development for the new SaaS product, if you weren't targeting feature function parity, how did you think about which features to prioritize and which features you could just frankly not reproduce in the new product?

Yeah, Look, I think that there was this, you know, kind of price of admission to sell and provide niche ERP software. Right? If you're going to sell and have people use, effectively niche ERP software, you've got to have the score you about to have these core pieces of workflow, the ability to, in our case, the ability to create a dispatch, to create an invoice to send that invoice to QuickBooks, and so on and still be able to have a pricing presentation, so on and so forth. And so we kind of first zoned in on, hey, what is the bare minimum core pieces of the engine that we absolutely need to make. And otherwise, people just can't use this thing to effectively run their shop on it. And let's make this in as delightful, and beautiful way as possible. And as robust as possible. And so that was the first piece. But let's not try and boil the ocean and make more than we need to. Then the second piece was how can we help the shops actually grow, help these contractors actually grow and make more money?

And so that was I think the one where just input from our sales team, I don't know if it was Amazon's product team, or whether it's Amazon or Slack, or it was one of these businesses with a great product function. And they said that no product meeting is complete without a sales rep in that product meeting. And so we had our sales reps, kind of really tightly linked with the product building part of the puzzle, where in the year while we were building this new SaaS product, we would constantly ask the reps, hey, what features are you losing out on? What really resonates with the customers? What would they like to see more of? And the reps would come back and say, hey, listen, they'd love to see a way where they can visually present products and prices in the field. And so he said, Oh, wow, that's awesome. And then different groups would come back with the same input. And then we'd be also talking to our customers as well, I'm getting that feedback too. So short of it was we thought, yeah, go ahead.

I was gonna say on the customer piece, I think one thing that really was a game changer for us as well, was getting a small handful of customers who were tightly embedded in that product building type process and giving their feedback. And sometimes sending sort of like, you know, five minute videos of certain things that are working or not working and their perspectives. And they were completely bought in, in that product building process. And that was obviously helpful from from the product itself. But also, once the product launched, it was fantastic, because they immediately were raving fans of the product because they had their fingerprints all over it. So that helped from a reputational standpoint as well.

Yeah, the whole culture of the product Bill was really tightly. It wasn't flawless, by any means, by the way, should talk about mistakes that we made along the way too. But it was really tightly linked with the customer and the prospect. So we thought deeply about what do customers really want, we thought deeply about what will resonate with these prospects in demo conversations. And so even when we would have a sprint release, you know, after two weeks, the engineering team would come out and they would have built something, we would share that with the rest of the business almost in demo form. Or sometimes he would share that as if the contractor was actually using that feature. And it was kind of, it was a little bit, you know, it always felt a little bit weird, because there was like this roleplay.

And there would be somebody from product would be acting like a contractor and presenting that to a room. But that discipline really helped us because it became much less academic, it was less about building the school is less about building the school thing with all the bells and whistles that was academic and would never get used. It was much more about how do we fundamentally help these contractors grow their businesses and make more money? And how do we build something that will really resonate and truly make a difference for these businesses? We made a bunch of mistakes along the way, which we're happy to talk about as well.

Yeah. Well, I think what we'll talk about some of those mistakes and lessons in the final section here as we start moving towards a conclusion. And I want to conclude on some of these internal and cultural dynamics that we've been alluding to throughout the course of our discussion today. And before we get to the cultural challenges that presented themselves, actually want to take a quick step backwards. And in fact, go back to the beginning, when you guys communicated this change to begin with, I mean, presumably at some point, maybe it wasn't a single point of communication, but certainly there were one or more points of communication where you had to communicate the need and the logic and the rationale as to why you had to make such fundamental changes to substantially every aspect of this business. You have to communicate that internally. And as we all know, as human beings, we tend to be naturally resistant to change. So I guess, how did you communicate initially the need to make such a drastic change the organization? And any lessons that you took from potentially any blowback that you might have received from that initial communication?

I think for us, one of the benefits was, there had been many long standing employees at the company who had gone through similar sort of technology changes within the company's 30 year history. Right. So it wasn't completely foreign to them. But we did talk about where the market is going. And sort of the benefits, as we sort of discussed earlier on in this podcast and the benefits of moving on to a SaaS platform. But then really sort of communicating the so what for that, as sort of people who work in this company, why do you care? Why should you care? And one of the points that we sort of hammered home was, by us making this transition means more growth for the company, and more growth for them, specifically, individually, whether it's, you know, more more opportunity to get promoted to the next level, more opportunity to move to a different group that they might be interested in, more ability to sort of share the profits, all that sort of stuff.

And that message, I think, really resonated with a good chunk of the company. But to your point, Steve, on, people being resistant to change, we did a few of the folks out, who effectively self select and said, Hey, this journey is not for me, because it means more work. And I don't really care about having more opportunity. And we probably lost I don't know, in a company of 20 folks, three or four folks over time, because of that. But one other piece worth mentioning. You can kind of say whatever you want. But if you haven't established trust with the team, then anything you say falls on deaf ears. And so there were certainly a bunch of small wins early on that were amazing, I focused on with the employee base to sort of earn that trust, and show that we're listening and ensure that we're actually action on the things that we hear from them. And I think that went a long way, in terms of having this message resonate.

I think really marrying Yeah, I think that's exactly right. And I think really finding a way to marry these legacy employees are these these employees that had been with their business for. There were some that had been with the business for decades, and finding a way to make them champions. And we were lucky because there were a half dozen, or all of these folks that were just really phenomenal people and leaders. And so we were really, you know, careful, this is one of the things we were careful and intentional about, which was let's take these half a dozen to 10 folks that have been at this business, let's accord them the right level of respect and position and kind of presence in this business. And in this change, so that they can champion the change in tech and help us take the rest of this business forward together. I think that was a lot more powerful than, you know, Steve and I are coming flying in from Toronto into a business that the average tenure was probably 10 plus years, and saying, hey, guys, this change is gonna be great. Just take our word for it. To your point, Steve, right.

Yeah, the bedrock, the foundation of trust is such an important point. Without that. Everything else that you try to build is almost by definition built upon a shaky foundation. So I think it's such an important point. Before we get to our concluding question, which I'm most excited to ask you, let me ask one final question. And this will be purposely quite broad. As you reflect back on your entire journey, if you could maybe speak to either some of the major cultural challenges that did present themselves, and or if you could speak to some of your major mistakes, or regrets or things that you would do differently if given the opportunity to do so again.

Yeah, I think that when we started this on premise to SaaS transition, you know, we did the thing that you usually do, which is you call a bunch of people who've done it before, and you've done well, and you kind of say, Hey, what are your lessons. And all of them said, this one thing that came up glaringly, which is, you know, you're gonna have feature creep, and you're going to end up building stuff that people won't use. So make sure you think really thoughtfully about feature creep, you know, because for 30% your product people aren't just aren't going to use, no matter how they talk to you about it. And so we heard this so many times, we said, you know, swear to God, we're never going to make this mistake ourselves. And lo and behold, exactly that happened, right? It didn't happen. It didn't happen as much right? So we were really diligent about it, like really sharpening sculptor thing, but you know, I remember we spend these three weeks, one of the competitors had built this thing that looked awesome, right?

They'd built this capacity planning engine. And we said, this is amazing. And the markets gonna love it. And the sales guys thought this was amazing. And it was really tough to build. Everyone went crazy queueing and building it. We built it, we nailed it. And I think we've to this date, we have never sold a single sale. Because of that capacity planning.I don't think anybody's ever even shown it the demo because the thing is so hard to explain, you know. So that was one learning and other learning was, you know, one of the things we did well, this isn't your question. But one of the things again, we heard when we ask people for advice is listen, you need to launch early. Launch early, launch the MVP, the most minimum viable product, or as some people call it, the MVP, the minimal delightful product, right? Launch early, so that you can look yourself in the mirror, all the mistakes will happen. And you're gonna clean them up, right, get the feedback as soon as possible.

And we really took that to heart, we launched super early, right, we launched when we were like, really uncomfortable. And I think that was like there was a great decision. But it was incredibly painful. You know, I remember the poor, first alpha customer who had been along with us on our journey. She called us up like a month after the first launch. And she said, you guys need to get me off this tape. And so, you know, we took the feedback. And we felt terrible about that. And we eventually were able to clean up that particular situation and get her in a good place, but there was just a ton of shrapnel flying around. And I think that really fatigue the team now with this new business that we're building. With our latest business audibly, we were much more thoughtful about spending that extra 30 to 45 days, where we literally ironed out like, you know, 900 bucks, right.

And so the customer, poor customer team, the product support team, and the Alpha customers didn't have to take the pain of all those things. We found new ones when we launched, obviously, but it was a lot less painful. And so I would say launch early. But the caveat is, launch super early, but just be a tick or two more thoughtful about, you know, getting those high volume bugs out of the way. And that'll save you a ton of pain. Steve, go ahead. I'm sure you have other mistakes that that we made.

No, we made a ton of mistakes.Well, it's not exactly your question, Steve. But I think one thing that really worked well for us, and that it was probably informed by all the mistakes we made prior to sort of kind of figuring this was extreme prioritization. There were probably like, I don't know, a dozen things that could have added material enterprise value to the company. But we said, you know what, we're not going to care about 75% of them. Right? Or more. And only focus on the core, a few things, one of them being that SaaS transition, and the product transition. And we're going to try to do that and a level versus trying to do these dozen things that will ultimately end up being a C minus level. And it's hard for like Type A folks who come from, you know, whether it's banking or consulting background to do that, because you kind of feel like, hey, for me to be successful, I need to be working on two dozen things, right? Because that means I'm accomplishing more. But really trying to stay away from that, I think will help you helped us definitely in our journey.

Well, it's interesting. It's interesting, you say that, and we can move to the next question. I know, you'regetting long on this one. It's interesting you say that, Steve, but and by the way for disclosure, right? So Steve, Steve Lau was the guy who was, you know, let's do a bunch of these enterprise value creating things. And I was the guy who would be like, hey, let's, let's focus on the core. So I appreciate you saying that's the but we look back, and there's like a bunch of these things that we probably could have done along the way. Now, hindsight is 2020. So we'll never know. But, you know, Steve used to say like, we should focus on Channel and bizdev. And we never got to it. And after we exited the business, they've done such tremendous work from channel. You know, payments was another area of clear opportunity and low hanging fruit, raising prices on the Legacy product. That was easy, easy to do, and we never did it and left, you know, potentially left money on the table. So we'll never know whether we were right.

In typical fashion, we've gone completely 180, swapping perspective.

Swapping perspective. One of the hallmarks of our partnership, although we're a lot more stubborn when we're playing sport against each other. But yeah, we'll never know what the right balance there was, I think, I guess people will have to find what makes more sense for them, but certainly some good and some bad there.

Now, the conclusion, where I'd like to conclude today, guys, is to shift from the perspective of CEO and operator to that of the investor, because I know that in addition to your current company, auto leap, you guys are also active investors in the lower middle market. And I want to ask you about investing in similar situations. So knowing what you know, now you have been under the hood so to speak, would you invest in a company that was explicitly planning to begin the on prem to SaaS transition in? You know, we are recording this in August 2022? And maybe more importantly, under what circumstances would you invest in such an opportunity? And under what circumstances might you not choose to invest in such an opportunity?

Steve, I'll let you take this one, or at least kick it off. But I just want to make one comment, which is back when Steve and I were raising our search fund, when was that there was like 10 years ago, 11 years ago, it's crazy. Well, 2012 we went to, and there was there was, you know, one investor is pretty. More than one investor, he went to three vessels said, Hey, guys, are you going to look at tech companies? And we sort of said, Yeah, we're gonna look at Tech. So that's like, just absolute left field, like we don't even want to talk to you guys. Today, we're at today. Today, we're having a podcast about not only looking at tech, but would you would you invest in a company at a tech company? And would you underwrite kind of rebuilding the technology as well?

And for what it's worth, I'll mention that, when I financed my own deal for a software company coming from a similarly non technical background, of the my investors who declined to invest in my transaction, all of those investors cited the fact that it was a software company, a primary reason that they chose not to invest in. And now in the search fund ecosystem alongside healthcare, software is by far the leading category in which search funds invest. So over the past 10 years, things have changed quite a bit.

We had a person comment, he said, you know, look, Steve, there's these deals that are center fairway, there's these deals that are first cut, but [inaudible] is OB. Love it? You remember that?

Yeah, I think the risks are typically are higher than what incoming CEO often sort of thinks. But I do think there's meaningful upside to these sorts of deals. So in short, the answer would be yes. But things that would get sort of, I speak for me as well to both mean remains more comfortable as sort of having people who've gone through that transition, very close to that CEO, whether in a very close adviser capacity or an abort capacity, I think that can be, you know, that could very meaningfully change the probability of success for that sort of deal. And even in Steve, you mentioned, today's market, you know, you know, high growth SaaS companies are down, call it, you know, 50, 60, 70% in the market. But even despite that, I still think there's still meaningful upside in these sorts of transitions, particularly at the lower market, where sort of most of the search win deals would find themselves. So short answer is yes.

So, I mean, let me give you a framework, and you guys just react to it in real time. This isn't something that I necessarily prepared you for. But I've been asked this question a lot. And I think about kind of two different possibilities under which I would invest. These two possibilities are seemingly an opposite ends of a spectrum. But I think I would invest at either end of that spectrum, but I would invest nowhere in between. So let me let me tell you a bit more about that. So one option and these options are very, very different from each other. So Option A is it's a rather short hold period, there's minimal product investment, you increase the prices on a highly sticky product and execute on some other operational low hanging fruit and you probably put some debt on the transaction. I think and you hope that a couple of years from now someone's still willing to buy an on premise business at a reasonable valuation. Maybe you even choose to do the subscription pricing option but but maybe not.

Opposite side of the spectrum under which I also think it might make sense though this is of course riskier, though certainly presents the opportunity for a higher return is a much longer hold period, a meaningful product investment and mostly equity on the way in because typically, you have to take profitability way down. If for no other reason, then you're simply changing the pricing model to subscription, which has meaningful profitability implications. I think that could make sense too, I think where people get in trouble, and frankly, where I got in trouble doing this is I kind of was in the middle of those two things. So I wasn't quite, you know, a profitability oriented play, to speak to the former option, nor was I quite like a growth oriented play to speak to the latter option, I kind of felt like, I tried to get the best of both worlds, but I ended up with the worst of both worlds. Let me just table that and get your general reaction to it as investors now.

I think that that's a really, really interesting way to, to frame it, you know, stream of consciousness reaction. I mean, we're all kind of a product of our experiences. But the second one, option B, where, you know, just sounds a lot more interesting to me and speak for Steve. But I think one of the one of the most exciting things about the Desco opportunity for us was another opportunity similar that that we've been able to be a part of, as investors is the opportunity for unbounded upside, or tremendous upside with that multiple arbitrage. And just the opportunity for tremendous value creation. Yes, there is more risk along the way and more of a lift from an execution perspective. But if that bar of difficulty is dealt with in the right way, the ability to kind of unleash that tremendous upside, I think can be phenomenal.

I think the former, which is short term, hold period, jack up the prices, and hopefully somebody will take it off of your hands, that one to us feels like, it still has a reasonable level of risk, not as high a bar of difficulty as option B, but still enough risk, and significantly less reward because you don't have the multiple arbitrage and you have less opportunity to create value. So I don't know if you're totally averse to the first one, but much more inclined to the second one. Steve, I don't know if you think about it in a different way.

Yeah, I would think about the exact same way and sort of the ability to scale quickly, in that sort of SaaS environment is one of the beautiful things about the model. And that speaks to sort of the the upside component of an option.

And I would say that macro, you know, macro dominates micro, as we've said many times before, and as you've heard many times before and so the key thing is if the market, you know, stating the obvious, but the market needs to hold, right? So if the market is if the end market supports the high growth SaaS company where not only can you rebuild the product, and change the pricing model, but then you can tack on 30 BDRs on the thing and have this, you know, on steroids, go to market motion, both from a marketing and sales perspective. That to us feels a lot more exciting, supported, potentially by a shorter sales cycle, so that you can experiment. That to us feels like you know, all the right ingredients.

Yeah, guys, that feels like a great place to conclude if for no other reason than the fact that we are up against time. As we conclude, I will mention that I began my own on prem to SaaS transition, somewhere around 2015. And both Steve and Rameez were incredibly generous with their time. I called them incessantly and asked so many of these questions potentially even verbatim, to benefit from their experience, and their successes and their failures and their learnings. And they were very generous with their time and their insights all those years ago. And here we are today, 10 years later, and you guys were similarly generous with your time and your insights. And I'm sure everybody listening is better off for it. So thank you very much for joining us. And congratulations on your on your success with Auto Leap and continued success as investors in the search fund and lower middle market community.

Thanks so much for having us, Steve. Really enjoyed being on and so much fun to spend time with you. And we think you're doing great things with your podcast so awesome that you're doing it for the community and the impact that it's having. Great to speak.

Thanks for having us, Steve.