System Playbook
We love to describe all parts of an innovation management system in a system playbook. This book is a tool for documenting, communicating and iteratively improving the system. Learn more about important chapters in this article.
Bernhard Doll
Business Design Maverick
Content
1. Overview
A system playbook is a brief document (such as a PowerPoint, Word document or web-based wiki) that describes all essential parts of an innovation management system based on Business Design. The purpose of the document is to create a shared understanding among stakeholders in the organisation of what the desired work mode looks like to design innovation and new business.
The playbook answers the questions that otherwise get answered differently in every project: who decides what, how a project moves from one phase into the next, which budget it draws on and which deliverables it owes at the end of each phase. A new team member should be able to read it in an hour and know how innovation works here. If it takes longer than an hour, the playbook is too long. Companies are still hesitant to define how innovation work should happen. That is strange, because every other part of the value creation process is defined, ruled and guided in detail — procurement, production, sales and after-sales all run on documented processes, mandates and reporting lines. Innovation is the one area left to improvise.
2. Structure
We usually integrate the following chapters:
Nr. | Chapter | Content |
1 | Welcome note from CEO |
|
2 | Contents | |
3 | Vision and mission of the innovation management system |
|
4 | Link to company’s strategy 20XX / Picture of the Future |
|
5 |
| |
6 | Expected leadership behaviour · working principles in daily practice · what teams may decide without asking | |
7 | Key stakeholders, Roles & responsibilities | See Roles |
8 |
| |
9 | Internal partners and collaboration |
|
10 | External partners |
|
11 | Work mode & Guiding Principles | |
12 | Tools & Methods (selection) | |
13 | Decision-making along the End-to-End Innovation Process | |
14 | Stakeholder management |
|
15 | Resource allocation & budget | Annual planning of number of innovation projects in each phase of the End-to-End Innovation Process External budget for e.g. coaching, research, design & prototyping |
16 | ||
17 | Glossary | The 15 terms the organisation keeps using differently |
18 | Document control | Version · owner · date of last and next review |
3. Format and Length
PowerPoint, Word or a web-based wiki all work. Pick by how the document will be used, not by taste: slides if the playbook is mostly presented, a wiki if it is mostly looked up, a document if it needs to be signed off. Keep it to 40 slides or 25 pages. Everything longer belongs in the linked detail — the process chapter points to the phase descriptions, the tools chapter points to the templates. Feel free to draw on this guide — businessdesign.org — as often as you like.
Whatever you pick, there is one rule: one source of truth. A playbook that exists as a PDF on three shared drives and a slide deck in someone's inbox is four playbooks, and three of them are wrong.
4. Ownership and Update Cycle
Give the playbook one named owner — usually the Innovation Manager. Ownership means two things: the owner decides what goes in, and the owner is the person everybody asks when the playbook and reality disagree.
Tie the updates to the rhythm you already run rather than inventing a new one. After each semi-annual innovation review (see Governance), the owner collects what changed — a new gate, a shifted budget logic, a role that turned out to be missing — and updates the affected chapters. Once a year, in the annual strategy workshop, the leadership team confirms the playbook as a whole. Two updates a year is the minimum. A playbook that has not changed in two years is describing a system that no longer exists, and everything filed under it loses authority.
Put the version, the owner and the date of the next review on the first page. It costs one line and it tells every reader whether they are holding the current system.
Keep in mind
A system playbook is a living document. Don’t try to find the “perfect” system. This system doesn’t exist and may change over time. It is important to reflect on the performance of your current system in short review sessions and refine it based on your learnings. Keep the system playbook always up-to-date.
5. Common Pitfalls
The 80-page version: Written to be complete, read by nobody. If your playbook needs a summary, write the summary and delete the rest.
The aspirational playbook: Describes the system you want, not the one in force. Write down what is agreed and running today, and put the rest in the Roadmap for Implementation chapter, clearly marked as not yet in force.
The consultant's playbook: Produced outside the organisation, handed over, never owned. The wording is better and the commitment is missing.
Responsibilities without decision rights: The playbook names who is involved in each phase but not who decides. The gap shows up at the first gate, and it is expensive. See the decision-rights table in Governance.
The frozen playbook: Version 1.0, two years old, still in circulation. Teams work around it, and the system it describes quietly becomes fiction.
6. Q & A
Do we need a playbook before we can start? No. Start with one or two projects, then write down what worked. A playbook drafted before the first project documents assumptions, not a system.
How detailed should the process chapter be? One page per phase: purpose, key activities, deliverables, gate, roles involved. The detail lives in the phase pages, not in the playbook.
Who signs it off? The same body that decides the innovation budget. If the playbook is not backed by the people who hold the money, it is a recommendation. Usually C-Level Management.