766 Moovilla: AI Project Management for MSPs

[Uncle Marv]
Hello friends, Uncle Marv here with another episode of the IT Business Podcast, the show for MSPs and IT professionals, where we talk all things tech to help you run your business better, smarter, and faster. We are here today talking about a topic that MSPs tend to ignore until it's really a big deal, and project management is probably one of those things that we know we got to do it, we just, you know, don't know how, except that we put together our little task lists in Outlook, or we put up a program like Monday or stuff, but there's a better way. And today we're going to be talking with Moovilla, and you'll remember them because they were the winners of the 2024 SWAG award.

And I've got the man in charge, Mike Cinca, with me today. Mike, how are you?

[Mike Psenka]
Good, Marvin, how are you? Thanks for having me on today.

[Uncle Marv]
I probably should have asked you in all of our prep talks. Did the girls all tell you that you guys you won an award with us?

[Mike Psenka]
We did, we did. Thank you for the shout out. I really appreciate it.

I see it in the background there for you. I know folks are just listening on audio, but we can we see the Tumblr up there in the background. So yeah, thanks for giving us a shout out.

We try to put care into all of those elements for our customers and the people we care about. So thank you.

[Uncle Marv]
All right. So I'll be honest, when I started talking to your folks, you guys have been around for a little bit, but I hadn't really been paying attention. And probably the first couple of times I saw your booth at the events that I was at, I probably just walked by.

And I don't have a reason. I hadn't heard anything about you. I don't know if it was just the way that people at the booth looked at me.

I'm like, hmm, I don't know you. And I don't know if I want to come up and grab your swag. So I apologize for that.

But here we are. And you guys have a great product, I think. So let me first ask, you know, give me the quick rundown when Mozilla, Moovilla, Mozilla, when Moovilla came onto the scene and what you guys are all about.

[Mike Psenka]
Yeah, well, we came on the scene all the way back in 2016, where we began the R&D process of developing automated project work and management. Right. So we have AI in the core in the heart of our platform and have been doing that sort of for a long time, kind of traditional expert system type of AI function.

We're leveraging some of the latest other tools and technologies as well. But we got into the MSP space a few years back because several MSPs had come to us. We were in other areas, other verticals, retail, finance, commercial, other spaces.

And some MSPs have become aware of the technology in the platform and said, look, we're really struggling with project management. You know, there are a lot of PSA platforms out there that are utilized today. And just it's not sort of a core focus of those platforms and projects work was important to them.

Right. And so they said, hey, we love what you're doing with the automation. It looks really, really cool.

We want to use it, but we're not going to double entry. You've got to be integrated. And so we made this strategic decision.

We looked and analyzed the market and went, wow, there's a lot of pain in this space around this. And this is important and critical. And we kind of when we learned about the community, we just we liked the community.

And there was a strong parallel to another industry construction. And so we built the first integration with Connectwise and had great success with that. So I went on to add integrations with Kaseya Autotask as well as Halo, which have recently come online as well.

So and that the market has just kind of been wonderful, wonderful to work with and wonderful to engage, I think. So, you know, it's been a few years, but I'll say of all the industries and I've been doing tech for over 30 years and software tech, I would say of all the industries, this is the industry more so than any other where I've seen competitors want to help each other. You know that there is sort of, you know, this fraternal order of kind of MSPs where they go, yeah, I know we could potentially compete with each other, but let's share best practice.

Let's figure out how to help each other. Let's give back to the community. And that's just a really cool thing to see.

So I think that, you know, we've been excited to work with and in this community for the last several years.

[Uncle Marv]
All right. So, of course, a couple of questions popped into my mind as you were chatting. But I first want to go back to just the core of what the product is, because it obviously didn't start in our space and coming into it.

But your platform was built on AI and helps to do a lot of the automating, organizing, communicating, blah, blah, blah. But what makes Moovilla different than some of those platforms I mentioned earlier, like Monday and stuff?

[Mike Psenka]
Yep, absolutely. So, you know, you think about the Moovilla platform very much. It has all the traditional functionalities of project management, portfolio management, resource management, capacity, forecasting, scheduling, budgeting, all of the sophistication where you think of a Microsoft project, an Oracle Primavera, Monday, you know, Smartsheet, all of these sort of large platforms.

