A subject-matter expert sends an instructional designer a 90-slide deck and a note: "Here is everything the new hires need to know. Please turn it into a course." The designer feeds the deck to an AI tool and asks it to build a module. Forty minutes later there is a polished 22-screen e-learning that faithfully covers all 90 slides, with a knowledge check on every section. It is fast. It is thorough. It is also a content dump, a tour through everything the SME knows, organized by topic, that will teach new hires to pass a recognition quiz and change nothing about how they do the job. The AI did exactly what it was asked. It was asked the wrong question. This lesson is about asking the right one, starting from the on-the-job action instead of the content, and using AI to pressure-test whether a module should exist at all.

The Content Dump Is the Default, and AI Makes It Faster

The most common failure in corporate learning is not a wrong fact. It is a course that covers everything and changes nothing. It happens because the default design question is "what does the learner need to know," and the answer to that question is always "more." A SME, asked what to include, includes everything, because to an expert it all feels essential. The result is the topic-organized information tour: a module that marches through concepts, definitions, and background, ends with a quiz that tests whether learners can recognize the concepts, and never once asks them to do the thing the job actually requires. Learners pass. Behavior does not move. The course was a documentary, not a rehearsal.

AI supercharges this failure, because the content dump is exactly the task AI does effortlessly. Hand a model a 90-slide deck and "make a course," and it will produce a flawless tour of the 90 slides. It has no opinion about whether any of it should be a course, because you did not ask it to have one. The speed makes the dump worse, not better: a bad course that used to take three weeks to build now takes 40 minutes, so more of them ship. The cost of producing a content dump fell to nearly zero. The cost of it being useless did not change at all.

A course that covers everything and changes nothing is not a fast win. It is a fast failure, and AI just made it forty minutes fast.

Action Mapping: Start From What People Do, Not What They Know

There is a design discipline built specifically to kill the content dump, and it inverts the default question. Action mapping, developed by Cathy Moore, starts not from the content but from the on-the-job action: instead of asking "what do they need to know," it asks "what do they need to do on the job, and what is stopping them." Why you care: starting from the action forces every piece of content to justify its existence by pointing at a real behavior, which is the single most reliable way to stop a course from becoming an information tour. If a slide does not help someone do something differently, it does not belong, no matter how much the SME loves it.

Action mapping has a clear sequence, and it is the spine of this lesson. First, you name a measurable business goal: the actual outcome the business wants, expressed as a number, like "reduce onboarding ramp time from 90 to 60 days" or "cut safety incidents on the line by 30 percent." Second, you identify the on-the-job actions people must perform to reach that goal: the specific, observable things a person does at the moment of work. Third, you design practice activities that rehearse those actions, realistic decisions and tasks, not information recall. Fourth, and only fourth, you identify the minimum information a person needs to perform each action, and you include only that. The order is the whole point. Goal drives actions, actions drive practice, and information comes last and lean, in service of the practice, never as the starting point.

Sit with the word "measurable" in the first step, because it is doing more work than it appears to. A goal like "improve onboarding" is not a goal in this sense; it is a wish, and a wish cannot tell you when you have succeeded or whether a course was even worth building. "Reduce ramp time from 90 to 60 days" is a goal, because it names a number, a direction, and a baseline, and it lets you do something a wish never can: ask, of any proposed module, "would this plausibly move that number?" Most proposed modules cannot survive that question honestly, and that is the point. The measurable goal is not bureaucratic box-ticking. It is the filter that gives you the standing to cut, because once a goal has a number attached, every slide and every activity has to earn its place by pointing, however indirectly, at that number. A slide that the SME loves but that moves nothing toward 60 days is not neutral. It is cost: learner time, build time, and attention spent on something that does not change the outcome the business is paying for.

Notice, too, how directly the second step connects to the previous lesson. The on-the-job actions you identify here are the very behaviors your learning objectives will target, written at the Bloom's level the action actually demands. Action mapping and objective writing are not two separate activities; they are the same discipline seen from two angles. The action "configure a new customer account correctly on the first attempt" is, almost word for word, an Apply-level objective waiting to be written in ABCD form. When the action is real, observable, and tied to the goal, the objective writes itself honestly. When the action is vague or invented, the objective inherits the vagueness, which is yet another reason the actions must be verified before anything downstream is built. The chain that ran through the last two lessons continues here: verified analysis, then verified actions, then aligned objectives, then practice, then minimum information, each link checked.

