Meeting Market Demand: The Evolution of the MSP Offering

Hey everyone, welcome to this month's MSPs in Conversation. Today we are talking about meeting market demand: the evolution of the MSP service offering. As always, this will be recorded. We cut this up into a podcast, YouTube, Vimeo, Spotify, all the usual places. Please feel free to share it around. It's a great resource for your team as well, to learn about different topics. And if you see the social snippets come up, like and share. If you have to jump off, there is no stress at all. We will try and finish on time, as always. And if you've got questions, please feel free to drop them in the chat. As always, I've got some extra questions today that we will be asking, so feel free to challenge our panelists as well. Always have a bit of fun with it.

So, as usual, a little bit about Hosted Network. Hosted Network is a wholesale cloud and telco provider for Aussie MSPs. We were an MSP way back when, but our focus is on delivering cloud and telco solutions the way it should be for MSPs: simple, easy, no margin burn. All right, enough about us though, because we're not here to hear about Hosted Network. We're here to hear from our amazing panelists. Ryan, welcome back. And Meg, thank you for joining us for the first time. I will let both of you introduce yourself, and Ryan, I will start with you.

Thanks, man. And thanks for having me back again. For those that don't know me, I'm surprised, after this many. That's right. So look, I ran an MSP for 25 years, a midsized MSP, and exited that in 21 and finished up there in 2022. Now I help MSPs both buy and sell MSPs, so acquisitions and mergers, and also around operational maturity and increasing profitability, etc. So it's probably easy enough that if you don't know me, really, yeah, apologies.

Well, thank you. And Meg, first time, welcome.

Yes, thank you so much for having me. I am Meg, or Megan Visser. You'll find me on LinkedIn as Meg Visser. I've been in IT for about 20 years now, or almost 20 years, and have worked across several different MSPs in Australia and across the UK as well. Today I sit as the chief customer and marketing officer for Otto. We're a medium-sized MSP based in Melbourne with a presence across Australia, and a few global team members as well. Hi Joel, nice to see your name in the list there. Really excited to be here today, and to have this conversation.

Cool. All right. Well, let's jump into it. So, I will stop sharing. And guys, I will encourage, if you've got questions in the chat, feel free to drop them in. Always keen for audience participation.

How Customer Expectations Have Shifted

The first question that I've got, and let me move my note over here so I look like I'm not staring off into space, is for you Ryan. What, in your opinion, dealing with as many MSPs as you do day-to-day, are some of the most significant shifts around customer expectations that you've seen in the last few years?

Yeah, look, I think let's say since COVID, it's probably a good example. So let's frame this at four to five years. I've definitely seen, or I'm sure you would have seen, or MSPs have seen as well, that customers are expecting a price reduction in their IT services, or managed services, as I say, has become more and more commoditized. There is a price pressure downwards in that. And obviously, with cyber, I would say up until about three years ago, two, three years ago, and even now I'd say for some customers, they just don't see that, don't understand it, don't understand the risk. So a lot of times you've got to explain that risk to them, and they still may not ever get it, to be clear. But I think with the Medibank breach, Optus, all of those things, Qantas now, I think, to be honest with you, those things, I feel sorry if you were caught in them, but I think it's probably some of the best things that's actually happened to the industry, that people realize that this can happen to the big names. So there's a good chance it can happen to them, and what the impact of being one of those people that were part of those breaches, and what information was shared, etc. So I think that's kind of interesting.

So I think I've seen, as said, the MSP side has been commoditized and going down. Cyber is going up. I think the spend in cyber, everyone starts saying, well, we need to do more, there's more risk. There's around risks around, again, Essential Eight and SMB 101, all of those types of areas. So we're seeing an increase in spend in those areas. So I think, and I openly say this on stage, I think overall the spend is increasing by people, by end users, but again, most of that's going into the cyber area rather than traditional managed services. And then obviously now you've got AI coming in there and everyone trying to work out how to monetize or commercialize AI. Which is probably an interesting discussion, and I know you've had some panelists on about that in the past, and I'm sure there'll be a question or two about it today as well. But yes, I think that's probably more professional services engagement rather than reoccurring engagement at the moment. But if someone can figure out a way of turning that into an easy reoccurring revenue, I think everyone will be doing it too. It's certainly changing.

I look at the Qantas one that was, you know, the most recent one that we've all sort of felt, and we've talked about a few times. You're right. And for those that haven't seen it before, I'm going to do a quick plug of mspsinconversation.com. You can see all of our previous recordings there. And Ryan's right, we did cover off some AI topics and some cybersecurity ones. But Meg, what are you seeing from the customer side? You're in the thick of it at MSP land today, and have been at a bunch of MSPs. What are you seeing the customers are asking for and need?

I think the market is shifting in terms of what the customer needs. Several years ago, and still today, MSPs talk about and focus on SLAs, and exceeding SLAs, meeting SLAs and all the rest, which is great. And I think SLAs still have a really important piece to play today in terms of contractual obligations and a safety net for clients, and a structure to work towards or work within within our help desks. However, clients don't want to not be able to work for half a day and to then be told, "Oh, but we're responding within SLA." We have been talking a lot at Otto recently that SLAs suck, and everyone's so used to today now being able to access everything on your phone quickly. We're very spoiled with convenience in our society, and when something doesn't work and you have to wait, it's frustrating. It's annoying, and clients aren't going to sit around and wait for that poor service to resolve their problems. They're going to start looking elsewhere. So I think that's a really interesting conversation to have with your teams. How do we exceed SLAs and even remove them a little bit from the conversation, whilst also balancing our team and making sure no one's burning out, because we have to work really fast to meet our clients' demands.