The big differentiator for us is at the heart of this entire system is something called the critical path engine. And it's a very large, sophisticated, discrete math engine and expert system that governs and controls all of it. And I guess so you can say, OK, you know, that's a lot of fancy, blah, blah, blah, your branded term.

I think the more approachable way to think about it is when my CTO and I started around this, we said, look, nobody's thinking of work like a programming language, right? We program software, write software, structured work should be thought of like a programming language, which means you then can debug it and you can automate it. And why do we think, you know, we know programmers need a debugger because they can't write code without debugging it.

Why do we think people who manage projects are perfect and flawless in their dates and their process and their structure? And, you know, we have come to learn that they weren't. They were everybody makes mistakes because we're human.

And so fundamentally, if you were to say, hey, how is it different? You know, we say, hey, don't manage, we're programming. And if you have a structure or framework where work can be programmed, you can then welcome and integrate automations, AI debugging, facilitate all this other stuff and produce far more integrity and credibility around the management of this work.

All the other systems are great and they're really good at collaborative work and sharing, but they enforce little to no rigor around the structure of that work and the trust of that data. And so a lot of our customers will go, God, I just, I feel like I can, I trust now. I have confidence that I can trust this information.

And I'm also finding out about problems before they blow up in my face. And once again, that's just think about it sort of like an automatic debugger scanning the work continuously going bug, error, challenge, problem, just like, you know, maybe an RMM does. And that's fundamentally the big difference, but that had to be at the core, right?

That was developed. That wasn't an add-on that that was built from the base up to say. And to be honest, Marvin, we didn't like, we thought, well, this may be too abstract, like this idea of programming work.

And like, it may just be too early for that. People might not want to do that because they'd rather go, no, we're collaborative. We manage we're, but fortunately there are segments that when we get it, we get the value of that.

And yes, you are sort of solving the problem that's been blowing up on us for quite some time. So, and the MSP market is certainly one of those. Okay.

[Uncle Marv]
So let me ask real quick, was it a big transition to, you know, go from where you started in 2016 into the MSP space? I mean, did you, did you have to do a lot of tinkering with what you started with?

[Mike Psenka]
So I'll say no. And part of the reason why we did it, because we have a big partnership with an organization called Komatsu, the heavy equipment manufacturer. Komatsu is like Caterpillar, but the second largest maker of bulldozers and excavators and mining equipment in the world.

And we partnered with them a while back because they have autonomous bulldozers and excavators. And their principle behind it was, Hey, as a society, we can't require people to have 20 years of experience in a bulldozer. We're aging out as a society.

We got to start to automate this. We got to be able to stick anybody in a bulldozer, train them quickly and have them be competent. So they went down that path and that industry went down that path.

But five, seven years ago, Komatsu came to us and said, “We love your tech. We love what you're doing. We, that needs to happen for construction businesses.

They don't have the bandwidth or the experience to have a lot of program managers and project managers and PMPs and running their finances. We'd love what you guys are doing in automation. We want to OEM your tech and build that out.

And so we entered into that partnership with them. And that's been a great partnership as we've gone forward. But when the MSP market came to us and said, we like what you're doing.

A lot of the complaints that MSPs had about what they were struggling with really paralleled strongly for these construction companies. And the industries look really eerily similar, right? On average, these heavy civil construction companies are five to 50 employees on average.

Yes, there are some really big ones, but these are people who founded their own businesses, built through reputation, how they manage that process. They're a margin sensitive business that have projects. They get frustrated because their projects leak margin when they run over on cost.

They're having difficulty managing status, weather and other factors change and customer related things affect the timelines of these projects. So all of those things that had happened when we interviewed the MSPs are like, yeah, that's a problem. That's a problem.

That's a problem. That's a problem. Okay.

Like we're wired as a tech for this. You know, now we have to learn the culture and the people in the process to fully understand and align. And so we've been on that journey, but the tech didn't require any sort of wild rewiring because it was, like I said, there was such a strong parallel to this other industry that existed.

And those problems were, were eerily similar.

[Uncle Marv]
Okay. So I'm sitting here trying to translate myself because I have to imagine larger MSPs understand this a lot better because they're dealing with, you know, larger, much more complex problems. I'm wondering how you've addressed it with smaller MSPs where a lot of our projects are just simply a group of tasks, you know, whether it be a 365 migration, a move or something like that.

