One of the most under-appreciated success factors of an MSP is its capacity to develop services. We’re the purveyors of Managed Services; there are hundreds in the repertoire of any given MSP. This keeps us busy - going from concept to a product that can be sold and delivered is a long road. While product based companies have a process for product development, we service companies too often overlook the value in this powerful business practice, where all our innovation, differentiation, profitability and growth can be formulated in advance.
The trend of fragmentation in services - into verticals, delivery tools, integrations - just multiplies the need for planned process.
The usual development process for managed services providers is to do a project - develop something that solves a problem for (and with) a specific client and standardize it later. This can lead to long term future revenue, but without a clear process mixing up service development and the real revenue generating activity of the company will not only kill our internal productivity, but likely our relationship with the client, if everything they see is always in beta testing.
Let’s identify some basics to ensure our process is better than the average and pull ahead of the competition.
1. Value Proposition
The first important aspect of the service development process is the proper Value Proposition. We’re always ready to sell gadgets, tools and things we can use to solve something. Finding the problem it can solve usually comes second - “Hey, we have a Mobile Device Management feature in the RMM tool! Great, let’s sell it to clients.”
This is the approach of the average and uninspired MSP. If we instead use the Value Proposition Canvas, we start by understanding the client’s problem before designing the service itself.
We seek to discover things the client wants to get done, the obstacles in their way, and the results or gains they hope to get. This is the right hand side of the canvas. Then we can design the service value proposition on the left to solve the problems and the deliver their requested results. We build a bridge connecting their issues with the benefits of our services. Lastly we craft the service description itself.
Let’s see a Value Proposition canvas for the Slack and vCIO services to see how it works in real life. We even have a complete blog post for that one.
In that sense we know in advance precisely the mission of the service - why the client needs that - so if we develop it further all marketing, sales and delivery efforts will be aligned.
Development will also be made more agile. For example we’ll be deploying different maturity versions of the service. The first instance of Mobile Device Management may only cover basic functions like wipe and remote deployment, but later will be covered with BYOD policies and internal compliance.
We may even find we cannot solve the problem, or the problem isn’t actually worth the effort and expense, and we can drop the service development fairly early, so we and the client can both invest our time in better pursuits.
2. Demand Generation
The second step is to create some Demand Generation materials. I know...how can anyone not want to pay for our obvious expertise? We have the skills, but the customer inevitably makes the buying decision. If we can’t explain the service and its benefits clearly, we can’t drive demand and there’s no reason to proceed or invest further.
We have to learn fast, and active materials are best at getting quick feedback on our thoughts. Sending a one pager is not interactive - it won’t have the specifics - which feature is the most important, for example. Graders are great tools for asking questions about the problems clients have with a particular issue and actually measuring our marketing effort, the copy, the delivered benefits and interest.
Demand Generation is part of the Service Development process, not something marketing folks do after we finish. It gives us real-time feedback and clear understanding of what really needs to be solved, a crucial objectivity to the process to make sure we develop the service for the client and not for the engineer.
3. Sales
Pricing and packaging is a big deal for services too.
- Is the service included in an MSP package or stand alone?
- Does the service have tiers, or should we scale it with GB, user, device?
- Does the service has a definitive process such that we can price based on the resources we put into it?
- Is it an open, listed price or customized per proposal?
- Do we sell it directly or through the account manager?
Again this is can’t wait until after the development process; it is part of it. We have to go out and test our assumptions. We can take a little advantage of our “early adopter” companies to go through experiments. We need the clearest understanding possible of all aspects before we scale.
Sell the service to the early adopters without a price tag. The goal is to find out whether they see the value without any price attached. Once we confirm the need we can find the price they will pay for the solution. In this case we can measure the value and the price independently. If the value isn’t compelling it won’t need to proceed to a price conversation. If it is a value, then we specify everything, and then create the perfect solution that both works and fits their actual budget.
To early adopters we can always offer a discount in exchange for their participation. We can get marketing contributions like testimonials, interviews etc. We can ask for contribution - content samples, real life data for presentations, and we for a flexible delivery schedule. We’ll only help ourselves if we state the discount clearly up front.
4. Delivery Processes
The last piece of the service development process is the Delivery Process definition. Usually we don’t consider this part from the beginning, but rather on an ad-hoc basis.
We start services sometimes as one time projects. A client needs something and we bring it to them as a project - making the common mistake of failing to look forward. We do so much to make one individual project come true, when we should treat every project as though it will become a repetitive service, so we generate service delivery process prototypes during our project work.
Therefore we’re going to need a quick service delivery prototyping tool. We’re going to use it to create service processes in real life and be able to reuse the materials later. Many people use Project Management or Process Management planning tools to create a project plan, or a process description. These are good for when we create documentation, but aren’t flexible enough and lack the feedback from real life as discussed above.
The best way is to fire up lightweight project management tools like Basecamp, Asana, Teamwork, etc. These have the flexibility for a prototyping situation (for instance your PSA’s project management is too robust, not flexible, lacks collaboration), and allow testing in the real world. You can open a workspace and quickly input the process deliverable items. Templates, Excels, Word docs, notes, todo lists, and everything else you think you need. As you start working on the project you’ll see a refinement of your efforts. Later of course, as we finish the project we can reverse the process, moving those todos and templates and deploying to a robust professional services automation when our goal is no longer flexibility but performance and efficiency.
Let’s put it together
To recap, create the Value Proposition, and test it internally first with broad (vague) definitions, then move forward with interactive Demand Generation materials to define the ideas more clearly, create Sales materials and scenarios of the Pricing and Packaging, then create agile Service Delivery processes.
We’re going to separate Production from Development. The development folks are going to hand hand off their work to the production team to deliver it. In the case of a small MSP we can at least separate the process virtually, if not physically.
As we need to be developing more and more services it will become harder to keep ahead of the curve without a solid Service Development process. Consider the services you’ve put together already, and how they’ve developed in terms of these four stages. It’s never too late to implement proven techniques.
Submit a comment