That's definitely a challenge, right? The customer balancing, what that experience actually is and what we can actually deliver and what their expectations are, can potentially be two different things. I'm going to jump off the back of that. Sorry, great point, and I 100% agree with you there. It's funny that if you're going back to your SLAs, you have a bigger problem. The fact of saying you're in an SLA, there's a mismatch of expectation there very quickly. And I don't know if you'd allow everyone to do this, or like all account managers and BDMs to do this, but one thing that we did, and this was back in the day for us, was we would actually say, well, yes, you might have a 2-hour SLA or a 4-hour SLA or an 8-hour SLA depending on which particular plan you were under at the time. What we used to do is actually show, here's our real-time stats. Here's our actual service, actually our SLA response times that we look at, it's sitting on a screen in our office right now. And I used to bring it up on an iPad, and it's like, this is real-time stats. This is real-time data. So while your SLA says that it's 4 hours, we're on average getting back to you in 78 minutes, or whatever it happens to be.

And that works really well from a sales pitch. It's like, well, again, if we're worrying about going back to the contract, yes, we all need to have a contract in place, and all the inclusions, exclusions and SLAs and all of those things need to be very clear. But if you're going back to that, there's a problem. So realistically, hey, this is how we perform, and I'm showing you on this lovely screen right now. This is how we manage our customer interactions. This is how we manage our business. And how many other providers will show you what their real-time statistics are?

Yeah. And data, from a marketing perspective, having those stats and figures out there, it's so impactful writing a statement about SLAs and things, if you've got the data to back it up. It grabs people's attention when they see those percentages and figures displayed publicly on your website and your socials.

I also think today as well, cyber is such a huge part of the conversation, and for us it's not an add-on. Every one of our managed services clients has a support agreement and a cyber agreement. We won't sign on a managed services client unless they have that cyber agreement too. It's such a fundamental piece of it today, and you just can't function without it. You need to have your cybersecurity protocols in place, and if you don't, what happens when you do have a breach, your client has a breach and they hold you accountable as their IT provider, but you haven't got a cyber contract in place. I think, to what you were saying before, Ryan, clients don't always understand what goes into cybersecurity, and what's required, and that's our job to tell them, you need to have this in place so that doesn't happen. We're not selling you this because we need to make you hit a target this month. We're selling it to you because you really need it to protect yourself today.

Yeah, exactly.

So, yeah, I think so much has changed. We've been through the shift from on-prem servers and physical hardware to the cloud. We're now going through today's shift of seeing what AI means for business and how that's going to impact every single element of business, not just from an IT and cyber perspective, but also productivity. How does HR use it? How do you make sure there's no biases in your AI? How do you make sure that the data coming back from the AI is accurate? How do you safeguard it and make sure it's staying in your environment as well? And it's not just conversations for us internally as MSPs, it's conversations that our clients are wanting us to have with them too. So I think that other shift is that education piece, that we need to get up to speed with what's happening in the AI space so we can hold those conversations with our clients as well.

I saw one of our partners' signatures yesterday. I don't know if he's on the call, I'll give him a shout out. His signature is basically saying that company directors are responsible for cybersecurity and those pieces as well, right? And little bit of a tangent, but I thought that was a good call out in his signature, every single email. You are responsible as well, not just IT. He basically said, you know, company directors are responsible, it's not just IT, you basically can't blame us. He said it in a very professional way, but that was the tune of the message.

We've got a comment from our COO actually, Lucas, in the chat, as we're sort of going through this as well. So I'm going to put it through to you guys. We, as a service provider to MSPs, we face the same issue, right? You guys need real-time support because your customers are expecting real-time support. So maybe you can give us some advice as well, and share it with everyone, but how do you provide almost real-time support when at the same time customers are expecting it cheaper? They want faster, but they want lower cost and things like that. How do you balance that?

I think it depends a little bit on the customer that you're working with. Because that conversation in terms of cost isn't true for a lot of our clients, but it is true for some. But I think for the ones where the cost element isn't so much of an issue, or even really both, it's just an honest conversation that this is a contract. Well, in fact, actually, our contracts aren't based on SLAs. So we're not going to respond faster to you if you are on our top tier MSA versus if you're on our bottom tier. So I just make that clear, that we respond at the same rate with every client regardless of their MSA level. But in saying that, if they were wanting to somehow increase that response time, that they could, I don't know, pick up the phone and call a dedicated technician, we just have to have an honest conversation with them and explain what our business model is, and find out exactly what it is that they need. That might not be the right solution. It might be having somebody on site once a week so they've got a face that they can talk to, their team can talk to. But I think it's just having a really open and honest conversation. And if it does come down to cost, maybe you're working with an NFP, you could look at how can you give back to that charity. We will often, on a project, add in a discount line item as a donation for that charity, so we can give back to our clients in that way. So I think it really depends on the client. I don't know that there's a one-size-fits-all response to that question, but that's my two cents.

Well, the reality is you're going to also respond not necessarily on SLA but based off priority as well.

Yes.