Those are our typical projects. And I'm trying to figure out for those types of MSPs, and we're not doing a demo, but is there a way you can describe to me how, or an example of how you would automate, I guess, like routine tasks for project management?

[Mike Psenka]
Yeah, that's a great, that's a great question, Marvin. So, so I would say, you know, people say, oh, you know, who are, what's your target audience? What's your target audience in the MSPs?

As you astutely point out, the very large MSPs, it's a no brainer for them, it would be utter chaos if they didn't have, and, you know, they were desperately struggling with this issue of this is damaging CSAT scores, reputations process, there's too much data. As you sort of go down, down, down, you know, right now for us, our customer base, you know, for the roughly couple of hundred MSPs that we have are sort of 20 employees and above in general are in that range. Businesses, and I would say, you know, if you were to say like the people who are seeing the most benefit are these businesses that are growing and scaling, businesses that are saying, hey, we want to get acquired, we want to improve our efficiency around this, so we look attractive to another organization, and then obviously the larger organizations.

So smaller organizations are folks who say, hey, I like being small, I want to be small, you know, we say, hey, if it isn't broke, don't try to fix it, right? You understand, and I will say that there's a scale of an organization in which the owner's mind is so efficient at keeping it all in a row that you know how to pick up the phone and call your engineer or call the two or three engineers, you know what you're doing, and that the efficiency within the human brain around those kinds of things, I think, outweighs the benefit of trying to do lots of work to automate something. So I would never encourage somebody who, you know, doesn't have a larger volume to put on lots of extra work around that. However, having said that, there are some additional things that I would say can benefit smaller MSPs, and some of the things we have coming, and that's around community sharing of content and project and best practice, right?

So the larger businesses have developed, their projects are essentially products that they got really efficient on delivering, whatever it is, and many MSPs, whether small or large, deliver similar products to the market, and the smaller MSPs don't have the advantage of hiring expensive consultants and having 1,000 at-bats at it. But the larger ones do, and the consulting companies do. And so, you know, when you say, hey, what's a benefit for a smaller MSP?

It might not be to retrieve all the benefits of critical path automation and automated scheduling of engineers because, hey, that happens in a phone call, right? But it could be the benefit of living within an ecosystem where you get the best practice, essentially in operating instructions on the most efficient way to execute a component. And that's kind of future speak, Marvin, and I will say additionally on future speak as well, which is a really cool thing that will be coming as well.

So having a project, whether it's an onboarding or whether it's a firewall, you know, there's, hey, there's 37 things that we have to do for this, right? And there are 37 steps in that project. We're moving towards the idea of that product, of that template, having automations, AI-driven automations and activations at endpoints of those tasks for a percentage of those.

So instead of maybe an MSP saying, well, I've got this thing I have to do, and it is 37 tasks that I have to do all of them. It's, well, I've got 37. I don't have to do 30.

I only have to do 20 now. 17 of these are now automated because it's running like software. And so that's where we see that this idea of work and project automation really helping the entire spectrum.

Because once again, as you point out, you're like, hey, is there really, you know, is there that much of a benefit for a smaller shop? And I would say, no, if they're smart folks, they can manage a lot of that stuff in their own head. But the minute you start to talk about like buying or getting automations where they don't have to do the lifting, that obviously translates to better margins, easier life.

[Uncle Marv]
Well, it makes sense because I'm in that mindset. I'm a smaller MSP, but I want to be able to manage my projects better than what I'm doing, you know, no matter if I scale or not. I mean, it's just, you know, the way to go.

So a lot of us are going to look at, is the cost benefit ratio worth it? And a lot of ways, I always think it is, but the price has to be right, obviously.

[Mike Psenka]
Is the juice worth the squeeze? And, you know, as we talk to organizations and sometimes we'll talk to smaller organizations and we definitely have smaller organizations that use it. And I would say one of the biggest buying decisions for some of the smaller folks was managing their credibility with their customers and ensuring that they were delivering accurate dates because problems occur.

And I think it was this issue of being able to, with integrity, communicate and say, here's the project timeline, here's the critical path, and being able to understand when a customer delay affected that critical path automatically going, yes, you know, I know that we said we're going to have this done on April 7th, but I needed this from you and you, and let me show you how this has created a 17-day delay in critical path.

