The problem with learning objectives nobody talks about

Open any training program and you'll find them. Slide two, usually. Sometimes in the facilitator guide. Sometimes laminated on the wall. Learning objectives. Neat, numbered, professionally worded. By the end of this session, participants will be able to understand the core configuration framework. Appreciate the key principles of solution design. Be familiar with the end-to-end workflow.

I have written hundreds of them. I spent years writing them without once asking the question that should have come first: who is this actually for?

Not the participant. That's what the phrasing implies — "participants will be able to." But look at who reads learning objectives in practice. The L&D team reads them. The program manager reads them. The client sponsor reads them, sometimes, if they're thorough. The participant, in my experience, reads them at the start of day one and forgets them by the first coffee break. The learning objective is addressed to the participant and written for everyone else. That inversion is where the problem starts.

The audience problem

When you write for an audience that isn't the person doing the learning, the objective stops being a commitment and starts being a communication artifact. You're signalling to a stakeholder that the program has been designed thoughtfully. You're giving the program manager something to put in the deck. You're demonstrating due diligence.

None of those things require the objective to be honest. They require it to look credible. And "look credible" is a much lower bar than "be true."

This is why the same verbs appear in learning objectives across almost every technical training program ever written. Understand. Appreciate. Be familiar with. Demonstrate awareness of. These words were not chosen because they describe what the participant will actually be able to do. They were chosen because they cannot be falsified. If the participant underperforms in their first month back at work, you can always say they understood the content, they just didn't apply it optimally. The objective survives the failure because it was never designed to prevent it.

A learning objective written to survive failure has already failed. It just hasn't been caught yet.

The participant, if they read it at all, gets no useful information from "will be able to understand." Understand to what depth? Under what conditions? Enough to answer a quiz question or enough to configure a live system with a client watching? Those are not the same cognitive state, and the verb "understand" covers both equally — which is to say, it covers neither.

The verb problem

Robert Mager figured this out in 1962. His framework for writing instructional objectives was built on a simple principle: a useful objective describes observable behaviour, not internal states. You can observe someone configure a system. You can observe them diagnose a fault. You can observe them present a solution recommendation to a client. You cannot observe them "appreciate" or "understand" or "be familiar with" anything. Those words describe what might be happening inside someone's head. They are not outcomes. They are hopes.

Mager called verbs like "understand" and "appreciate" covert behaviours — states that can only be inferred, never directly observed. He wasn't against them because they're vague. He was against them because they're untestable. And an untestable objective is not a design constraint. It's decoration.

The honest version of most corporate learning objectives would look very different. Not longer. Not more elaborate. Just specific about the conditions and the standard. Not "participants will understand the configuration framework" but "participants will configure a multi-tier pricing structure in an unsupported environment, within 45 minutes, without reference materials." Same domain. Entirely different promise.

The table above isn't a rhetorical exercise. It's a design audit tool. Take any program's objectives, run them through it, and count how many land in the "safe verb" rows. In most programs, the ratio is roughly four to one. Four unverifiable objectives for every one that makes a real claim about what participants will be able to do. That ratio is not accidental. It reflects a system that rewards the appearance of accountability without requiring the substance of it.

The honesty gap

Here is the more uncomfortable version of the verb problem: sometimes the verb is chosen because the design can't deliver anything stronger.

If your training consists of demonstrations, walkthroughs, and guided exercises where every answer is on the preceding slide, you cannot write "participants will configure independently." The design doesn't support that claim. So you write "participants will understand the configuration process" — which the design can support, because understanding is unverifiable and anything you did in the room technically counts.

The verb is weak because the program is weak. But the verb hides the weakness. Nobody looking at the learning objectives on slide two sees the gap between what's promised and what's designed. They see a professionally assembled list of intentions and assume the program behind it delivers on them.

This is the honesty gap. It lives between the objective and the exercise. Between what the learning objective says the participant will be able to do and what the hardest activity in the program actually demands of them. In most technical training programs, that gap is large. It is also invisible — because the objective was written to be reassuring, not to be tested.

Before you finalise any set of learning objectives, run a single check: take the hardest exercise in the program — the thing participants do that is closest to independent, unguided performance — and ask what verb it actually earns. If the exercise involves following a documented walkthrough, the verb is "replicate." If participants configure a feature with reference slides available, the verb might reach "apply" with scaffolding. If they work through a novel scenario without guidance, you're approaching genuine application. Map your hardest exercise to a verb. Then check whether your objective matches it. If the objective claims more than the exercise delivers, you have a honesty gap. Name it or close it. Those are the only two options.

Who the objective should actually serve

The argument for rewriting learning objectives is not aesthetic. It's structural. An objective written in falsifiable language — observable behaviour, specific conditions, defined standard — does something a covert-behaviour objective cannot do: it functions as a design constraint.

If I write "participants will configure a multi-tier pricing structure in an unsupported environment, within 45 minutes, without reference materials," I have made a promise that the program must now keep. The assessment has to test that exact thing. The exercises have to build toward it. The scaffolding has to prepare participants for unsupported performance, not just guided replication. The objective has become a backwards-design anchor — everything in the program pulls toward it.

That is what a learning objective is supposed to do. Not communicate to stakeholders that the program exists. Not demonstrate that the L&D team has done its planning. It is supposed to define the target so precisely that every design decision can be evaluated against it: does this activity move participants toward the stated outcome, or not?

When I rewrote the objectives for the advanced curriculum at Apttus — not just the language, but what we were actually claiming to produce — the redesign that followed was not optional. The objective said "evaluate and recommend." The existing program reached "apply with guidance." There was a two-level gap. The only way to close it was to redesign the exercises, the assessment, and the facilitator's role in the room. The honest objective forced the honest design. That, and not any particular activity or content choice, is why the IBM Americas results eventually looked the way they did.

The objective is a claim. The program is the evidence. If you write the claim first — honestly — the program has to live up to it. Most programs write the claim last, after the content is already fixed. That is the wrong order.

The participant deserves to know

There is a final dimension to this that the technical literature addresses less directly, but which matters enormously in the room: the participant's relationship to the objective.

If a learning objective is written in observable, specific language, the participant can use it. They can ask themselves, at any point in the program, whether they are on track to meet it. They can self-assess. They can ask the facilitator for the practice they need. They can recognise, on the last day, whether they've arrived at the stated destination or not.

A participant who has been told they will "appreciate the key principles of solution design" has been given nothing useful. They cannot self-assess against it. They cannot know whether they've achieved it. They walk out of the room with whatever they absorbed, and no honest frame for understanding whether it's enough.

An objective written for the participant — genuinely for them, not for the program manager — gives them the answer to the question they're always asking but rarely get to ask directly: what does good look like, at the end of this, in conditions that resemble the job?

That is not a complex question. It deserves a direct answer. Most learning objectives provide everything except that.

Write the objective you'd be prepared to be held to. If you wouldn't put your name on it in front of the participant's manager six months after training ends, it isn't an objective. It's a cover story.