← Back to Playbooks

Playbook 3 — Role-Based Enablement

Designing training that fits the job, not a generic demo

A finance controller and a sales rep need the same tool explained two different ways. The tool is identical; the job is not.

Most AI training fails at the design stage, not the delivery stage. Someone runs one session for everyone, walks through the features, and calls it enablement. The team leaves knowing what the tool can do, which is not the same as knowing what to do with it on Tuesday afternoon.

Role-based enablement starts by listing the tasks, not the features. For each role that will use the tool, write down three to five actual tasks that recur in their week, in their language. Not “summarize text” — “turn the client call notes into a follow-up email before I leave for the day.” The task is the unit of training, because the task is the unit of work.

Then design backwards from the task. What does the person need to be able to do, and what is the shortest path to doing it? This is the part most in-house rollouts skip, and it is the whole curriculum: an objective per task, one worked example, one practice attempt on their own material, and a clear definition of what “good enough” looks like in their context. Everything else — model choice, prompt libraries, tips and tricks — is secondary to getting two or three real tasks done well.

Two mistakes are worth naming. The first is depth without relevance: teaching the difference between model versions to an accounts team that needs one repeated task automated. The second is relevance without depth: showing a flashy demo that leaves people unable to repeat it on their own files. Both produce the same outcome — a session people rate highly and never act on.

A practical shape for each role:

The test of the design is simple. Can a person in this role, the day after, complete one named task without you in the room? If not, the session taught the tool, not the job.

Next: Playbook 4 covers the layer between being trained and being competent.