Team Playbooks
People will understand your team better and onboard faster
I usually create a document called a Team Playbook for every team I work with. People across the company like this document because it provides a quick overview of how the team works and where to find resources, people, meetings and documentation.
The audience for the Team Playbook is
The team itself! Because believe it or not, sometimes team members are looking for that Zoom link or that Notion page and need a quick way to find it.
New team members. Anyone who joins the team should be able to get up to speed quickly. It helps to have a single page with a comprehensive overview.
People from other teams. It helps other people understand how you work if they can easily see where and when you meet, where your document is, and so on.
Contents of the Team Playbook
The principle here is: Anything that describes how the team works belongs in the document.
The document is about structure and process, not about the content of the work. So I suggest you list the following
Team name.
Team’s location in the org chart.
Team’s vision, purpose, area of expertise, or anything else describing what people in this team strive to achieve.
Team members with contact information or links.
Team members’ special skills (technical, social, organizational, …).
Team members’ current projects (if applicable. List half-year projects, not daily work).
Meetings. Make a list of all recurring meetings including title, time, purpose/goal, room number, or virtual link.
Location of documentation. Make a link list of where the team documents its work. It does write documentation, right? Right? Of course it does. Link to specifications, architecture proposals, decision logs, or any other valuable documentation.
Processes. How does the development process work? How do issues move through Scrum/Kanban? When does the team review something, and who does it? How do you sunset features? Work with links to existing documentation, there is no need to duplicate content.
Strategy. How is the team contributing to product strategy and business strategy? Link the strategy documents and detail how the team’s roadmap matches.
SKU/Product List. Provide a list of the actual products offered. Also include end-of-life products that are not sold anymore. Most often, you’ll provide a link to such a list in another system.
Business cases. How does the company generate revenue and how does the team contribute? How does each product generate revenue? What are the associated costs? If available, also add business cases that led to decisions to build product or features.
What did I miss? Add everything you need to know about your team. Imagine you are new to the team: What would you like to know? What would help you to understand the team?
The good thing is that you can start small and add anything important later.
You’ll notice that there is a strong overlap with a Handover Document, so you might decide to include some elements of a Handover Document in the Team Playbook right away.
How to Write Amazing Handover Documents
Whether you leave a company or take on a new job in your current company: Writing a good handover document is a good chance to ensure a smooth passing of the baton and leaving a great last impression. It may be required by your boss, but I suggest you write such a document in any case—your successor will thank you later.
Beyond Content
As with any modern collaborative document, use these guidelines for documentation that people want to maintain:
Don't write a Word document as if it were 1996. Use some kind of hypertext, collaborative document. Tools like Confluence, Notion, OneNote, Coda, Basecamp or even Miro are useful. These tools make it easy to share and update content.
Let people update: Don't be the only one responsible. Give people the technical permission to update the playbook and the social responsibility to update it.
Use hyperlinks wherever possible. This makes it easy for your readers to find the help they need. Link within the document, but also to external information in other tools.
Structure your document well. A good structure helps people find the right information quickly. Provide an overview at the beginning in the form of a table of contents. Of course, the table should also contain links to the relevant sections of your Team Playbook.
Aim for brevity, but include all the important information. Make it quick to read, while keeping all the necessary information (or links to it) in one place.
In conclusion, creating a Team Playbook will help your team members, people in your organisation and new team members to quickly understand how, when and where you work.
What I read
This is separate section of this newsletter. I will list some of the best articles I read on the internet. They may or may not be related to the topic of this article. I will keep a list of the best articles (currently >650) at https://www.digital-product-management.com. These are today’s picks:
Metrics that Matter to Product Managers: This post is a list of metrics by product type which you can use to inspire your own dashboards so that you can discover things which matter most about your product at the same time.
Product Metrics That Matter: A comprehensive summary of important metrics, including a dashboard proposal.
North Star Metric Playbook: The guide to discovering your product’s North Star metric.
Thank you for suggesting this go in a shared space so the whole team works on it! I would add a section on business strategy to cover your offers, SKUs and you make revenue.