Notice that information, the thing the SME's 90-slide deck was entirely made of, is the last and smallest step, not the first and largest. Action mapping does not start with the deck. It starts with the goal and works backward to the deck, keeping only the slides that help someone do an action that serves the goal. Most of the 90 slides will not survive that test, and that is the discipline working, not failing.

Using AI to Pressure-Test Whether a Module Should Exist

Here is where AI becomes genuinely powerful in action mapping, and it is not the part most people use it for. The highest-value use of AI in the build is not generating content faster. It is pressure-testing whether the content should exist at all. A well-prompted model can act as a skeptical design partner that interrogates the request before a single screen is built, asking the questions a good designer asks a SME, and asking them tirelessly.

The move is to refuse, at first, to let AI build anything, and instead make it challenge the premise. Give it the goal and the proposed actions and prompt: "For each proposed action, ask whether training is actually what is needed, or whether the real barrier is a broken process, a missing tool, or no incentive. For each piece of content in this deck, ask which on-the-job action it supports, and if it supports none, flag it for cutting. Do not write any course content yet." Used this way, AI does the tedious, thankless work of holding every slide and every action up to the light, which a tired designer under deadline pressure tends to skip. It is the same skepticism the verified needs analysis demands, now aimed at the build.

This connects directly to the most expensive question in L&D, asked one lesson earlier and worth repeating here: is training even the right intervention? Action mapping's goal-first structure makes the question unavoidable, because if you cannot connect an action to a measurable goal, or if the barrier to the action is not a skill gap, the honest output is "this should not be a module." The bravest and most valuable thing an instructional designer can say is "we should not build this course, here is the process fix that would actually move the number." AI, pointed at the premise instead of the production, helps you say it with evidence.

There is a subtle reason this premise-testing role suits AI so well, and it is worth naming. The questions that kill a content dump are not hard questions. They are tedious, repetitive, slightly awkward questions that a human designer is socially and emotionally reluctant to ask, because asking them means telling a SME that their favorite slides do not belong and telling a sponsor that their requested course should not be built. A model has no such reluctance. Prompted correctly, it will ask "which action does this slide support" of all 90 slides without fatigue, without diplomatic hedging, and without the quiet pressure to just say yes and start building so the deadline gets met. You then bring judgment and tact to the model's tireless interrogation: you decide which of its flags are right, which cuts to defend, and how to have the human conversation with the SME. The division of labor is clean. The model supplies relentless, unsentimental scrutiny of the premise; you supply the judgment about what is true and the diplomacy about what to do. That is a genuinely good use of the tool, and it is the opposite of asking it to skip the scrutiny and produce screens.

A caution belongs here, because the same model that pressure-tests the premise can also fabricate the answers. When you ask AI to list the on-the-job actions, it can invent a plausible action that no one actually performs, drawn from its sense of what "onboarding" or "safety training" usually involves, exactly the hallucination pattern from the analysis lesson. So the skeptic must itself be checked. Every action the model proposes is a candidate to verify against the verified needs analysis and the SME's account of the real work, not a finding to accept. The discipline is symmetrical: use AI to challenge the premise of the build, then challenge the premise of AI's answers. Neither the request nor the model gets to assert an action into existence without tracing to the real job.

A Worked Example: The 90-Slide Deck, Action-Mapped

Return to the SME's deck and the request to "turn it into a course." Watch the two paths.

Before (the content dump). The designer prompts the AI: "Build a 20-screen e-learning module from this deck with knowledge checks." The model obliges perfectly. Twenty-two screens, every topic covered, a quiz per section. It ships. New hires click through it, pass the recognition quizzes, and arrive at their actual work no more able to perform than before, because nothing in the module rehearsed the work. The onboarding ramp time, the number the business actually cared about, does not improve. Six weeks of "training" later, the manager is still saying new reps are too slow, and the course is quietly judged a failure that nobody can explain. The deck was thorough. Thoroughness was never the problem.