And that's, you know, the emperor's new clothes is always sort of a difficult conversation to have with customers. And we always talk, you know, and it's always interesting. And I'd be interested in your opinion on this, Marvin, is, you know, if I were to ask you what percentage of the time, if you say there's a delay in a project, what percentage of the time, and this is going to require some vulnerability on your part, what percentage of the time would you say it's the customer's fault?

You know, I'm not going to tell them that because they're the customer, they're, you know, that's the king. I'm not going to tell the king he's making a mistake versus, hey, it was kind of our fault. It was a supply chain issue.

We were busy. We dropped the ball. What percentage of the time would you say it's a customer's issue versus yours?

[Uncle Marv]
Well, I'll be, I'll be quite honest. I actually just have been speaking about this. I've got a project that is taking way longer than it should have.

It's project has probably been 25% my fault when there have been issues and 75% theirs. But that's a control issue on their end. If I were to talk about my other projects, when there's been delays, when there's been issues, it's probably 50-50.

[Mike Psenka]
Okay. And that's generally what you, your first answer is sort of what we hear from most MSPs, that 70, 75% of the time, it is a customer induced delay, but they also say like 0% of the time, are we comfortable communicating that to the customer? And what happens when there's a delay and the customer isn't aware that it's their fault?

It's your fault, right? And so that's a frustrating issue for the customer, but they need to know that, right? And you can communicate that if you have the fact-based.

So that is another sort of important component.

[Uncle Marv]
All right. I’m sorry, we're going to go way off track here because, so I have no problem communicating with my customers when there's a delay, first of all, and second, whose fault it is. You're telling me that a lot of MSPs have issues letting them know that there's an issue because it's the customer's fault?

[Mike Psenka]
So I'll say this, when it's clear what the issue is, they know that. However, for larger, more complex projects, they don't understand the impact on the critical path. And so I'm going to step back for a second, and I don't have the luxury of visuals here, but in a project, tasks have dependencies.

Hey, I got to buy the router before I install the router, so to speak, right? Those are dependencies. So you have dependencies in a project, in a task, and the critical path is that longest dependent chain of tasks that define the length of the project.

So there might be 40 tasks in a project or 50 tasks, but the link of these 17 define that this project is going to take a month and a half, right? There are other tasks that are there, but it's these 17. But what ends up happening is, at the start of the project, those 17 define that it's a two-month project.

But as the project goes on, two weeks into it, there's a task lower in another work stream that gets delayed, and that becomes the critical path, right? So people operate going, oh, we got to do this, this, this, this, this. And then this other thing comes in to create a delay that, because they're not aware that the critical path has changed, that delay, this other thing they didn't do is, we don't know this yet, but this is now going to delay the project two weeks.

You get to the end of the project, it's two weeks, and they go, oh, shit, I didn't know that that thing was what was going to cause the delay. And so when I say that they're comfortable doing it, it's really clear if the customer doesn't respond to a specification. But it's also tough when you find out at the end of the project, you trace back and go, aha, we're late because you guys didn't do the specification.

And the customer's like, yeah, but why didn't you tell me that then? Why didn't you tell me that then? So, you know, and once again, you are really in touch with the projects in the process and delivering in the execution on that.

So you're intimately aware of it. In larger midsize and large organizations, that transparency doesn't exist. And so the engineer goes, oh, I couldn't do it.

It wasn't ready. We didn't get this from the customer. They're not as in tune to that critical path change or that execution.

And so once again, it is always hard to go back late. Early warning detection system is sort of the key here. Does that make sense?

[Uncle Marv]
Oh, it does make sense. And putting it in perspective, obviously, the larger the organization, the more hands involved in the project. One person doesn't tell another, but the manager may not know.

So yeah, it's there's a lot of dependencies there.

[Mike Psenka]
Yeah. And that's why I said you have the beautiful benefit of having all those board meetings and emails occur in your head. I mean, there is no substitute for the efficiency of a small MSP.

Like they reap some massive benefits of being able to track and monitor. And that reaps higher CSAT scores because the customer experiences that there's just a point of scale in which the human brain can no longer do it.

[Uncle Marv]
That is true. That is true. So let me make sure I do this because we're probably not going to have enough time and we'll have to parlay some of this into the live show.