And unless, and look, as much as people won't say it, and you're an MSP and I don't expect you to say it, the reality is we are going to stack and rank customers, we are going to stack and rank their problems. If two customers come in with P1 tickets and you can only work on one before the other, well, you're probably going to look after the one that's on the higher plan, or the customer looks after you better, or the one that's paid you on time, or any of those things. That's just business. But it's really based off, again, the priority of the situation. A business where someone can't do payroll and it's payroll day is critical. But if someone can't do payroll and it's 5 days after payroll, and it's not going to come around for 2 weeks, well, that's not a priority one case. They might think it is, and it is for that one particular person, but in the scheme of the overall situation, it's not that high a priority. And you'll get to it in 2 hours rather than 15 minutes, or you'll get to it in 90 minutes, or whatever it happens to be.

Yeah. And I think that just comes down to communication again, having that conversation. Hey, we've got a hospital that can't issue medication. We need to deal with that right now. Is it okay if your issue waits, because you're able to still work, or whatever it is? Having that open dialogue and setting the expectations. I think the worst thing you can do from a customer service experience is radio silence when someone's expecting service now, or needs help now, or sees their issue as a really high priority, but for some reason you just can't get to it. At least picking up the phone and talking to them and telling them, this is when I'm going to get to it. The no-update update.

Yes, indeed. Just at least touching base. That's a common theme of panelists on here on MSPs in Conversation, around that no-update is an update, and communication is so fundamental.

AI and Automation: Where the Opportunity Lies

Okay, so we'll move on a little bit. We touched on cybersecurity a little bit, and that's definitely been the theme for the last few years, and I think, as we recently talked about, it's going to continue for the foreseeable future in reality. AI is a new one. We're definitely seeing, and there was a lot of talk that came out of the Pax8 conference in wherever it was overseas, can't remember, around AI and the evolution of MSPs and TSPs, and how they were driving that into their business. What are you both seeing? And Meg, I'll throw this to you and Otto. What are you guys seeing at the moment? What are you doing around AI to plan for that, if anything?

Yeah. So I guess there's a few different angles to look at. Internally, we're using several AI tools to help with various things. Be it Copilot, hey, make this email sound better, or PIA to help with triaging tickets. We're using several different tools to sort of help with our own business workflow. From a client's perspective, we're having a lot of conversations around data security, and what you need to look out for when you're signing on with an AI tool to make sure that the data that you're putting in there stays within your own environment. It's not going back out to train a model. We're also assisting clients with writing AI policies. And it's not just a one-size-fits-all policy. It'll be a policy that's split out to address concerns that each different department will have, because AI works so differently in each different department. So you almost do need to have a separate AI policy for every part of your business. The last sort of angle that I'll touch on is we are looking at productizing a service around this, and it's all around business intelligence. We're looking at working with our clients on building AI apps and agents, at intelligent reporting using Power BI and how they can access more data from their business, and also business process automation. You know, that's such a big one. We are so appealing that our apps are doing the best job that they can for us and are connected. We are hiring a DevOps person at the moment to sit in the seat to carry out a lot of that work, but it'll also be coupled with our vCIO service over the top to add that nice consulting layer, and pair the two together. So lots of opportunity there.

That almost sounds like another business in itself.

Yes.

Ryan, what are you seeing in terms of, we've touched on AI, I can't remember if you were one of the panelists, but you and I have talked about it a lot. What are you seeing out there in the wild? Are enough MSPs taking advantage of that opportunity? And what should they be doing in your opinion?

It was Nick and Ronnie who were your panelists for that.

Thank you. Thank you. I've got a memory of a goldfish.

Look, yes, a lot. I'm trying not to get on my horse around AI, and I won't unless I get invited onto my horse. But yes, look, there's a lot of RPA, let's call it RPA, happening out there. You've got PIA, Rewst, CASA have got their Cooper bots, you've got a lot of different tools out there that are trying to help MSPs be more efficient. It can be from looking at their previous support tickets and saying, this is how it was fixed last time. So I think that's Thread, from memory. There's a lot of different products out there that are helping MSPs do these types of things. A lot of it is really based on your own data. So if you've got good quality data, again, these tools will do really well for you. If you've got really rubbish data, or, hey, I fixed the ticket, or the customer had a problem, I fixed it, well that does nothing for you. So it's still based off what data is in your systems as an MSP. But again, how can you be more consistent with that? So PIA and Rewst are handy for onboarding and offboarding clients, as in users for clients, and it makes it really consistent. You're going to have the same outcome every single time.

One of the things I think a lot of MSPs, as they scale, will end up having a problem where, hang on, Fred set up this computer and it took him 2 hours to do it, but Bill then took 2 and a half hours and forgot half the stuff. Those types of complaints or customer concerns come about. And that's where I think, with the RPA pieces nowadays, that at least gives you a consistent outcome every single time. Or at least 99% of the times, if you want to call it that, because nothing's ever perfect. So I think there's a lot of those things that can be done and can be used.

