Why most technical training fails before it starts

For years before I ever stood in front of a training room, I built the content that filled them — and I confused a well-built deliverable with a useful one. The first time that confusion cost something real, I was training a batch of customers, not new hires, and within a day their questions had gone out of scope. All that you are covering here — how does this help our project? I had no honest answer. By the fourth time I heard a version of that question, the diagnosis was unavoidable: the room wasn't where it had gone wrong. The room was just where I found out.

The design failure sat upstream, in the question that starts most curriculum-development processes: what do we need to cover? Ask that question and you get a coverage map — every feature, every release note, every screen the SME considers in scope. It produces completion rates, assessment scores, and feedback forms that say the right things. It is almost entirely disconnected from the question that actually determines whether training works: what does this participant need to be able to do when they leave?

The mechanism behind that gap has a name in cognitive science: the transfer problem — the distance between knowing something in the context where it was learned and being able to apply it in a context that looks different. A participant can score well on a closing-day assessment and still struggle visibly three weeks later, because the assessment tested recall inside the training environment and the job demands application inside a production one. Those are not the same cognitive task, and no amount of polished content design closes the distance between them on its own.

What does close it is the exit-state question, applied at the start of design rather than the end. After that customer batch, I changed the first question I asked — not the content, not the delivery format, the question itself. Instead of asking Dev and QA what was new, I asked practitioners who had implemented the product in real customer environments what actually broke, what customers tried to configure that the sandbox never covered, and what the gap was between "completed training" and "production-ready." The training didn't get longer. The features covered stayed largely the same. What changed was the frame: every piece of content now sat in service of a situation the participant could recognise as their own.

When a technical training programme fails, the diagnosis usually points at delivery — the trainer wasn't engaging enough, the content was too dense, the room was wrong. Sometimes that's true. More often the failure is baked in before the trainer walks in, before the deck is finalised, before the first participant registers. It is a question about coverage, asked by people who were structurally prevented from asking about outcomes instead.

Everything that follows from a curriculum depends on what question opened the design process. What does production-ready look like for this learner, in this context, on the day training ends? Start there, and the rest of the design has somewhere to go. Start with coverage, and you've built an inventory — a thorough one, possibly an impressive one — that was never going to transfer in the first place.

Further reading: Bransford, Brown & Cocking (Eds.) (2000). How People Learn. National Academy Press. · Lave, J. & Wenger, E. (1991). Situated Learning. Cambridge University Press. · Mager, R. (1962). Preparing Instructional Objectives. Fearon.