Why I Started Untapped Channel Strategy (And the MSP Problem I Kept Seeing)
Thirteen years is a long time to watch the same mistake happen at different companies.
The companies were different sizes. The products were different. The markets were different. But the mistake was the same: leadership would decide MSPs were part of the go-to-market strategy, build a program on their own terms, and then wonder why it wasn't working.
That's what I kept seeing. And it's why I started this practice.
The MSP Side Project Problem
Nobody calls it a side project. The language is always more optimistic than that. "We're building out our MSP motion." "Partners are a key part of our growth strategy." "We want to expand through the channel."
What it looks like in practice is different. The pricing is built for direct sales. The conflict policy protects the direct team. The onboarding assumes the MSP's customers operate like the vendor's direct customers. And leadership measures the program against direct sales benchmarks that don't apply to how MSPs actually go to market.
The result is a program that looks like a channel program but functions like a tax on the MSPs trying to use it.
What MSP Programs Can Actually Do
When a vendor builds an MSP program the right way -- around what MSPs need to deliver outcomes for their customers -- the economics shift completely.
One MSP can bring thirty customers. Fix the program, support the motion, and thirty becomes three hundred. The compounding is different from anything a direct sales team can produce, because you're not selling one customer at a time anymore. You're enabling someone who sells for you at scale.
That requires a completely different program architecture. Different pricing. Different conflict policy. Different support model. Different success metrics. None of it comes from the direct sales playbook.
What Thirteen Years Taught Me
I went to school to be a teacher. That didn't go the direction I expected, but the instinct never left. Every role I've had in channel has been about passing on what I know in a way that actually helps someone make a better decision.
At VMware, the work that mattered most wasn't the program -- it was breaking the program. A major partner relationship didn't fit any existing framework. Making it work required building something new from scratch, and that process generated tens of millions in partner-sourced revenue annually over seven years. At Apple, the MSP program needed a full rebuild. Different company, same core problem: the existing motion wasn't built for how MSPs actually operate.
Thirteen years of that. Big companies, small ones, programs that scaled and programs that didn't. What I kept noticing was that the vendors who struggled weren't short on ambition. They were short on someone who had been through the failure modes before.
Why I Started This Practice
There are CEOs sitting with a real opportunity in front of them who can't figure out why the program isn't moving. They're watching their quarterly numbers. They're thinking about their investors. They're wondering if they're making the right call for the long-term health of the company.
The answer is usually not complicated. The program is broken in a specific way, for a specific reason, and fixing it doesn't require a full-time hire or a two-year transformation. It requires someone who has seen it before and can move quickly.
That's the practice. Not a framework. Not a playbook to hand off. A working engagement where we figure out what's actually broken and fix it -- inside your environment, on your timeline.
If your program was designed using a VAR playbook, that's often the root cause. I wrote about the specific failure points in Why VAR Playbooks Fail MSPs.
If you want to know where your program stands before we talk, the MSP Channel Readiness Assessment takes about ten minutes.