I think those tools are coming at a pretty serious cost, and you do need to be able to not have as many staff, or increase the amount of customers you have with the same amount of staff, to make them pay for themselves ultimately. So I think there's an element of that as well. One thing that I have been concerned about for the last couple of years when it comes to those RPA type tools is that people don't just try and race to the bottom even further. We know that most MSPs don't make a huge amount of money, they've got even a low percentage. The last thing I want to find is people that, oh, hang on, I've got a bot that can do all that now, or I've got a tool that can do that, so instead of charging a proper commercial rate, oh, I'll just win the business and charge $5 or $10 a user or less, and then the next person does the same thing to beat them, and then, again, that's right, it's a race to the bottom and we're commoditizing our own product at that point in time. It's bad enough customers wanting to see that price go down, but if we're trying to do it to ourselves, we're the ones to blame at the end of the day.

Yeah. We're cannibalizing our own industry.

Yes. Charge more, people. Charge more.

Oh, that's a different discussion we've had plenty of times.

But yes, people don't charge the right amounts, and don't do price increases, and aren't willing to have the frank and difficult conversation sometimes with their clients.

So, you've heard it here first. You've officially got approval to send out that rate letter email. Ryan told you to do it.

So we've got a percentage of clients that would come back with an issue. Well, yeah, and that's what we've talked about a few times, right?

Um, we've got a question here, just going back to the last piece that we're talking about around the no-update. Joel's asked, "Regarding the no-update, is there any benefit to having a member of the ops team sweep through the tickets on a regular basis and perform those updates?" I guess the no-updates, after chatting to the assignee as to the status of the ticket. Or is that just creating unnecessary busy work? So what have you both seen around that "hey, we're working on it" update? I think what Joel is saying is, have you seen that from an ops perspective, or are you expecting typically the technician or the engineer to do that?

I think the challenge with having an operations team member outside of the assignee do those communications is you're somewhat removing the responsibility and the ownership of the technician that owns that ticket, and moving that over to somebody else. And I think it's so important that the engineer that's assigned to the ticket is owning it. I think there might be a bit of a perception shift that needs to happen as well. We talk a lot at Otto about, we're a customer service business first, and our engineers that are on the help desk, their primary job is customer service. And when you're removing that element of communication, you're removing an element of that customer service experience, which really I think they should be owning. In the instance where you're too busy, everything's on fire and you don't have enough time to do anything, I mean, any communication is better than nothing. But I would caution that, with really the engineer should own it.

What's he saying? The Jim Collins, right person on the bus in the right seat.

Yeah. Yes.

Does he watch your... I think there's also, you've got to be careful as well. As much as I suggested the no-update update, you've got to be careful with it as well. You can't just keep doing it time after time after time.

No.

So it's fine for a once or a twice, or first or second time, but if you're now four weeks overdue and you're sending another no-update update for the fifth time or the eighth time, that's really, I think after the second, maybe third time, it actually becomes counterproductive. At that point in time, you're actually bringing attention to the fact that you've not done something. Now, don't get me wrong, if the no-update update is, hey, we're still waiting on your manager to approve this, that's okay, because it's actually on them. But if the no-update update is, hang on, I've not done something because I've been slack or I've been prioritizing something else, and after the second or third time, that's actually negative. It's not an excuse.

You're also diluting the voice of your business as well. If you've got so many status updates from a ticket in ConnectWise with all the extra fluff around it, the branding and the gray bit and the white bit and your little no-update updates down the middle, and they've got five of those with no real update in there, their emails from your business will start to be seen in a way that, I think, they don't really send me anything useful. It becomes annoying. It just becomes extra.

Becomes noise. I'm gonna steal that. Diluting the voice of the business. I think that's a great line. That's definitely going to stay with me. I've actually written that down.

Rolling Out New Service Offerings Without the Mistakes

Um, all right. So we're going to move back on to rolling out new service offerings and potentially the mistakes. So if we're talking about AI, we're talking about cybersecurity, different people on the call are at different stages of their MSP journey. So what are some of the common things that go wrong when we're rolling out a new service offering? And what would you typically recommend from a best practice perspective? Ryan?

Come up with a good plan to start with. Make some assumptions. Document your assumptions, so when you come back and review where you're at in 3 weeks, 4 weeks, 6 weeks time, you then realize why you made certain things. Continue to shape and hone it and get it better. Ideally, try and find a couple of friendly customers, or a couple of customers you can say, "Hey, this is our first one. We're going to cut our teeth on this. We're going to give you a slightly better price because we're cutting our teeth on that, but we want good feedback, honest and solid feedback throughout the whole process, not just after it." That worked really well for us. We would be open, honest to clients that, hey, this is a new product to market. And they knew from experience with us, if there was ever a problem, we were going to make it right. And that's a consideration. That's also why you can't go and say that to a brand new customer. Hey, this is the first time we're doing it, and you're a new customer, and yay. That does not go down well. A customer that's been with you 10, 15, 20 years, who knows you, and you've got a great relationship and great trust, it's really trust, that works well.

And yeah, you're never going to get everything right 100% of the time. And a lot of times, especially with a new product coming, you're going to segue off, you're going to tangent off. You're going to say, hang on, the way we just went was absolutely rubbish. We now need to zag back another way and do something different. And that's okay too. The biggest thing is, don't make no decision at all. I've said it for years as well: we're humans. We don't deliberately go out and make wrong decisions. Now, you may go down a direction and 5 seconds later, or five minutes later, you might find that's the wrong decision. So change. Do something different. Go a different direction. The worst thing you can do is do nothing at all.

Meg, what have you seen that makes projects, or new product rollouts or service offerings, be successful?

