"By the end of this module, learners will be able to identify the key principles of effective communication." Read that sentence again. Now tell me: what will be different in your organisation next Monday because a learner read those words?
Nothing. And that is the problem with learning objectives as they are almost universally written.
Learning objectives are a staple of instructional design education. They appear in every storyboard template, every course brief, every LMS metadata field. They are written in careful Bloom's taxonomy language. And they are almost completely useless as a guide to whether training actually worked.
The Gap Between Knowing and Doing
Learning objectives describe what a learner will know or be able to do in a controlled environment — typically, immediately after the training, while the content is fresh and the stakes are zero. They measure acquisition. But organisations do not pay for acquisition. They pay for application.
There is a significant body of research on the transfer problem — the gap between what learners demonstrate in training and what they actually do back on the job. Transfer is not automatic. It does not happen just because someone completed a course and passed an assessment. Transfer requires practice in authentic conditions, feedback in the moment, and an environment that supports the new behaviour. A learning objective, however well-written, addresses none of those conditions.
Performance promises address all of them. Because a performance promise is not about what the learner knows after the course. It is about what the organisation sees differently in the weeks and months that follow.
What a Performance Promise Looks Like
Here is the same training programme described two ways.
Learning objective version:
"Learners will be able to identify the steps in the customer service recovery process and apply them in scenario-based assessments with 80% accuracy."
Performance promise version:
"Within 30 days of training, customer-facing staff will complete incident recovery logs on the same shift as the complaint, at a rate of 85% or higher. Customer recovery satisfaction scores will increase by at least 15% within 60 days."
Feel the difference? The objective describes a learner in a training environment. The promise describes a business in the real world. The objective is complete the moment the course ends. The promise is only fulfilled when behaviour has actually changed.
Why This Matters for Design
Writing performance promises before you design anything is not just good for stakeholder communication. It fundamentally changes what you build.
When your target is "learners will identify the steps," you build content about the steps. When your target is "staff will complete incident logs on the same shift," you build a course that practises completing logs under pressure, examines the real barriers to doing so, and addresses the motivation and environmental factors that make it harder than it should be.
The performance promise reveals the real design challenge. It forces you to ask: what is actually stopping people from doing this? Is it knowledge? Is it skill? Is it a process problem? Is it a tool problem? Is it that nobody has ever clearly communicated why this matters?
A learning objective lets you skip that question. A performance promise does not.
How to Write One
A performance promise has three components: an observable behaviour, a measurable standard, and a timeframe. Together, they describe a future state that you and your stakeholder can look at and agree on whether it has been achieved.
Start with the question: what will people be doing differently? Not what will they know. Not what will they be able to do in a quiz. What will you actually see them doing differently in the workplace?
Then ask: how will we know? What data will tell us whether this change has occurred? Customer scores, incident reports, manager observations, sales data, compliance records — the metric should already exist or be easy to create. If you cannot identify a metric, the behaviour you are targeting is probably too abstract.
Finally: when? Within 30 days? 60 days? 90 days? Timeframes create accountability. They also create the expectation that you will go back and check. That expectation alone tends to change how seriously both the training team and the business take the programme.
The Stakeholder Conversation
There is a side benefit to performance promises that is not always acknowledged: they make you a much more credible partner to business stakeholders.
When you walk into a briefing meeting and say "we are going to build a course on communication skills," you are a vendor. When you walk in and say "in 60 days, your managers will be giving structured feedback to every underperformer on their team, and here is how we will measure it," you are a strategic partner.
Business leaders do not care about course design. They care about outcomes. They care about whether their investment in training is going to move a number they are responsible for. Performance promises speak their language in a way that learning objectives never will.
A Final Note
I am not suggesting you abandon Bloom's taxonomy or stop writing granular objectives for your own design process. Internal objectives are useful. They help you scope content, sequence activities, and align assessments. Keep writing them — but keep them internal.
What goes in the brief to the stakeholder, what goes in the course overview that learners read, what gets evaluated at 90 days — that should be a performance promise. A description of a better future that you are committing to help build.
If you cannot write that promise, it is worth asking whether you have understood the problem well enough to build a solution at all.