Systematic service development process

One of the hot topics in the bootcamp was a typical MSP issue - managing client agreements. The problem gets verbalized in different ways: "I have many new services I would like to sell to existing clients" or "I have to re-onboard all of our customers because the agreement is very old" or "I want to increase our prices to reflect the improvements and additional tools we introduced" or "I barely make any money and I need to renegotiate our prices". Sound familiar? We’d like to introduce a systematic approach to solve this problem for now and the future.

What is the real underlying problem

The original problem is nothing more complex than the ad-hoc and un-managed service development process period. As a service company you spend a whole lot of time developing your services. All internal processes are service development, all tool deployments are service development, all new vendors are service development...meaning everything you do that isn’t providing a service to a client is you developing your services. If you do that without any control mechanisms the result will be misalignment with clients.

We all know that service development doesn’t happen without reason. The technology is always changing, the market needs new services, old services become obsolete, clients come and go, and new opportunities arise. As a managed service provider, a plethora of moving parts to deal with can result in less profitability, under-utilized services and obsolete agreements. The usual solution is to spend more facetime with clients and explain, negotiate, present, and discuss with the owners or account management team why you need to re-align. Sometimes, however, we need to manipulate prices, introduce new services or otherwise change the set agreements.

Solving these symptoms requires identifying the root problem: make the service development, deployment and communication a conscious effort.

Differentiate yourself from your competition and

become sales ready in 30 days

Service Development and Deployment Process

Without going deep into details, let's go through the process quickly. It’s surprisingly simpler than we’ve found most people fear. This is because of the closely related industry with which we face this challenge: software companies. We don’t have to do much more than understand how they’re solving this problem, and apply the practices.

1. Roadmap: Software developers have an internal bible called The Roadmap. This document lists out all the changes they have to make in their tool - new features, updates, fixes, internal processes, and everything else. That roadmap is a central element of their efforts, and the majority of their team is guided by that document.
2. Agile development: the gist of being agile is not to execute long term plans, but get the most important items from the roadmap and ship a version of them early. That helps get to the endpoint step by step, while giving the customers tangible value along the way. It also helps focus the development effort with (typically) understaffed teams.
3. Beta: Sometimes developers will ask you to participate in beta programs, where you get access to improved features faster (and take on the risk of reliability), and they can test out the user experience and further develop the product, validate their ideas, fine tune processes and the optimize the user experience.
4. Release: As a software user, and even more so, a cloud application user, you know that applications are changing all the time...not minute by minute while you’re using them, but by release cycles. The development team develops new features, new modules, enhance the UI, etc, and you get it as a package in the new release.
5. Upgrade: Sometimes it turns out that the function you just started to use is going to be an add-on or in a higher-priced tier. You still can use the product in the beta period, but you might have a decision to make whether you want to upgrade to enjoy the new features.

To summarize:

• They have a conscious effort to develop their products and services
• There is a guiding document for everyone to be in focus
• There is a mechanism (releases) to deploy and communicate changes with customers
• There is a mechanism (beta) to engage users with the new experience
• There is a mechanism to redefine the offering, giving the customer the option to stay on the current plan or upgrade

So let's put these basic principles into play as an MSP

1. Roadmap: as an MSP you need to have a guiding document listing out all the changes you want to make with your services. Internal process fixes, new tools, new processes, new services - everything related to your services. As you plan your development activities the roadmap helps your team to stay flexible while keeping priorities clear.
2. Agile development: based on your roadmap you pick the most important developments, selecting what matters most, instead of scrambling to deal with everything on the board. Every week you can have a development meeting and focus your efforts on specific internal processes, your customer interfacing or implementing certain features of vendor applications. That gives your team focus and a sense of accomplishment as opposed to the futility of firefighting on internal projects.
3. Beta: you might pick specific clients to enjoy the benefits of new services. You can introduce vCIO, Technical Account Management, Application management or even security services to your clients as a beta program. The process helps you to get their consent of the experiment (and also lets them know development is progressing) and you can offer these new services or updated experiences for free for a while.
4. Release: the main thing to consider in release cycles is to minimize internal stress and enhance communication. You can batch many items together and send a quarterly email, letter or a complete webinar to let all clients know about changes being made, and how they affect them. If you provide Account Management, the Quarterly Business Review (QBRs) are perfectly suited to presenting innovations to customers.
5. Upgrade: let's assume you made four quarterly updates on your services during the year. You communicated well what’s beta, what’s sustainable fixes, upgrades (which will be part of their current plan) and what are going to be new service line items (extra charge). Typically once a year you can repackage your offering to include all new services to the current packages and also display the add-ons and features they can access if they upgrade. This method of repackaging means only those clients will enjoy the new features and benefits who upgrade. This will be their decision.

Benefits

• proactive process gives you control over your services to make sure clients are seeing the value of your developments and progress
• the roadmap can give you peace of mind, clarifying where to develop, and helping allocate the necessary resources to streamline development
• agile development gives the team clarity - a process for working on your company instead of for your company - crucial to your ability to scale
• the beta can help you develop services with clients without incurring the pitfalls of nascent services
• releases help you communicate changes very effectively without creating confusion
• upgrades help you restate your value proposition every year, set expectations and give your clients a sense of progress and choice