I think you need to, at the very beginning, as Ryan said, plan really well, and involve everyone in that piece. Not just from a technical perspective, but you need to have whoever your customer leader is. If it's head of account management, if it's a chief customer officer, whoever that person is, they should be in the room too. You need to have marketing there as well. You need to have some of your techs that are going to be supporting it. I think representation from around the business to help with that planning phase, and everyone to give their two cents from a different angle. And then, I was going to say before as well, have a client and roll it out to them and let them know that it's the first time you're doing it and offer it as a discount. We're doing exactly that with our business intelligence service offering that we're spinning up. We have an existing client that are really interested, we've profiled them as being super risk hungry in terms of emerging technology. And so they're a really great client for this service offering. They're keen on it. They want to do it. They're happy to get the discount, as everyone always is. And we're going to test it on them. So I think, yeah, good planning with the right people around the business. You want representation from most departments, and have a test customer if you can't test on yourself first.

Correct. A lot of times MSPs will eat their own dog food, or try test them on themselves, and that's okay too, as long as it's not in a massive production system. I think, I know a lot of MSPs, and I know we corrected this back many, many years ago, would often deploy something new or a new patch or something like that, and you get to a point where you're at a certain size where you can't do that. You can have a lab to do that, but you've got to make sure you don't impact your production systems, because at the end of the day, you're providing that as exactly what you said earlier, that customer service.

Yeah. I think there's also a research element as well. You want to test that the market wants that product and service too. There's obvious ones out there that people are talking about, but if you're doing something a little bit left of field that you're not sure how it's going to land, contract in a research agency and get them to test the market for you and give you those really good insights. Get them to survey your existing clients, prospective clients, competitors' clients. They go out there and get all the contacts, get them to get the data for you, so you can make an informed decision.

We certainly, I wish I had that advice many, many years ago. Hindsight's always a wonderful thing. Our team have a name for it, and it's called a bit of a BS. A bit of a Ben Special. Yeah, there we go. Luke straight away, he said it. But I mean, particularly when you're a growing business, and if I think back to 15 years ago running our MSP, we wanted to sell and we'd close a deal, but we wouldn't train anyone, we wouldn't document it, or whatever the case might be. And be like, oh yep, we've sold something new, and the rest of the team would go, wait, what is it? How do I support it? Where's the documentation? And fundamentally it would erode all margin that we would have been making, because everyone was just spinning their wheels. So yeah, there we go. My whole team is making a little comment around that.

So guys, from a, you know, we're rolling out a new service offering, be it AI, be it cybersecurity, or anything else, fundamentally, from a standardization perspective, what are the things that we've got to look out for? And to sort of lead you down a path a little bit, a lot of MSPs and business owners, we're tech-savvy and we get distracted by shiny coin syndrome. I know a bunch of partners that every single time they go to a conference, they come back with a new tech tool. It's shiny toy.

Shiny toy. We call it shiny coin.

I don't know. I mean, we're special. I've never heard that in my life. For the right reasons. But what are some of the standardization things that you would recommend to the audience to make sure that they're not burning those margins?

I think for your core business offerings, so your managed service agreement, your cybersecurity agreement, your vCIO plans, all the rest, you need to have your standard offering documented, really boring, in a basic table, with each feature in that service offering and what product delivers it. Is it internal service desk? Is it whatever? So you know exactly what you're delivering for that service. For the new shiny stuff, that's really exciting, and we're in it, we should be embracing emerging tech, and we should be looking at what's coming out and what's out there. If you don't have an R&D team dedicated, just set aside some time, a couple of days a week, a couple of hours a week, whatever it is, for yourself or some members of your team to have that R&D time to do some research and play with the shiny stuff and bring the ideas to the table, so you can discuss them and then ascertain whether it's something that is going to be profitable or worth it to your clients to roll out. But I think the key is to have your foundation offerings really summarized, solidified. You know what they are. There's no deviation. You understand what the profit is across them all, how to support them, how to deliver them, and then set aside the time for the shiny stuff.

I'm going to take that advice. David Vidos is actually just saying we should only do one to two shiny things a year. David, I'm hearing what you're putting down. Ryan, what do you think from your experience and what you see in the market?

Look, again, bringing anything new, I love what Meg said there. I think having a product development team, it could be someone from... We had three. We had one from projects, one from sales, and I was part of it as well. So I was the third in our product development process. We were looking for new, different ways of bringing a couple of products together into a new solution. So how could we provide a new solution to a client? Part of that process is really understanding, again, what the costs are, what the market looks like, how many customers would you have that could potentially buy it, how many customers would buy it. If you're building a product or a solution that only two or three customers, even five customers, are going to take, chances are you're never actually going to make money on that. You need to get to the eighth, 9th, 10th deployment of that before you start really making some good money out of it. Because you've got all the quirks dialed out. You've got all of the scripts and the automations to be able to make it efficient. You know where all the headaches are, and you've solved those types of things. So you need to look at, again, bringing something new to market, you need to look at how can we sell at least 20 of those, or can we sell that to at least 25 or 50% of our customer base. That's what you need to look at.

Yeah. So that's definitely a, particularly for someone like us in Hosted Network, right, we can't roll out one thing. We basically kind of do, even internally, with what you guys are saying. We align with a few friendly MSPs that we call our guinea pigs. We test out our bits and pieces and we make sure that it is going to be a fit, and it doesn't always work out, right? I like to say that we fail fast in that regard, right? Figure it out, fail fast, and then kind of move back.