After (action-mapped with AI). The designer starts with the goal, confirmed with the business: reduce ramp time from 90 to 60 days. Then she uses AI as a skeptic, not a builder. "Here is the goal and the deck. List the on-the-job actions a new hire must perform to ramp faster. For each, say whether the deck's content supports it. Flag any deck content that supports no action. Flag any action where the real barrier looks like a process or tool problem, not a knowledge gap." The model returns something far more useful than a course. It identifies five core actions, like "configure a new customer account correctly on the first attempt" and "locate current pricing for a quote in under two minutes." It flags that 60 of the 90 slides support no action and are background the SME finds interesting but new hires do not need to perform. And it flags that "locate current pricing" is blocked not by missing knowledge but by pricing living in three disconnected spreadsheets, a process problem. That single flag redirects effort: the fix for the biggest ramp bottleneck is not a module, it is consolidating the pricing data. The remaining real actions become a short, practice-heavy module: realistic account-configuration scenarios with feedback, not 22 screens of topics. The minimum information needed for each action, perhaps 12 of the 90 slides, gets included in service of the practice. The course is a third the size, rehearses the actual work, and points at a measurable goal. And the designer can tell the business: here is the practice module for the real actions, and here is the process fix that will move the ramp number more than any course could.

The lesson is not that AI cannot build a module. It can, fast. The lesson is that building fast is the wrong first move, that the right first move is asking whether the module should exist and what action it serves, and that AI is most valuable as the tireless skeptic that helps you ask, not as the eager builder that helps you skip the question.

The Discipline in the Workflow

Make action mapping the order of operations, and make AI serve it rather than subvert it. Three habits keep you honest. First, never start a build by asking AI to "make a course" from a deck; start by asking it to extract the goal and the actions, and refuse to let it write content until the actions are confirmed. Second, use AI explicitly as the cut-it skeptic: ask it which content supports no action and which actions are not really training problems, and treat its flags as candidates for cutting and for redirecting to process owners. Third, verify everything it proposes, because the model can hallucinate an action that sounds plausible or miss a real one, and the actions, like every load-bearing claim in this program, must trace to the verified analysis and the real job, confirmed with the SME.

The iron rule applies here in a particular shape. AI assists, the human verifies, the human owns the decision, and that includes the most consequential decision of all: whether to build the thing at all. "The AI built the module from the deck" is not a defense when the module changed nothing and the real barrier was a process the whole time. The designer who starts from the action, uses AI to pressure-test the premise, and is willing to say "this should not be a course" is the one who moves the number the business actually cares about, and that is the difference between fast production and real impact.

Key Takeaways

• The most common failure in corporate learning is a course that covers everything and changes nothing, caused by starting from "what do they need to know," whose answer is always "more."
• AI supercharges the content dump because that is exactly the task it does effortlessly; a useless course that took three weeks now takes 40 minutes, so more of them ship while the cost of being useless never fell.
• Action mapping, developed by Cathy Moore, inverts the default question: it starts from the on-the-job action, asking "what do they need to do, and what is stopping them," so every piece of content must justify its existence by pointing at a real behavior.
• The action-mapping sequence is goal then actions then practice then minimum information: a measurable business goal drives observable on-the-job actions, which drive realistic practice, with lean information included last and only in service of the practice.
• The highest-value use of AI in the build is not generating content faster but pressure-testing whether the content should exist: prompt the model to challenge the premise, asking which content supports no action and which actions are really process or tool problems.
• Action mapping's goal-first structure makes the most expensive L&D question unavoidable: is training even the right intervention, and the bravest, most valuable answer is sometimes "we should not build this course, here is the process fix."
• In the worked example, 60 of 90 slides supported no action, the biggest bottleneck was a process problem (pricing scattered across spreadsheets) not a knowledge gap, and the real course was a short practice module a third the size.
• The iron rule includes the decision to build at all: AI assists, the human verifies, the human owns it, and "the AI built the module from the deck" is no defense when the module changed nothing and the real barrier was a process the whole time.