Not a Training Problem: The Five-Minute Diagnosis Before You Build the Course

The request arrives with total confidence: "The reports keep coming in late and full of errors — we need a training on report writing." And because building a course is now fast and cheap, the tempting move is to just… build it. Two weeks later there's a tidy module on report standards, everyone completes it, and the reports keep coming in late and full of errors — because the reports were late for reasons no course was ever going to touch. The template lives in three places and two are outdated. The deadline conflicts with month-end close. And the one person who submits flawless reports on time has been rewarded for it with more reports.

Here's the principle that separates instructional design from course production, and it fits on an index card: training fixes can't-do. It has never once fixed won't-do, can't-because-the-system, or didn't-know-it-mattered. Performance analysts have been demonstrating this for fifty years, and the finding refuses to budge: most of what arrives labeled "training need" is something else wearing training's clothes. Which means the most valuable five minutes in L&D happen before anything gets built — and they consist of four questions.

The four questions

1. Could they do it if everything depended on it?

The classic thought experiment, and still the sharpest blade in the kit. Picture the person with every incentive aligned and every obstacle removed — could they perform the task correctly right now? If yes, you are not looking at a skill gap, and no amount of instruction will change anything, because instruction adds capability and capability was never missing. If no — they genuinely couldn't — you've found the real thing: a can't-do gap, and training is on the table. Ask this question first because a yes here makes the remaining three questions the actual diagnosis.

2. What happens to them when they do it right — and when they don't?

Follow the consequences. If doing the task correctly earns a person nothing — or actively costs them, like the flawless report-writer who "wins" more reports — the system is training people to underperform, efficiently, every single day. Late reports that trigger no follow-up teach that deadlines are decorative. A safety procedure that's slower than the shortcut, with no one checking, will lose to the shortcut forever. No course outruns a consequence structure pointed the wrong way; fix the pointing.

3. What's standing in the way?

Barriers are the most common non-training culprit at small companies and the most invisible from the requester's chair. The three-places template. The approval that waits two days on one busy person. The tool that requires re-entering the same data twice. People who look like they "need training" are frequently performing a broken process correctly — the errors are in the workflow, faithfully reproduced by everyone who follows it. Walk the actual task once, end to end, and the barrier usually introduces itself.

4. Do they actually know what's expected?

The cheapest fix in the entire discipline. An astonishing share of "performance problems" dissolve when someone states, precisely and once, what good looks like and by when — because the standard existed only in the requester's head, or in a document nobody has seen since onboarding. If expectations were never explicit, there is no gap to train; there's a sentence to say. Related and nearly as cheap: do they get any signal when they drift? A person who receives feedback for the first time in the annual review has been navigating without instruments all year.

Prescribe by branch, not by reflex

The diagnosis maps cleanly to prescriptions. Expectations unclear → a standards conversation and a visible exemplar — one meeting, not one module. No feedback → build the loop: who tells them, how fast, against what standard. Barriers → fix the process, the tool, or the single point of delay — and only then ask whether any skill gap remains. Consequences inverted → a management conversation the sponsor may not enjoy, which is precisely why it needs the diagnosis behind it. And the genuine can't-do → now build the course — gladly, and to a standard, because it's aimed at a gap training can actually close. In practice a stubborn problem is two branches at once: a real-but-minor skill gap sitting on top of a broken process, and training alone treats the minor half.

Saying "not training" without losing the room

The political danger is real: the sponsor asked for a course, and "your management is the problem" is a sentence with a short career attached. The move is to annotate, not gate. Don't refuse the build — run the five minutes, then present the findings alongside the plan: "Happy to build this. While scoping it I found three things that will limit what any training can do — here they are, and here's who owns each." The course can still ship; the diagnosis rides along with it, in writing. Sometimes the sponsor reads the memo and cancels the course themselves, which is the best outcome available. Sometimes the course ships and the memo turns out to be the document everyone points to in six months. Either way you've told the truth without making the sponsor wrong in public — and you've built the case file for the day the pattern repeats.

Where the tool fits

There's an irony in modern L&D worth naming: now that AI makes course production fast, the pressure to skip diagnosis has gone up — when building costs an afternoon, "just build it" feels harmless. It isn't; a course aimed at a system problem doesn't just waste the afternoon, it spends your credibility certifying that training was tried and failed. LearningByDesign is built for the far side of the diagnosis: when the answer is a genuine skill gap, it takes the outline from objectives to structured modules with checks that prove transfer — fast enough that you can afford to spend your scarce time on the four questions instead of the typing. Diagnose like an analyst; build like it's cheap. In that order.

The bottom line

"We need a training on X" is a diagnosis delivered by someone who didn't run one, and accepting it uncritically is how L&D becomes a course factory with no measurable effect on anything. Five minutes and four questions sort the requests: could they, what happens when they do, what's in the way, did anyone say what good looks like. Fix the branch the answers point at. Build — enthusiastically — for the can't-do that remains. The practitioners who work this way ship fewer courses and change more outcomes, and sponsors eventually notice which of those two things they were actually paying for.

— Tom