Leveraging Vendor Relationships

But in terms of Hosted Network to our MSPs, we're a vendor, right? In your experience, how can MSPs leverage their vendor relationships more when they are developing new products, right? They're developing new service portfolios. How can they partner with their vendors more to do that? Meg, what have you seen? How are you guys doing it today?

Just before we move on, I had one thought come to mind when you mentioned failure before. And I think failing is so okay. If you have a new service or product that you're launching and it doesn't work, it's actually great learning. And I'm just piggybacking off The Diary of a CEO. He has a big component of that book that talks about failing and how failing encourages innovation. And I believe the example he used, the team had KPIs around failures as well, and they were tracking the failures. I think it maybe ties to the Kaizen philosophy. Anyway, I just wanted to put that out there, that failing is okay. Rather try and fail than not try at all.

Right. 100%. It's definitely a lesson. It's a learning point.

Indeed. And also the amount of learning that goes on in that failure. If you have an engineer that comes up with this plan to do this amazing thing and you say, "Yeah, go ahead and do it," and it doesn't work, how good is that knowledge that that engineer has gained from trying that project, and the confidence that you showed in them to allow them the time to do that? Anyway, I'll get off this tangent and address the other question.

In terms of vendor relationships, I think each vendor brings a different thing to the table in terms of what support they can give, whether it's from an MDF perspective to help with marketing efforts, or getting your team along to different events. Whatever that looks like, or potentially hosting your own roundtables or events like this one. There's other vendors that will help from a technical perspective too, that will have resources within their business that can help your projects team with different solutions and designing networks and whatnot. But I think it's just understanding what your vendors offer, and aligning with your account manager there, and seeing what resources they have internally to help you.

Ryan, how do you say working with vendors can help launch a new product?

Look, ask them. Ask them what they've got. Ask them, are they developing a solution at the moment that we're not aware of? How many times, again, it's no different than what we're doing, or the MSP is doing with their customers. They're developing a new offering. The vendor or distributor haven't put the final touches on it, or whatever it happens to be. If you ask them the question, they might not, the person you're talking to, or you might go, hey, we've actually got a solution for this, or we've been looking at this. Can we actually use you as a test for this, and can we actually help collaborate on it? If you don't ask, you don't know. Now, don't get me wrong, if you're doing something totally novel that's never been done before, then you might want to keep that to yourself and get it trademarked or something like that, to be clear. But it's rare. Again, we're in technology there. Most things are a copy of something else, or a variation of something else. So yeah, ask the questions. You don't know what's going to happen. And chances are, I'd say there's a good chance you'll actually find someone, or again, someone that's done it, or they know someone that's doing it.

And this is the thing, we don't, unless it's so different, in most MSPs we're not going to do everything to every customer. So a lot of times you can actually partner with another MSP or another specialist if it's something a little bit different. You might be able to partner with someone else to get those first five or 10 customers done respectively, each to each of your respective customers, to say, okay, how do we actually do this? Like even today, you look at the peer groups and you look at any of those types of things, or even outside of those, there's plenty of IT companies that will actually get together and share ideas and share concepts and develop things, develop IP that they share. Because, again, not everyone has the time, and no one really has the amount of time to develop these, to make things perfect. Again, a lot of times you're getting to minimum viable product for a lot of things, and getting it out there and learning as you go.

MVP. I love it. I definitely encourage those of you that are Hosted Network partners to reach out to our account managers and our team. And Sean's just made a comment that Dicker Data as well, but any vendor that are dealing with other MSPs, we hear about these things as well, right? And we hear the stories of what works and what doesn't work. And we're also very likely, even if we don't know firsthand, we know someone that will be able to connect you, and give you that sort of exposure and that experience. And so yeah, I definitely, in some cases, that's one of the first few phone calls I'd be making. Hey, what do you think of this? How would you do this? Rather than trying to figure it out, reinventing the wheel yourself, leveraging the contacts and the network that you've got. And hey, Meg, you mentioned MDF, as vendors, we have those funds and we have those resources available. And fundamentally, distributors and vendors like Hosted Network, our success is your success. Well, your success is our success, but fundamentally, success.

So that's a better way of saying it. Yeah.

Yeah, it is.

Internal Buy-In and Converting the Challengers

Moving on a little bit though. We touched on before around the internal team and getting everyone together first. I want to touch a bit more on getting that internal buy-in, right? I know that over my years, I've certainly sold some things and haven't really consulted the rest of my team, but the importance of getting that internal buy-in is critical. What's the best way to do that? And when you are getting that resistance, how do you work through that?

Are you meaning how you convert Ben's Specials into repeatable business process, and then everyone along the way goes, here we go again? And, sorry Meg, you're about to say something. Go for it.

