Matching Solutions to Use Cases
The right tool for the right job…
I was recently reminded on the phrase “If you want to go fast, go alone. If you want to go far, go together.” I was having a conversation with a colleague about creating SKUs and we got into a healthy debate.
The origin of the discussion was around whether you can win more business by building SKUs mapped to very specific use cases. That one wasn’t much of a debate - we landed on “yes, if it’s worth it.” That was really the crux of the issue - HOW MUCH MORE can you win? Partners - in any program, Microsoft, Google, AWS… any ISV - have long been asked to take services and fold them into their existing practice. That, or take a set of SKUs/services from different providers and wrap services around them to form a compelling, managed solution that’s differentiated from the market.
A variety of hyperscaler machine/disk sizes to mix and match as you please
Years and years ago, our Finance department pushed back against creating custom SKUs just for one Partner. Their argument was that every SKU required some level of management, and the more you had the more likely you were to end up with an error. That, and the only way to prevent their specific naming conventions would be to make an entirely different price book for them. Did we even understand how many hours went into that!?
Eventually, our service provider mentality won out and we created a whole new set of SKUs for them. This time, the names were specifically mapped to use cases. The trick was, 90% of their customer base used a mix of the same app stack. Different combinations, but the fundamentals were all the same. The result? We had at least 6 or 7 SKUs for the exact same result - a VM with 2 CPU, 8 GB of RAM and some combination of disk space. Each one was named <App Name> Server, and while it was a TON of work to set up, the Partner’s Sales reps and SE’s had an absolute breeze quoting and closing business - the majority of which was without our interaction.
Was it worth it? Yes, in this case it was. Was it a risk? Also yes… but it sometimes growth is measured by risk * elbow grease.
A real balancing act…
We ultimately landed the discussion at a modern version of the same question. Spot PC has GPU accelerated hosted desktop SKUs, so the updated conversation was around mapping SKUs to use cases. Should we have a “Hosted AutoCAD” SKU and a “Hosted Solidworks” SKU to go alongside a standard “Hosted GPU Desktop” SKU? Tough question, given that the number of possible applications and compute requirements vary more than the app stack that one Partner did a few years back.
That’s proof that scale matters! Microsoft, Google and Amazon don’t do this - no single Partner has their own dedicated price book/rate card. Why, you ask? The sheer volume of asks would be so enormous that it would be completely unmanageable. So again, another risk/reward scenario. If Partners don’t get custom SKUs, so be it - the investment level is there to the point where MSPs can take the base VM SKUs and Managed Disk SKUs are enough to build custom solutions around. Similarly, ISV PMs can build a pricing strategy around PaaS services, API plans, containers & microservices, etc…
A shining example of how this discussion - when the time comes, should Microsoft build Windows 365 SKUs for GPU accelerated desktops, or a named SKU for each of the top 10 GPU accelerated apps (even if they are the same set of compute resources behind the scenes)?
By the way, we never landed on a definitive answer in our lively debate so let me know what you think on Twitter!