What a playbook is (and is not)

A working definition

A playbook is a decision that has already been made. Someone did the work the slow way, kept the parts that held up, threw out the rest, and wrote down what remained in the order you will need it. You are not buying information. You are buying the skipped detours.

What it is

A sequence. Steps in the order they are executed, because order is where most attempts go wrong. Each step says what done looks like, so you know when to move on.

A set of defaults. Which tool, which setting, which price point, which email to send on day three. Defaults are not laws. They are the answer when you have no reason to choose otherwise, which is most of the time.

A record of failure modes. The part of each chapter that says "this is where it breaks" is worth more than the steps themselves. Anyone can describe the happy path. The happy path does not need a playbook.

What it is not

Not a course. A course teaches a subject; a playbook executes a task. One ends with understanding, the other ends with a thing shipped. Confusing the two is why hard disks fill up with unwatched video.

Not documentation. Documentation describes what a system does, written for the people maintaining it. A playbook describes what you should do, written for the people about to do it. Different tense, different reader, different job.

Not a guarantee. A playbook removes avoidable mistakes. It does not remove the work, and it cannot remove judgement. Two people run the same playbook and get different results because they bring different context. That is expected.

How to use one

Read it once, end to end, before starting anything. Playbooks make sense as systems; step seven often explains why step two is written the way it is.

Then follow it literally the first time, even where you suspect a better way. Deviating before you have run the known-good path means debugging two unknowns at once. Change one variable per run.

Mark where your context differs. Every gap between the playbook's assumptions and your situation is a note for later. Those notes become your own playbook, which is the real end state: ours gets you moving, yours keeps you moving.

How we write ours

Each of ours started as an internal document we used on client work. It gets rewritten after every project that uses it, while the mismatch between the document and reality is still fresh. A playbook that is not maintained becomes folklore: roughly true, increasingly dangerous.

That is also the test before we publish one. If we would not hand it to a new hire and trust them to run it unsupervised, it is not done.