And by the way, if you're listening to this audio and you're listening to it in order, we are recording this on Thursday, February 13th. Mike and I are going to be doing a second show and it is going to be live on February 19th. That'll be the Wednesday live show at 8 p.m. Eastern. So that will be part two of that. So finish listening to this one and then go check us out on the live show there. When I was talking with your people there and we were talking about some topics and stuff, the whole idea of a project paradox is what they wanted to frame all this in.

And it sounds like a lot of what we talked about already is part of that paradox. But can you lay that out for me in just kind of what the basics of a project paradox is?

[Mike Psenka]
Yeah, sure. Well, it all it comes down to the basic fact that human beings suck at probability. Like our instinct, for whatever reason, the good Lord, evolution, whatever you want to call it, we were not gifted with an inherent sense of accuracy around probability.

And that gets us into trouble. And I'll give you a couple of examples. So many people may have heard of the birthday paradox.

The birthday paradox says if you have 23 people in a room, there's a 50 percent chance that two people share the same birthday. And people go, well, wait, there's 365. It doesn't make sense.

It doesn't matter if it makes sense. It's the truth. If you have 60 people in a room, there's a 99 percent chance that two people share the same birthday.

And many people's instinctual response is, well, that doesn't make sense to me. Oh, it doesn't matter that it makes sense to you. It's the truth.

And anyone who wants to gamble or bet on that, I'd be happy to take your money. Like, this is the truth. Well, what does that have to do with projects?

Well, if you have a project and there are 40 tasks in the critical path, these sequent tasks, and let's say everybody gets their work done on time, 90 percent of the time, nine out of 10 times, they get their work done on time. What's the probability that that project is going to be done on time? It's about one and a half percent.

It's a really, really low number. And people don't realize that. And furthermore, nobody has one project going on at a time.

If you have 20 of these projects going on time, the probability that the sun won't rise tomorrow, that the sun rising is a random chance, I think it's like 6.03 times 10 to the negative 17th. It's a really tiny number. The sun's probably going to rise tomorrow.

But the probability that a portfolio of 20 of these 40 task projects, the probability that they're all just going to go and work well and everyone's going to kind of get, even if they get their stuff done 90 percent of the time, the probability is I think like 3.05 times 10 to the negative 37th. Like, it's a billion, billion, billion times less likely. And so what does this mean?

It means we're doomed statistically to have problems in the same way that anyone managing a network knows. It's not a question of whether an endpoint is going to have an issue. It's a question of when, because it's the same issue.

It's the same probability equation going on. And we know and accept that and understand that with endpoints, right? But people don't realize a task and a project is an endpoint.

It has a rate of failure. And when it fails, it can cause problems. And so, you know, we encourage people to understand that, hey, it's not a question of if, it's a question of when you're going to have task endpoint failure.

What can you do to remediate and minimize the impact or the risk of that endpoint failure? And, you know, we talk about this automated project monitoring and management, just like RMM, it's doing the same thing, right? To reduce, to address that probability problem in favor of the MSP or the end customer.

So, because most people just don't realize the odds, you know, you're just going to have a problem. It's just simple coin flip math, honestly. You're going to have problems.

Now, do you want to know about the problems early so you can address them and fix them? Or do you want to find out about them late and after they've done the damage that they've done?

[Uncle Marv]
Interesting. So, in a sense, there's risk management that needs to be built into this. Yeah.

The assumption is something's going to go wrong somewhere. And are you prepared to deal with it, let alone communicate it?

[Mike Psenka]
Yep. And when will you be communicating it? Late?

That's a reputation. And we always say, look, AI is awesome and automation is awesome. The MSP industry is a relationship business.

It is going to continue to be a relationship business. Despite all the amazing AI and tech, it is going to continue to be a relationship. And that relationship is founded on trust, support, credibility, right?

And you're going to have problems. We know it statistically. Your ability to communicate those problems improves your credibility to your customer to go, yeah, we have problems.

But they picked up the phone and they called me and we worked on it together as opposed to, yeah, we had problems. I had to call them and let them know that they were late. Or that becomes, what else aren't they doing?

What else are they getting wrong? If they can't get dates right, are they really managing my secure environment? So that's why we say, look, this is a really important reputational issue for you to get ahead of because you're going to have issues.

Just like endpoints fail, tasks are going to fail.

