When your customers say your training is ineffective or you see from reports that product use does not increase following an education intervention, one of the questions you should ask yourself is, "Are we helping customers understand the context for why our product exists and why they need to learn it?" One major problem with software education is that it is focused primarily on helping people learn features. Learning features without understanding basic concepts and without understanding "why" will often leave people bewildered about how to use the software.
Customer are left to think to themselves, "Why are we doing this?" And this is a distraction in your courses that you do not need. It is very often the case that the people in your training course were not involved in the decision to purchase your product, and in some cases, might have only heard that your product was purchased the day they were told to join your class.
If you focus primarily on teaching features, your course will be ineffective at best, and a complete failure at worst.
Purpose matters. Even in software education
Have you heard the parable of the three stonecutters? If not, you should read it. The story reminds me of a release engineer friend of mine who told me it took him five years to realize his job was not to ship the best, problem-free releases possible (which of course was his job). He came to understand that his job was to help his company deliver the best possible website experience to help grow the business. In other words, there is a higher purpose to the work. And from understanding the higher purpose of work, comes motivation.
Customer education teams need to think about how they help customers understand this higher purpose, if you want to deliver the most effective education possible that helps a customer achieve some desired outcome. This process does seem daunting. After all, isn't it the customer's job to motivate "their" employees and to help "their" employees understand "their" higher purpose?
Yes. It is.
But if you are in the business of helping customers learn and use your product so that they achieve some desired outcomes and then continue to subscribe to your software product, then it is your job, too.
Don't worry, there is a simple way to look at this problem that will help you change how to design customer education programs. Have a look at the image below. It shows four levels of understanding that your courses should address.
Each is explained.
When you teach a feature, you are showing someone how it works. This is important because if someone does not know how to use a feature, they cannot perform a certain action. Take the example of a pull request feature in a version control system. A pull request allows software developers to get other members of the team to review the code they have written. "Great," a developer thinks, "How do I do that?"
Your training can describe how to create the pull request (Click the Create button...), how to ask specific people to review it (Mention people, like this...), how to describe your request in the description so reviewers know specifically what you are asking them to review (Leave a comment, create a numbered list, click submit, like this...), and even show you how to get alerts, read the reviews from the people who responded to your request (Click subscribe to notifications, here...).
All of this, and perhaps more, needs to be learned.
Some people may ask themselves, as you are steamrolling through each tab of the pull request screen, "What is going on here? How does this relate to my job. I already get people to review my code. I don't need a tool for this? I just email it to the people I want to review it and they send me feedback."
The problem here is that no context has been set. The learner does not understand the concept of a pull request as your product is designed. You just started showing them how to do a pull request.
And what if the feature changes?
Your courses need to address concepts. First of all, every course needs a diagram that explains the concept taught in that course. A concept is a higher level description of a feature that ignores specific functions. Features change often. Concepts do not. So the more of your courses focus on concepts, the less often you need to update the content in your course.
Let's continue the example of a pull request.
The concept of a pull request is to let you tell others about changes you have made to the code repository, ask for team members to review your code, and collaborate around improving it. An entire section of a course could be designed to explain this concept, how a team might work together applying this concepts, and even how a manager can build a team and processes to implement the process.
There are many angles a learning designer can take.
The point is to teach the concept of a pull request, without specifically teaching features in a product, which could vary by product and change quickly and often.
The better one understands a concept, the less time one needs to spend learning features.
Now that a learner understands the concept of a pull request, can we assume they understand the purpose of it? As we rise to the next level of teaching, we begin to link how people use software to the reasons why they are using the software in the first place. Very few software training courses address this. And that needs to change because if people do not understand why they are doing something, they are much less motivated to do it well or to otherwise stick to it through the boring parts.
What is the purpose of a pull request?
There are many levels to this, and the learning designer will need to make some choices about how far to go with it. For example, the following is a list of possible purposes of a pull request:
- Improve team collaboration: a process in place to facilitate peer reviews around their work.
- Professional development: software developers learn from each other by receiving feedback, giving feedback; and discussing why a piece of code was written a certain way, how it can be written in a different way, and how it will impact the rest of the code.
- Improve software quality: Reduce bugs and minimize repetitive fixes by the QA team.
- Minimize bottlenecks: Managers are not reviewing each team members code.
- Scalability: Better handle complexity of a software team as it grows.
- Increase velocity: Speed up release cycles and ship products faster.
You could likely think of more. The point is to help your learners understand the purpose of using pull requests.
The difference between purpose and outcome is in the numbers. The outcome of a pull request could be that a quality rule is implemented that requires all new code to be reviewed by three peers before it can be added to the project. An outcome could be to increase sales conversions on the website by five million dollars in Q2 because a team implemented a new version control process and can now ship higher quality code changes more often.
Your training courses should address the ultimate outcome that the organization desires as a result of purchasing and using the software that the team is learning.
It is your job to motivate and educate
The question is not which of these levels your training should address. You should included all four in all of your courses. Not in equal proportions, and it depends on your audience and the goals of each course, but to some degree, you should address each of these levels in each of your courses. If you do, customer motivation will rise, and so will the effectiveness of your courses.
Design courses in a more predictable way
If you are in the process of developing courses, whether for live or self-paced training, you may want to use a repeatable process for how to create courses in the most effective way possible. We wrote a guide to help simplify the process of developing courses. This guide, Ad Hoc Hell: A ServiceRocket Guide to Developing Your First Software Training Course, is a practical guide to developing training courses, no matter what method you use. This guide will help you develop better courses in less time. Download it now.