Teach customers your software implementation methodology

AImage by Tumisu from Pixabaydd caption

Every single one of our customers needs to learn a new way of working as a result of purchasing our software. After all, the products we sell and support were built to change the way teams in organization work. Why build a product otherwise? 
The point is to say to the market, “This thing we have is better than what you have. It will help you do something new, make more money, save money, or otherwise do something more efficiently. Our product will take you from your current lowly state of existence to a new happy place.”
OK. Great. Our sales and marketing worked, and a customer bought our product. But just because we promised this obviously massive improvement in their lives, it does not mean customers are ready to starting working in this new way.
For one, software implementations are hard. In the book, Consumption Economics, only one in seven software implementation projects are considered a success. Therefore, customer need help rolling out your software. 
Second, change is hard. Your software promises a new way of working, and getting customers to learn, know, and live the new way is hard. They need help with that, too.

“Change is great. You go first.

Large customers can afford to pay for hands-on professional services engagements, so it’s an easy decision to throw experts at that. It is not so easy to take this approach with medium sized customers. Professional services economics does not support it.
The way around this is to teach your small and medium-sized customers to fish. Create education experiences that teach customers your rollout methodology and the process methodology for working in the new way your product promises.
I call this methodology training, and I believe software companies have two methodologies:
  1. Implementation methodology
  2. Process methodology
You need to educate customers on both. Let’s discuss each.
Implementation methodology
If we have any worry at all about a failed rollout, we cannot afford to leave it to chance that customers will roll it out successfully. We can (and should) offer professional services and help customers with their rollout, but this is an expensive approach. 
Large customers will pay for this. Small and medium-sized customers will not. We cannot rely on professional services to help our smaller customers yet we cannot just send smaller customers to a knowledge base. 
If we offer a training course on how to rollout our product, we can, in a scalable and affordable way, enable smaller customers to run their own rollouts. If we teach customers our proven methodology, we increase the likelihood rollouts will be successful.
This isn’t exactly new. It is not uncommon for software companies to publish their rollout methodology. 
Percolate, the content marketing platform company, publishes its software adoption framework that customers can use to create rollout plans. 
Workplace by Facebook has its implementation methodology on their Workplace Customer Resource Center
What you should do is take this approach one step further and create a hands-on education program to each customers apply your rollout methodology.
To learn more about Percolate’s approach to helping customers with adoption, listen to my discussion with Arjun Devgan, then VP of global customer success at Percolate on Helping Sells Radio.
"One of the best ways to "up" the customer experience, is to help them plan ahead for the day they do decided to buy your software. This way, they can hit the ground running. “
  •  Arjun Devgan, then VP of global customer success at Percolate
Process methodology
Another way to look at teaching customers methodology is teaching customers to apply the new, best practices processes that your software is designed for. 
Think of it this way. 
Your software promises some new way of working that will help your customers make more money or save more money or work more efficiently and/or effectively. A new way of working. If this is true, then you should teach your customers how to work in this new way, and not limited to just how to use your product, but how to work in this new way ub a broader sense.
Consider the example of a company that is buying Atlassian's Bitbucket. Bitbucket helps software teams use the git version control methodology to manage and share their software code repository and work better as a team to build and ship software.
Software developers know what version control is. There are many different version control methodologies. Git is one. A new Bitbucket customer may be switching from a legacy version control methodology and is not familiar with git. They see git as a way to improve result so they switch. 
If a customer is new to git AND new to Bitbucket, teaching features is the last thing you want to do.
In a world in which we teach customers features, we could create a training course and teach customers how to submit a pull request (as just one example).
It doesn’t make any sense to show customers how to submit a pull request if your new customers don’t know what git is. A pull request in concept is unique to git.
See the layers?
Think of this in two parts:
  1. The work process of the job. In this case, it is doing version control using git.
  2. The process using your software. In this case, it is doing git using your software.
You could choose either approach or both. For example, you could create education on version control and git, whether the customer uses your software or not. You could create education that teaches customers how to do git version control using Bitbucket, specifically. 
Your customers might be willing to pay for training to learn git from you because you are the leading provider (and therefore expert) in git, and you might want to be known as the git experts. 
The point here is that whether you offer this level of training, many of your customers who buy your software are buying it as a means of implementing a new way of work. You need to decide whether you want to help your customers adopt that new way.
Ask yourself, “What new way of working does our software offer and how can (or should) we help our customers learn that new way of work?"
This is what HubSpot does. HubSpot Academy started off teaching courses on inbound marketing that did not involve using HubSpot. Inbound marketing was a new type of marketing at the time and HubSpot created a new category of marketer who wanted to be an inbound marketer. What is your inbound marketing? Or git. Or agile. Or sales. Or DevOps. Or project management. Or graphic design. Or (fill in your category here ________________________).
The methodology is the product
Maybe what you are really selling is your methodology, and your product is a means for customers to apply your methodology. If this assumption is even remotely true, you should do what you can to teach customers your methodology.

Comments