[Uncle Marv]
Right. So you just mentioned something where, so when I was looking at what a project paradox would be, I was thinking in terms of speed versus quality. Customers always want it done fast and we always want to do it right.

And then another part of that, because there's multiple parts, but one was control versus collaboration. And you mentioned who's going to communicate with who when the issue comes up. One of the big problems I've always seen, well, not always, but that comes up a lot is I try to make sure that a customer never calls me to check in and make sure everything's okay.

And you made the comment that somebody has to call somebody and say, well, why didn't you let me know? And of course, we don't want the customer to ever be that person that calls and said, hey, there's a problem with this. Why didn't you tell me?

Does Movila have a collaboration feature where everybody on both sides, both the MSP and the customer sees where the project is at any given time or it's Movila just for us and the customer never sees it?

[Mike Psenka]
Yes. You can invite customers in as extended members. So they can look at the critical path.

They can see their tasks. They can see where they're introducing a delay and it can communicate to them automatically via email. If my customer's not going to log in or whatever, it can let them know, hey, there's a delay here.

There's an issue. Have you completed this? So they can participate in that journey on those projects with you and ensure that they're accountable because at the end of the day, there is this issue of accountability.

You know that you're going to be accountable as the service provider and deliverer, but the customers have to be accountable. They have to be accountable. And that's kind of gentle accountability, right?

It's this gentle reminder and awareness of, hey, this is what's going on. Remember we said this. And I think we all have that experience when we have another service provider working for us and they inform us, hey, no, you're really busy, Marvin.

I did need this from you, but it's okay. We're going to be, just want to make sure you understand. We're going to be probably a couple of weeks late.

And you go, oh, I'm sorry. I know I was supposed to get that to you, but you're not upset, right? Because they're letting you know ahead of time.

And I think that sort of gentle accountability, we try to facilitate that in the tech. So those people that want to use that have a way to communicate to their customers that may be challenging or problematic to inform them and go, hey, we did tell you there were emails, there was communication. We wanted to alert you that this is a critical path item and it's currently delaying things.

We're not supposed to deliver for another three months, but we're two weeks behind now. And I already know it. That all of a sudden lets them know, oh my God, these guys are on top of this.

They're very dialed in and predictive as opposed to reactive.

[Uncle Marv]
All right. Well, I was going to ask you about that predictive part, because my thought was, this is going back to me watching HGTV with the wife, where there's one show that they always know that if something happens, it will put them X number of days behind. And they can tell the client that, is there a predictive thing inside of Movila where if one of those tasks doesn't happen, is it able to project out how much of a delay the rest of the project would be or am I asking too much?

[Mike Psenka]
No, no. So that's exactly what it does real time in the project. So as those delays occur, that risks, and I'll talk about it in a couple of different ways.

So there is continuous server-side monitoring around all the projects in the portfolios. Even if no one is going in to touch them, it monitors, tracks those, identifies, hey, you've got a capacity conflict. This project changed.

You're expecting someone to be in two places at once. That's going to create a delay. Like it monitors and alerts.

And there's something called an RPAC score, which is sort of like a credit score for the project where it'll say, hey, the project is either poorly structured or you've got a critical path delay or a risk. So it does that. And then it forecasts and says this is now the probable delivery date of this project.

This is the delay. If you have penalties or there's financials associated with delays or early, it'll automatically calculate those so people can understand the impact and risk. There's also another component of this, which is analyzing past performance and variation.

So the platform has a very rich template structure process where you can productize or templatize your activities. And then it'll automatically analyze real-time all the projects that you've done that are similar and tell you, you keep estimating four hours for this, but you keep logging seven hours for this. Like if it's a fixed bid project, you're losing money on it.

You should change this. You keep saying it's this type of engineer, but you know what? This type of engineer keeps working on it.

So you should change the resource type on it. So it'll go through and analyze and pull up the details, right? So it's not just giving a summary value because you may go, well, I know we're off on that, but this was an exception.

I want to exclude that. Okay. You know what?

This template is fine. The devil's in the details. I will say that.

It's always giving the user the ability to go into the details and say, you know, I think that's, I do need to change that. We are spending more time on that. So that backward looking and always analyzing what you've done to say, Hey, your estimates were right.

Keep doing it. Or, and then we can automatically update it. You, Carmen, the AI agent will say, Hey, do you want me to update this template automatically for you?