Yeah, I can share some wisdom from a vCIO engagement I did a few years ago. I was working with a manufacturing client in a previous MSP, and I was running a digital transformation process for them. They had a whole bunch of on-prem servers. They had their office, several factories, things not connected, working together. The chair of their board wanted to be leading in the digital space for their industry, and so they contracted me in to help them with that. How I got buy-in across the board, being that in their space there were a lot of, there was huge diversity in their team, were really junior staff, young, starting out, keen for everything, to people heading towards the end of their career, very comfortable with what they're doing and with how they're using technology, or were using technology at that point of time. I set up a digital transformation committee which included, sorry to repeat myself again, but people from all around the business at all different levels. So every single department was represented, and it wasn't just the department managers. There were people from every single different level in that group. We would meet once a week and talk about everyone's challenges. I ran a survey across their entire workforce and asked them, what do you hate about IT? What do you love about IT? What do you wish you had? What do you wish you didn't have? Yes, printers is always a problem for everyone. And gathered all of that data with that digital transformation committee, and we wrote a strategy and we brought everyone along together for the ride. And I think that is why that engagement was so successful, is that we had buy-in from everybody, and everybody was part of that journey. Everyone contributed to that strategy, and that strategy was shared across their entire team as well. So if somebody wrote a comment in their survey, "My headset sucks. It hurts the side of my head. I really wish we had different headsets," that comment was in there in the survey results. So it could be like, ah, okay, I see that they're talking about the headsets because they're really uncomfortable. But I think that's the key, just getting everyone along for the journey, no matter what business you're in. That's how you're getting your team's buy-in, and I guess how you deliver successful projects.

Ryan, any comments?

Love it. I think it's perfect. I think you're right, in that it needs to be a good breadth of people across the business and across the team. It shouldn't be everyone. That's the worst thing you can do. And it's bring people in and out with domain expertise and some random people. Don't just, like, think of bringing someone in that you would never think about bringing in, because they probably got an opinion that actually works, and a perspective that most of the other team don't have. So it's really good to bring that as well, some of those people in that way.

Yeah, Sean's just said that every team has a champion that is the key to success. And I love that. I think that's great. Finding who those evangelists are across the organization or your client, right? Even internally or externally. I think even if you're delivering a project like what you're referring to, Meg, that's something to make sure, that you get that repeat business and the client comes back. More likely that the project is successfully delivered, the more future revenue you're likely to have.

And every customer is going to have a change champion too. So find out who that is, and note that in your system, and get that person on side, and get them to start, again, you could seed some of the ideas into that person's mind, and then they think it's their idea, and then they come to you wanting to buy something.

So Vidos has just mentioned, you know, what about the biggest challenger? So I mentioned evangelists, but should you involve the people that are more negative in that process, or do you kind of just push them to the side?

Yeah, I think so. Another client comes to mind. They're a hedge fund based in London, and probably one of the most challenging clients I've ever worked with. Their previous account manager, this was when I was an account manager, their previous account manager got into a verbal argument, very loud, both, I guess, angry men. The account manager before him, he made her cry. And then he came to my plate. He was a huge challenger in that he was really distrustful. It was never fast enough. He was distrustful of us, of his own team. But I chipped away at him, slowly worked on him, and eventually he became our biggest advocate. So I think absolutely, if you can. I mean, there are points in time where you need to consider, as the client, the right fit, when it comes to personality and your team safety and mental health. But in that instance, I wasn't part of a team making that decision. So I was like, right, let's make this work. And yeah, I ended up turning it around and it was great. So I think if all the stars align and it works out and they are a right-fit client and the right personality you want to work with, I think yes, absolutely, if you can convert a challenger, they can be just as noisy about how good you are as they have been about how bad you are.

Measuring Success: Time to Value and the Emotion Behind the Need

Okay. So, and I'm going through a bit of a journey here of rolling out a new service offering, if you haven't picked up on that already. The next thing, around measuring success, I want to talk a little bit around, we're rolling something out, we've got the buy-in from everyone, we all think it's a great idea, but how should we be tracking that success to make sure we're actually hitting those goals? Ryan, there's traditional ROI and whatnot, which is sometimes difficult.

And I did say this on stage a couple of years ago, that on projects you'll start seeing it, and I think you should be starting to add it to the vernacular, the time to value. If I implement this, when is the first time I'm going to start seeing value for it? It's not just an ROI. An ROI is a rear-vision 3, 6 months, 2 years, 5 years after a project, that's where you actually really review an ROI. It's really hard to review and show an ROI 3 weeks into a project, or 30 days into a project, but you can show time to value. This is where you'll be in 30 days, or in one month, this is where you'll be in 3 months, and this will be the impact to your business. So I think if you can show time to value, that is often another good way of how you get through objection handling about, oh, this project's going to cost how much and it's going to take how long? And it's like, yes, but if you start seeing value from this within the first 90 or 30 days, and then in 90 days, then, oh, okay, well, we're going to start saving time, we're going to start being better in these other areas, or we're going to be more competitive in these other areas. That makes a big difference.

And then the ROI is the discussion after, well after the project's completed, when you do a project debrief, and then, okay, did it actually achieve the expected results as well? It's not just a straight ROI. What did we learn? What worked well for the customer, what didn't work well for the customer? Are they achieving the expected outcomes? And there's also an opportunity. What else could you do next? That might have just been version one, and you've got now better ideas that you've learned, and okay, we can take this so much further now. That's an opportunity.

