On May 22, 2015, I participated in an Ask Me Anything on Inbound.org. The questions focused on how to design enterprise software training and how cloud-based, software-as-a-service (SaaS) companies can use that training to improve outcomes and customer success. There were many great questions from a wide variety of professionals seeking to improve training to help customers get more out of their software.

Among the many questions asked during the AMA, one caught my eye. Isaac Moche asked:

"What are the 3 things you see companies doing wrong when it comes to training their customers online?"

This is a very good question because there are patterns of things that go wrong in software training, which can be made by beginner and experienced designers alike. My initial responses can be found in the AMA, but I liked the question so much, it is worth going into a bit more detail here.

Below are 3 common mistakes made in software training design.

Mistake #1: Too much focus on feature training

I have attended (or reviewed) too many software training courses that launch right into showing features without spending any time talking about what the software is designed to help people accomplish. If truth be told, in the past I have designed a few courses like that myself, much to my personal embarrassment.

So, before features should be covered in any software course, context needs to be addressed about why the software exists, how it is designed, and what is possible with that software. If context is covered well, learning features will be easy. Skip the context and feature training will be lost on many.

What to do instead: When you design a software training course, set it up with the proper context. Address the big picture of what the software is designed to do, and how it will help your learners achieve some outcome.

Mistake #2: Trying to cover everything and not focusing on most important tasks

Another problem with software training is the trap of thinking, "We need to include this, and we need to include that." In other words, there is a common believe that a training course needs to cover everything or otherwise as much as possible. As a course is designed, more and more is added until a course can become way too much for anyone to absorb. Said another way: Scope creep.

Scope creep is a potential problem in any project and training is no different. When we begin designing a training course, we invariably face numerous decisions about whether to include a learning objective. And just like in baseball, the tie goes to the runner. If there is any debate about whether something should be included, we include it for fear of "missing something."

This is a huge mistake.

Before you know it, a one-hour class becomes a two-hour class, but we still need to cram it into one hour. When the class is run, the trainer will need to rush through the course and invariably skip through a lot of content, mostly the exercises and "stuff" at the end. Learners recognize this and are left to wonder what they missed.

One of the most important decisions learning designers can make is to decide what not to put in a training course.

What to do instead: Instead of deciding what extra features to add, follow a guiding principle of sticking only to the essential tasks or outcomes a user needs to accomplish. For example, when you begin to design an introductory course for your product ask yourself, "What are the three essential tasks you want a new users to be able to perform as a result of completing your course?" And nothing else. You have to be disciplined. You have to say "No" to product managers and subject matter experts who will insist that other topics need to be covered. as well. You will need to explain that those other topics will be covered in other classes where learning those topics will be more relevant and useful.

Mistake #3: Starting off with free training and trying to make it a paid offering. Companies should start with free and paid training from the start.

Many software companies begin by offering training for free. After all, training should be a service to help our customers, plus most early stage software companies are so busy building and shipping their product, they have not spent time thinking strategically about training. The logic is sound. But over time, the software company begins to understand that the level of effort required to develop and deliver training is enormous, and that larger customers are willing to pay for training.

When they do decide to start charging for training, it can be a shock to customers who complain "Last year training was free....I won't renew if you charge us."

What to do instead: Before a company decides to offer training "as part of the subscription of the product" it should have a discussion about whether anyone believes training would be a fee service in the future. And make the decision in an informed and strategic way.

Conclusion

I have seen these mistakes frequently, and I assume you have, as well. The value in understanding these three mistakes is being aware of them, so you can take measures to reduce the frequency with which we make them. There will frequently be times when our time is short and we just want to ship a new course quickly. If this occurs, and you fall back on old ways because speed is the priority, relax and say to yourself, "No problem. This is version one of this course. We will make those changes in a future release."

Call for comments

What mistakes have you seen in software training?

What mistakes have you made designing software training?

What was the most effective software training course you ever attended? What made it effective?

Bill Cushard covers the intersection of learning, software adoption, and customer success. His career has focused on helping companies adopt disruptive software through learning, change management, communications, and implementations that help people get the most out the software.

Bill Cushard is also the author of the 2018 book, The Art of Agile Marketing: A Practical Roadmap for Implementing Kanban and Scrum in Jira and Confluence.