This is the seventh post in this series, if you’ve not read the first post I’d recommend you skim it first for context. As a reminder, here is what I’m covering in this series:
- What is an MSP? – Covered in post 1
- TAM/SAM – Covered in post 1
- Economics of an MSP and their customers – Covered in post 2
- Personas – Covered in post 2
- Vertical analysis – Covered in post 2
- Share of Wallet – Covered in post 2
- The assisted sale – Covered post 3
- Product Penetration Scale – Covered post 3
- Financial Modelling – Covered in post 3
- SaaS metrics – Covered in post 3
- Commercial agreements/billing – Covered in post 4
- Research, Analysts, consultants and forums – Covered in post 5
- Marketing and Shows – Covered in post 5
- RMM’s, PSA’s and integrations – Covered in post 6
- Product capabilities and principles – Covered in this post
- ‘MSP team’ investment requirements
- Activity maps and company strategy
- Product management best practices
Product Capabilities and Principles
If you have followed this series so far, you will have all the key information about how and if you should enter the MSP space as a vendor, all this is irrelevant if you do not have “Product-Market Fit” (PMF).
Here I’ll briefly cover the most important aspect of any successful go-to-market, the Product, and what are some rules to adhere to when working with MSP’s.
Product Principles
For the majority of my career, I’ve worked within invisible boundaries of how the Products I’ve managed should be built and used. In the last 8 or so years, I’ve formalised these into visible Product Principles which have been used to align and inspire our internal teams, as well as reinforce our customers/market of who we are and what makes us different.
Product principles are a critical component of an organisation and go well beyond high-level buzzwords, but should be part of the design of your products and how you as a company engage with your customers.
When working with MSP’s, there are a few product principles that I believe should be common in all vendors targeting this space.
Here are a few generic examples with context, your’s should include service/use case specific principles in your list:
- No barrier to support
- Never put a paywall between you and your customers when it comes to supporting them with issues or queries
- Have quality support and SE’s on hand – don’t skimp on these resources!
- Paid professional service should not be a thing if you’ve built your product properly
- Business-friendly to MSP’s
- A little vague, but essentially you must align with the way the MSP does business from a contract and billing perspective, I’ve covered this in-depth in the billing methodology post
- Clearly Prove Efficacy and Display Value
- This includes the general reporting capabilities and the overall ROI of your service (see the “Three golden rules” later in this post)
- You must be able to easily articulate and prove the value of your service to the MSP’s business and the MSP’s client
- Your solution has to do what you say it does, proving this varies in difficulty depending on your service. I could write a book on cybersecurity testing and the tricks the industry as a whole does to try and get 100% on 3rd party tests, but you should concentrate on showing contextual efficacy to your customers, focus on the things that impact your customers and prove that you solve them
- Enterprise-level capabilities built with a Consumer-level UX
- Maybe Consumer-level UX is a bit too far, but the bar needs to be set high
- This has been the hardest to attain over the years as I’ve lived in the complex world of cybersecurity. It is easy to build a solution where you let the customer decide what they wish to do with all the events that occur or confront them with a myriad of configurations possible, but in the world of SMB and MSP, they rely on you to make these decisions for them and only show them what they need to see and configure as much as possible out-of-the-box
- The user experience to onboard onto your product should not require more than three steps to get deployed and active and certainly no professional service from you! You won’t scale if you have anything manual
- Lastly, MSP’s like to think they are using enterprise-grade technologies, although they certainly don’t have the budget or expertise to manage them. Showing that you have the depth of solution but without the overheads associated with managing it is worth its weight in gold!
What about “Strategic Principles” beyond Product? A future post brings this all together when discussing strategy and Activity maps…
Product Capabilities
The Product Principles help frame the key pillars of your solution, double-click into this and there is a bunch of capabilities your product should have, but you’ll be the experts in these as you’ve completed your discovery and interview process with MSP’s. Here are a few key attributes I know MSP’s look for:
- Lightweight service
- Low impact on customer’s network/device/users
- The last thing MSP’s need is their clients complaining about your service getting in the way of their business
- I once asked a forum of large MSP’s during an Advisory Board session whether they would choose performance (system impact) over efficacy when discussing a new cyber security feature which may cause device impact, the answer was shocking to me at the time as most voted for performance! MSP’s are very sensitive to this!!
- Easy to provision and deploy/activate
- A maximum of three easy self-service steps:
- Registration – capture this is a single form, you can always go back and get more data once active, but don’t make this cumbersome, remember you’ll need to support this in your provisioning API via the PSA
- Simple config selection – depending on your service, you should have a default configuration and a selection of best practice configs. Again, your provisioning API needs to handle this
- Install/activate – Whether a software agent installation or an authentication binding/SSO you should make this extremely easy. For software, don’t build your own deployment tool, just build RMM scripts to automatically deploy your software once provisioned, this gets you near to maximum deployment numbers
- A maximum of three easy self-service steps:
- Open APIs for integration – reporting and provisioning
- One thing I’ve learnt is that you can never win with canned reports, customers always want a slight variation to what you may serve them, unless you have built or licensed a fully flexible reporting engine, you should give the customer the data in the raw format so they can fill their boots. I’m not advocating you ditch your canned reports as you’ll still need to give good reporting examples of your service, just augment them with an API (and direct download) to pull all the data
- This is also a requirement for the provisioning of your service, working with PSAs and RMMs, you will need to allow a 3rd party to provision your service so they can view operate your service in their “single pane of glass”– more on this in the last post about integrations
- Cloud-based & Multi-tenant
- Very few exceptions to this these days, I’ve end-of-life’d a bunch of on-prem solutions in the last few years and with barely a whisper from customers/prospects
- The multi-tenancy is primarily for internal benefits as you understand the nature of the MSP’s business and their clients, as I touched on in the economics of the MSP post
In addition to the above, there are three golden rules to operating your service which I think should be ubiquitous across all solutions serving the MSP’s, in fact, this applies to all B2B customers!:
Rule no.1 – Show them it’s active
- Your product dashboard should clearly show if the service is operational, may sound simple but have you considered:
- Are your installed device agents/users checking in regularly?
- Is your backend/cloud experiencing any issues/downtimes?
- Are integrations active?
- Has the service expired for any of the MSP’s customers?
- Customers want the “warm and fuzzies” that your service is set up correctly and is ready to do what they are paying you to do. Don’t underestimate the need to reinforce this
Rule no.2 – Show them what you’ve done for them (and their customers)
- Your customers should easily be able to see historic information about all the great things you’ve automatically done for them whilst they’ve been busy with other things
- Succinct ROI and value reporting should welcome the customer, again, reinforcing that the service is working and quantifying this with data from your service for the MSP so they can share with their clients
Rule no.3 – Show them what they need to do
- Your goal whilst serving the MSP is to automate as much as possible to save the MSP time and money, however, your service may not be able to do this all automatically, for example when a backup restoration on a server has failed or a customer site goes down due to network issues.
- In these cases, you need to triage this for the customer so they can clearly understand what is going to need human intervention
- This needs to be front and centre for the MSP and you must clearly state what actions required and be sure to clear the alert once resolved – otherwise, this is all just noise to them
These three rules apply to your integrations too. Whatever your service shows directly you should provide to the RMM or PSA, but don’t go too deep in the integrations. Have the bare minimum available so they can click through into your product to see the more verbose information, this is because maintaining code in integrations is hard enough, duplicating your service consoles in an RMM or PSA will set yourself up for a fall.
Also, if all your service capabilities are duplicated in the RMM/PSA you lose brand awareness and are a prisoner to the RMM/PSA’s roadmap – which will impact churn rates.
Over the years it is amazing how many services fall short of these Principles/Capabilities/Rules in the MSP market. Look at your products and see how you stack up!
