What a Playbook actually is

Most experts who sell the same outcome twice already have a method. It is in a checklist, a saved prompt, a folder of past work, or nowhere except their head. The method is what the customer is actually paying for, and it is the one part of the work that never gets written down.

A Playbook is that method, written down as a document the YAMO runtime follows.

It is a document, not a configuration

This matters more than it sounds. A Playbook is authored text with structure in it, so you can read the whole thing in one sitting and see exactly what will happen. There is no hidden state, and nothing about it is inferred from how you clicked through a screen.

A Play is one step

Inside a Playbook, the ordered steps are Plays. A Play is a single named job: what it reads, what it does, and what it hands to the step after it.¹

Splitting a method into Plays is most of the writing. The useful test is whether you could hand one Play to somebody competent who has never done the work, and get back something the next Play can use. If not, it is two Plays.

What sits around the Plays

A Playbook also declares the things a run needs in order to happen at all:

Those four are also what a customer sees before they buy, which is the subject of the next post in this series.

It stays yours

Copying a template out of the Playbook Library gives you the document, not a subscription to somebody else's version of it. You edit the Plays, change the declarations and rewrite the wording, and what you end up with is your method rather than a starting point you are stuck inside.