A stakeholder walks in and says, “We need a course.” By the time the sentence lands, a decision has already been made — about the problem, the audience, and the fix — and nobody in the room diagnosed any of it. The request arrived as a solution. That is not a criticism of the stakeholder. It is just how requests travel through an organization.
The intake meeting is the one place you can reopen that decision without making the person wrong for having made it. And a good intake meeting should occasionally make the original request smaller.
Requests arrive as solutions, not problems
“We need onboarding training” is already three assumptions stacked on top of each other: that the gap is knowledge, that the audience is new hires, that the format is a course. Any one of them could be wrong. Maybe the real issue is that the process changed last quarter and nobody updated the job aid. Maybe half the audience already knows the material and sat through it anyway. Maybe a searchable checklist would outperform a thirty-minute module and cost a tenth as much to maintain.
You cannot see any of that from the request. You can only see it from the questions.
The questions that do the work
They are boring on purpose. The point is not to sound clever; it is to separate a training problem from a process problem before anyone builds anything.
- What changed? A request usually has a trigger — a new system, a spike in errors, a reorg. Find it.
- What are people doing today? Not what the SOP says. What actually happens on the floor.
- What do they need to do differently? A specific action you could watch someone perform, not “be aware of.”
- What happens if they do nothing? If the answer is “not much,” you have just learned something about priority.
- Is the gap knowledge, skill, process, motivation, or tooling? Only the first two are training problems. The rest need a different owner.
If every intake ends with exactly the solution that was requested at the start, the diagnosis step was decorative.
What it looks like in the room
A compliance lead asks for a forty-five-minute course because audit flagged that people were skipping a required step. The instinct is to start scoping the module. Instead you ask what people are doing today, and the answer is that the step lives on screen fourteen of a process most people abandon at screen nine because the form they need is on a different system nobody linked. The step is not being skipped out of ignorance. It is being skipped because the tooling makes doing it correctly slower than doing it wrong.
A forty-five-minute course would have taught four hundred people to do a thing the system actively discourages, and audit would have flagged the exact same behavior next year — now with a training record proving everyone “knew better.” The two-sentence version of the intake finding — “this is a tooling problem wearing a training costume” — is worth more than the course, and it took five questions to reach.
A smaller scope is not a smaller contribution
There is a fear underneath all of this: that if you talk the stakeholder out of the big course, you have talked yourself out of the work. In practice the opposite happens. The three-hour course becomes a thirty-minute workshop and a manager guide. The eLearning becomes a checklist that lives where the work happens. Half the audience gets handed back their afternoon.
The stakeholder does not remember that you built less. They remember that you were the person who made the problem clearer. That is what gets you invited to the next intake earlier — before the solution has already been decided.
Take the last three training requests you accepted. For each, write the one-sentence problem the training was meant to solve — the performance gap, not the topic. If you cannot write it without using the word “training,” the request was never diagnosed. It was transcribed.
None of this requires being difficult. It requires one meeting, five questions, and the willingness to hear that the answer might be less than what was asked for. The best intake meetings send you home with a shorter build and a sharper reason for it.
We walk through the shrinking-request version of this in a short video on the LumID channel.