Press "Enter" to skip to content

How to apply agile to SMB customers


How to apply agile to SMB customers

View this email in your browser


The weekly newsletter of the Business of Tech, giving you new insights into the world of IT service delivery. 

Looking for stories from the podcast stories?  Check out the pod itself on Apple Podcasts, Spotify, or daily in your inbox.   Stories are available to everyone for five days,and Patreon supporters forever.

Was this forwarded to you?  Join the list!






Applying Agile to SMB customers






How are your client relationships going? Are things getting stale? Want to take things up a notch?
It’s been a minute since we focused on the nuances of client work in this newsletter, so I figured it’s a good time to hit pause on the AI convo and zero in on the communication side of things. Plus, a change of seasons is around the corner – if you’ve been meaning to do some soul-searching on the client relations front, perhaps summer will be your time to shine.
I know at least one of you has been mulling this topic over; a listener asked me about Agile development right around the same time I came across an author who’s written on this exact concept: Douglas Squirrel. In fact, Squirrel (yes, that’s his preferred name) even runs an entire community dedicated to the subject. 
Let’s dive into my Business of Tech bonus interview with Squirrel, who has a rather eccentric take on Agility and client relations. If you’ve been looking for something a bit out of the box, his philosophy might get your creative gears turning. 
Squirrel’s POV on Agile Consulting Services
No matter what type of consulting service you deliver, Squirrel’s philosophy is the same:
The ridiculous thing that so many consultants fall into is the idea that you’re going to take a statement of work from somebody, it’s going to list a bunch of different things you should do, and your job is to do that as closely as possible to what they asked for. That’s a total disaster in software. It’s a total disaster in most things. So the trick is to not do what your client wants, but instead to do what they need.”
If you’re the type to talk to a potential new customer, put together a clear proposal with a list of services, and deliver those exact services (as I’m sure 99% of us are), Squirrel wouldn’t consider your methodology to be Agile (don’t shoot the messenger on this one). 
So, where does the magic come in? Squirrel’s special sauce is two-fold: first, build trust with clients by inserting the long-term impact of your services into conversations. In his words:
“I help them to understand how working with me will be not just a path to making your tech team do more of what they do today, but a way to much better profit, maybe a totally different product line, a revolution in what you’re doing.”
Second, once they have trust in your understanding of their needs, you go the flat fee route, but with a high price tag. With the extra padding, you don’t just deliver one service. You address the root of any given problem from as many angles as possible. 
For example (courtesy of Squirrel), if a client asks you to maintain printers and update Windows, you get a conversation going about their reasoning behind the requests. In this example, they might tell you that their call center is flooded with ransomware and phishing and their machines just don’t do well enough to keep up. Now that you opened up that convo, you pivot to offering up security and training. 
The goal here is to seek discoveries your clients might not even think to bring up and jump at the chance to fix them. 
The Larger Scope of Agile Implementation
You might think this sounds like a jazzed-up version of a normal methodology: getting into a client’s space, finding things to do, expanding engagement, and sharing a list of services. I ran this by Squirrel, and his response was clear: “No, no, no. Not the things you’re going to do. No, no, no. That’s the difference.”
Instead, according to Squirrel’s system, you would make a list of the problems they have from a business and revenue perspective. If you were to notice that computer outages are preventing customer service calls, for example, you’d bring this up to the client from a numbers POV:
“We’ll turn into things that my team may actually show up and do, but I’m going to talk about those and charge for them as business outcomes… I’m going to talk about, what value is that? Well, man, if we could take 50% more calls, we could make 50% more sales. Start adding up, you got a lot of zeros.”
So, the goal is to view your service in terms of business outputs, and train the client to view you that way as well. When this gets translated into proposals, Squirrel always brings it back to the business’s bottom line and how his service contributes to that financially. 
Staying Agile During Engagement 
If you generally err on the side of caution when it comes to the scope of services, this might sound a bit too loose-ended for you. After all, you can promise a client one thing, then have to pivot entirely when the conditions on the ground inevitably change. If you’re thinking in terms of financial output on behalf of your client, this can be an especially slippery slope. 
I asked Squirrel how he navigates the unexpected while staying engaged with customers, and he remained steadfast in his focus on the long-term business outcome. He would let the client’s point of contact know that they’re changing course, then simply change course. If they thought malware would do the trick, but they actually need to fix the network, he wouldn’t haggle. He would just do it. 
And, get this – he wouldn’t charge more for an unplanned service. He charges a very high flat fee, then does whatever he needs to within that retainer.
To pull this off, Squirrel also noted that you need hyper-vigilant, energetic staff. He has to trust his people to execute just about anything. 
Finally, I confirmed with Squirrel that this methodology really can work for any sized organization. And, in his belief, it can scale down to any individual provider and any individual client. 
I’ll leave it on this final quote, which was the inception of his Agile philosophy:
“Maybe it would be a good idea if we talked to some customers and if we didn’t make a plan that showed everything we’re going to do for the next year, but we actually listened to those customers and built what they needed.” 

I’ve spoken in the past about how the role of the MSP is evolving from a straightforward provider to a strategic business partner. Squirrel is definitely the type of tech person embracing this role with glee – even if you aren’t quite aligned with his style, there’s something to be said for that level of adaptation. 
To learn more about Squirrel’s Agile methodology, head to As always, I’d love to hear your feedback – send your thoughts along to [email protected]

More from MSP Radio


Missed Things? 

How about our latest videos to catch you up? 

The Daily Podcast available as videos

How AI is different and how to link value in digital transformation with Kamales Lardi

AI and security use cases with Cemtrex CEO Saagar Govil

Preparing businesses for the impact of AI with Dr Yossi Sheffi

How will AI change an industry? Andy Wilson dives into legal


Want the Daily News?   

All the stories from the daily Business of Tech Podcast are available in the daily digest, and stories are available to everyone for the first five days, and Patreon supporters forever.  Catch the audio of the show anytime on Apple Podcasts, Spotify, YouTube, or wherever you find podcasts.  Links at


Copyright © 2023 MSP Radio, All rights reserved.

Want to change how you receive these emails?
You can update your preferences or unsubscribe from this list.