Change the resource type and up the number of estimated hours. So the next time you use it, you have a more accurate picture and you can opt to do that or not do it.

[Uncle Marv]
That sounds absolutely fantastic because I mean, even, even for the smaller ones, I mean, yes, we're on top of stuff, but if I could give a much better estimate based on past performance, that would be awesome.

[Mike Psenka]
Yeah. And it goes to that idea of, you know, getting to this productizing your business, right? Whatever size you are at a conversation that it was CEO of the former CEO of the largest, or one of the largest MSPs in North America.

And, you know, he said a big part of our journey over the last 10 or 12 years, he goes in all businesses is this idea of really productizing what it is you do, even if it's a project, even if it's a productized, productized, don't think of it as kind of one off. The more you do that, the more you can control your margins, improve your business. And that's a journey that businesses make.

And he was sort of saying businesses of all sizes need to make around this idea of productizing their work, because then they can understand the value of the revenue. Hey, these are the kinds of things I want to continue doing. These are the kinds of things I should probably stop doing.

[Uncle Marv]
Nice. Mike, I want to switch gears here and try to end us off here so we can have stuff to talk about on the live show. So I said this to another guest a while back, and they kind of got weird on me.

But I'm going to ask you and I'm going to try to do it in a much better way. You sound awfully excited about Moovilla and you're what, we're eight years in, nine years into this. Let me ask first, what made you start Moovilla and how are you still so excited?

[Mike Psenka]
That's funny. Well, this isn't my first rodeo, right? So the last business we had, we had a really successful business kind of exited.

And when we did that, we looked in and for me personally, I like a puzzle and a problem. I sort of geek out on like, oh, this seems like a really important problem and an intractable problem. And you say this has been a long journey, but when my CTO and I got into this business, we knew this was a little bit like bench research in a lab, right?

Sometimes researchers will spend 10 to 20 years on a project and it might or might not work, but you got to make that, they know that going into it, making a commitment to go, hey, we think this idea is important enough to society, people, the benefit of businesses, that it's worth risking five, seven years of time before you bring it to market and go, oh, it does matter. It doesn't matter. And so we knew that there was going to be a long road of delivering this sort of differentiated, hey, program work, don't manage it and building out that architecture.

And so, you know, you say, why don't we have the energy? I think we're just so excited that now over the last several years, like it's bearing fruit because there was just a lot of effort that had to go in to build this thing out before someone could drive it. And I could go into more details.

I've sort of got a car metaphor. I've been asked this question before and I'm like, you know, it's like we had an electric car and we had the really cool electric engine, but people were going, we love the torque and the speed, but you don't have a radio in it and you don't have air conditioning and you don't have power windows and you don't have leather seats. And my wife's never going to get in this car, so I can't buy it.

It's cool. Don't get me wrong. And you know, that's where we were in the beginning of the journey.

And we knew, hey, it's going to take four or five, six years to get everything there, to bring a new car to the market that's got this differentiated tech. And so I think the enthusiasm and energy that I have is probably just because we're going, oh my gosh, it matters. People love the car.

They're driving it. They're excited. The electric engine does matter.

Like it, you know, it does seem to be important to people. It is providing the benefit that we thought it would provide because if it didn't, that would have been pretty discouraging.

[Uncle Marv]
All right. Well, that's a, that is a fantastic answer. Glad I, glad I asked.

So Mike, thank you very much for spending some time with me. I know it's a commitment to do two shows, but I, I again, want to thank you for that. I am, listen, you got me excited now about Moovilla.

[Mike Psenka]
Thanks Marvin. Hey, I really appreciate you giving us the opportunity to come and talk. I do love talking about this stuff and I can see your passion about the industry and the business too.

So thanks for giving me an opportunity to share time with you.

[Uncle Marv]
Absolutely. And we welcome you back again, folks. We're going to be having a second session next week on the 19th at 8 p.m. Eastern. It will be streamed live on all the social medias, YouTube, LinkedIn, and the Facebook. So sign up now and join us then. We'll be back with the CEO and founder of Moovilla, Mike Cinca.

So Mike, thanks for coming on the show.

[Mike Psenka]
Thanks Marvin. Thanks everyone.

[Uncle Marv]
All right, folks, that's going to do it. We'll be back soon. Check us out later.

And until next time, Holla!