Teams of designers, software engineers, product managers, and project managers who collaborate at a high level do so because they know and trust each other. Not just on a personal level, which is great, but how they do and talk about their craft. This includes the steps it takes to accomplish activities like design sprints, and also when to do them, who to do them with, and how activities relate to each other.
But let’s say you’re a startup that is scaling your team rapidly. Or maybe you’re a big company funding a new program. Or any of the various ways it makes sense to bring a new group of folks together who don’t know each other well, but who must come together to solve a problem.
Members of newly formed teams do not always have the benefit of knowing what the next play is because they haven’t worked with each other long enough. These situations can create problems such as:
- Too many meetings and too many folks in each meeting because there’s both a lack of understanding of what activities are in play and also a lack of trust on how those activities will be carried out.
- Redundancies of activities due to not understanding who has clear ownership of them and a lack of understanding of what is accomplished in any single activity.
- Frustration between team members because there’s a lack of clear understanding of when an activity is done and how it’s handed off to someone else.
To solve these problems, your team needs a playbook.
The Playbook
A playbook as it relates to cross-functional design, product, and development teams is a collection of activities that are used to get sh*t done in order to create the best outcomes possible for the stakeholders and users of digital products. The playbook creates an alignment of a shared vocabulary, or taxonomy, of activities carried out by the team. It creates a hierarchy where helpful and allows for relationships and grouping of activities. Finally, a great playbook is easy to contribute to and evolve as patterns and practices evolve.
Just like the playbook of any soccer or football team, playbooks for technology teams build trust and efficiency between teammates because they begin to know the next steps your teammates will make while working together.
Outcomes
Similar to Design Systems, Playbooks are all about outcomes over deliverables. Taking time out to workshop, document, and create a template or two for your activities means pressing pause for a moment on tactical output. But just as software engineers refactor their code a little bit with each pull request, a little time out for capturing patterns of activities has a lot of strategic payoff down the road.
Alignment of Vocabulary
Playbooks create alignment of vocabulary, or what I like to call a “shared taxonomy” of what to call activities that make up a practice. This is extremely helpful for fostering collaboration between designers, developers, and product managers because of the ambiguity between related tasks. The difference between a "content inventory" and a "component audit" may be confusing if you’re not a content strategist. User testing and user research may be confusing to developers. And if you’re a digital agency, you want your growth and marketing teams to be accurately communicating your services to your clients.
Contribution Framework
Playbooks create a powerful framework for contributions from all levels of your team. Once your basic playbook taxonomy — what you’re calling activities and how you’re organizing them — is established, you’ve created a roadmap for folks to adopt the activities they are most passionate about. For example, you may have a designer on your team who loves facilitating design sprints and has strong opinions about how they’re carried out. Your playbook creates a way for them to build out the practice their way and have a place to showcase and defend their approach.
Continuous Improvement
Finally, playbooks facilitate continuous improvement of your organization’s practices. Routine, tactical activities can be done faster with more consistency, freeing up more time for strategic thinking and innovating on your practices. Mistakes of the past, while hard to completely do away with, are avoided more often eliminating costly fixes.
Format
The format or your playbook doesn’t really matter as long as you’re keeping in mind the outcomes above. I’ve tried a few over the years. Simple collections of Google docs and presentations that have been indexed work OK, but not great. Some teams make their’s public through "git" repositories or web-based content management systems.
My personal favorite, and what we used at my last company is Notion with AirTable as a close second. I love both these solutions for playbooks because they combine the best parts of a visual relational database with the cushy content authoring experience of an easy-to-use content management system.
Notion allows you to define your teams such as:
- Design
- Content
- Research
- Product
- Project Management
- Engineering
- Data
With a dash of hierarchy added, we create a basic governance structure and shared taxonomy of our activities:
Design
- Tone of Voice Workshop
- Design Sprint
Content
- Content Inventory
- Component Inventory
Research
- User Research
- User Testing
Product
- Product Roadmap
- Prioritization Matrix
Project Management
- Agile Implementation
- Staffing
Engineering
- Git workflow
- Deployment plan
Data
- Analytics report
The relational database part comes into play because many of the activities that teams do to create great digital products are related to each other. This coordination of activities can easily be mapped using both Notion and AirTable. Here’s what the relationships begin to look like in Notion:
Creating a service blueprint is an activity I frequently do early on when I’m working on new products, especially ones that integrate with multiple systems in an organization. I frequently go back to them whenever there is a misalignment of understanding of workflows within the organization.
In these cases, creating relationships between the activities in your playbook is extremely valuable. If a designer is leading a design sprint and the stakeholders are confused about the organizational context of the problem you’re trying to solve, they can pivot to related activities to help them get unstuck.
Conclusion
To wrap up. I highly recommend a playbook for your organization. I recommend embracing the agile practice of “just enough documentation” though. Start with establishing a basic taxonomy and a handful of activities that you frequently use. They’re probably ones that are already pretty well documented. Leverage the playbook as a way to gather your existing repository of practices in one place.
It’s OK to be aspirational about what practices you’d like to be doing, but don’t get bogged down in this. If you find that you’re slogging through something, you probably are. You should feel efficiency gains pretty quickly. Once that design sprint takes two hours to prepare instead of two days and your software engineers know exactly where the design documentation is found, your teams’ happiness and ability to innovate will begin to shine!