Let’s say we’re designing a course that will help widget sales people overcome buyers’ objections. The objection we’re focusing on right now is this one: “I’ve read that your widget creates a lot of heat.” We have a specific way we’d like our sales people to respond to that objection.
Some people in our audience are familiar with the concerns about heat, while new people might not know as much.
How do you think most training designers would approach this? I think they’d do it like this.
The designers would think, “First, we’ll tell them the common concerns about heat, to make sure everyone knows them. Then we’ll tell them what our own research shows about the heat and why it’s not a big deal. Then we’ll tell them how to respond to heat objections, and finally we’ll let them practice with a scenario.”
Why did I label this “boring and inefficient?”
- The learners have to trudge through many screens before they finally get to use their brains.
- Some people already know the stuff presented on the many screens.
- The how-to info is presented immediately before the scenario, making the scenario a simple check of short-term memory.
Here’s a more efficient approach that has the added advantage of helping people learn by doing.
We immediately plunge learners into a realistic scenario — followed by another and another. Then we concisely recap what they’ve figured out through the scenarios.
The material feels like a stream of activities, not pages of information followed by one lonely memory check. The recap will be memorable and concise because it refers back to concrete examples, such as, “As you saw with Ravi’s objection, it’s best to …”
But what about the information?
We can include the information about heat issues as optional links in the scenario.
Now our material is more efficient and a heck of a lot more interesting. People who already know all about the heat issues (or, importantly, think they know) will forge ahead without reading the optional documents. Newer or more careful people will check the documents to make sure they know what’s going on. Both groups will figure out if they chose correctly when they see the results of their choices.
In addition, the optional documents are low-tech PDFs or pages on the intranet, the same documents that people use on the job. This makes the information much easier to update and puts the scenario in a more realistic context.
But they might just guess and miss important information!
The usual argument for the boring and inefficient approach is, “We have to make sure everyone is exposed to the information.” But who cares whether they’ve been exposed to it? What we care about is whether they know it and can apply it.
So we’ll design scenarios that make them prove they know it, and we’ll design enough challenging scenarios about the same important information to make sure no one is slipping through the cracks. And if we’re really worried about information being missed, we can include it in the feedback, as shown in this post.
For some research support for this approach, see Throw them in the deep end.
But you didn’t show them how to overcome objections!
We haven’t led them by the nose through the Heat Objection Handling Process because we want them to figure it out through experience. Our feedback will help. For example, if someone chooses option C above, they’ll see the following result:
“I’m not surprised that your studies don’t show any problems,” Ravi says, sounding a little annoyed. “But Widget World does rigorous, independent testing, and they found heat issues. What can you tell me about the heat?”
From this, learners realize that shoving research at the customer backfires. It sounds like option A was the better option, and for their next step, they’ll want to calmly discuss the concerns. (This post goes into more detail on why we’re just showing the result rather than telling the learner what they did right or wrong.)
More design time, less development
This approach usually requires more in-depth discussions with the subject matter experts and more careful script writing. However, it often results in quicker and easier development. We’re building fewer screens and, happily, we feel less compelled to add bling in a desperate attempt to make a boring presentation more interesting.