Yeah. I think when you go into product planning, the product or service that you're delivering is addressing a customer need, and behind that need is often an emotion attached. So if they're looking for a new IT support company because their current one is too slow, the emotions that they're feeling are frustration, anger, they're feeling distrustful, maybe a lack of control, they don't know what they've got, why they've got it, etc. Whatever the product or service is that you're designing, what customer need is that addressing? What's the emotion behind it that they're feeling? And when you start to get into that nitty-gritty, then you start to get into some really powerful marketing information. Because once you know what those emotions are that you're addressing, you can craft your messaging around it to meet what the customers are looking for. They'll see your item, be like, oh, yes, I do want easy IT, I can just call and they'll fix my life for me. And I think the same when you're looking at ROI, going back to your original, why are we doing this product? Yes, we are fixing that, our clients aren't feeling frustrated, because we've addressed that need. Yes, they're no longer unclear, and we've given them a sense of control over their IT, because we're giving them transparency across XYZ. I think all the figures are really important, as Ryan said, the traditional methods of ROI, they're important to look at. You want to make sure you're profitable, you're gaining revenue from whatever you're selling, but you want to make sure it's resonating with the people that are buying it too. And it's not just the success of that product. It comes to your entire brand as well, and how people are feeling about it. If your product that you've launched is addressing some really great things for them, then your brand gets uplifted in their eyes, and they're going to start becoming referrers, and they might leave you some good Google reviews, or those kinds of things.

Yeah. Okay. I actually love that. And Luke's in the chat, Luke Bragg, has just said, people buy on emotion and justify with logic. And so in that product planning stage, really early on, trying to address that customer need, identify what it is and those emotions. I think that's great. I can almost see the template in my head.

So we're nearly at time. What are your final bits of hard-earned wisdom when it comes to rolling out a new service offering? And this can be a story, it can be secondhand knowledge. What's something that you've seen that just didn't work, and that you would do differently?

Well, before you added the last bit on the end, I was about to say, be willing to make mistakes, as long as they're not catastrophic mistakes, or deleting customer data mistakes, or things like that. Be willing to, again, iterate. You're never going to make the first version perfect, but progress, again, progress rather than perfection. Get something out there, start playing with it, start testing with it. Software dev, anything, support, a new product offering, a new solution offering, whatever. They all go through the same process. It's just how complex and how many steps are in it a lot of times. That's probably the answer to the first bit. Meg, have you got anything to add on there? Otherwise, then we can go into the second bit you just asked.

I think the only thing I would add is that, in tech, we are so fortunate to be in an industry that is always evolving and changing. Tech is changing weekly. We see new apps being released, new exciting tools that we can use, and it's such a privilege to be in the age where AI is coming out and to see what that's going to look like for us. Hopefully not taking over the world. Yeah, I think humans are afraid of change, and that's evident too in client conversations. But yeah, I think we need to lean into that, and we need to continuously be evolving and staying on top of these market trends, and listening to what people are talking about, so we don't fall behind. Traditional IT support and cybersecurity are important, but are they going to be what's important tomorrow? Or is it going to be more around AI or something else? I don't know. But you need to keep your ear to the ground, look at the trends, and don't be afraid to try the new stuff that's coming out. I don't have a super spectacular example of a poor product rollout, as such. I've got some that haven't gone that well, but they weren't catastrophic. And I would say too dramatic in my wording, but they didn't go well. Probably definitely catastrophic ones, but we just, not many people want to talk about them, or have held those feelings down and got rid of them.

Yeah. Please, Ben, don't bring that back up.

That's right. I think the ones that I've seen that have struggled have been when not all the right people have been in the room, and marketing's been left out to the last minute, and like, oh, we need to market this new product we've developed. Oh, okay. But have we thought about what the customer actually needs, or all this other stuff that probably should have been thought about at the beginning? We've talked about it a lot today, but that's probably the only thing that I've really seen has made product launches go wrong, is not all the right people were in the room from the very beginning.

Definitely. And on the back of that, I'd say just not having things scoped out well, or no clear definition of success very clearly defined. What is success between you and the partner, you and the customer, you and whoever? What does success look like? And is that achievable before you even start it? Is that success achievable? Start there. And if it's not, then you're never going to hit it. It's what's the swing, the different versions of the swing that the engineers deliver, and then the horse image, that's the meme of what the customers wanted, what someone could deliver, and then what they actually paid for. There's plenty of examples out there. It's more just making sure that you're very clear on what that success looks like, and can you achieve that, and are you capable of it, or you have the skills or availability. If you're not capable of doing it yourself, that's fine, but you have access to the people who can deliver it.

Yeah. Guys, well, thank you, firstly, for imparting that wisdom. I've certainly, as always, I love these, because I get lots of ideas and notes. And I can see my team, actually, in my Slack at the moment, they are currently creating "Cuddle the Chaos" memes. So I'll have to share some of those later, the friendly ones. Anyway, but guys, thank you for sharing your bits of wisdom. Very insightful. I really enjoyed that.

Our next one coming up, and I'll just share my screen very quickly, and it kind of relates to that catastrophic product launch maybe, but it is around creating a culture that performs and stress management for MSPs, right? It's a topic that we talked about probably about a year and a half ago now, and we're going to revisit it. We talked about it just coming out of COVID, but it's a topic that at Hosted Network we try and talk about regularly, around mental health. So please feel free to join us then. We've got a tentative date of September the 3rd. As always, it will be recorded and added to mspsinconversation.com. So if you can't join us, feel free to check that out. Meg, Ryan, thank you so much. I appreciate your time, and thank you for all of your wisdom, and thank you to everyone for joining us today.