The PDD Playbook
A flexible framework for building and supporting product design teams at growing startups.
Leading and growing design teams is hard work. It's even harder when you are starting that journey from scratch and navigating a startup in growth mode at the same time. You are, as the saying goes, "building the plane while flying it." You have to grow the team; do the work (often on accelerated timelines and few resources); determine the team structure and processes to help you scale; recruit; coach; and evangelize. Phew. That's a lot.
The Product Design Department (PDD) Playbook helps you bring more structure, vision and storytelling to that work. It has helped me decide how to help my teams and I understand their progress. It gave me a language to talk about our goals and our success to leadership.
Playbook
The PDD Playbook goes like this: I expect designers to be…
High impact for the business
Customer-oriented in approach
Imaginative of new concepts/ideas
Quality drivers to ensure we ship the best we can
Collaborative early and often
Efficient in how we use our time
You can think of these as the outcomes of all this work. To enable designers to do this, the design department needs to provide…
Clear purpose
Efficient & effective procedure
Empowerment & support
Requisite resourcing
These are what I call "department pillars."
Pillars
The four department pillars ground the playbook.
The purpose pillar is about making sure your team has a clear sense of what your shared goals are. Purpose is about knowing what a successful outcome is and what direction to head. It's about aligning individual efforts with the larger company.
The procedure pillar is about shared standards and ways of working. Procedure is about giving designers a clear, shared answer to common collaboration problems. This is for the greater good and efficiency of the entire team.
The support pillar is about ensuring that designers get the help they need and deserve to be successful in their roles. At best, it is about making them greater than they are today. It is about empowering designers, getting things out of the way and giving candid guidance and coaching.
The resources pillar is about ensuring the team has the necessary (you guessed it) resources to carry out their goals. This can be securing budget, tracking and managing capacity, or establishing a clear hiring process and pipeline. It can also be about ensuring the goals narrow to meet the resources where they are at, if the resource pool cannot expand.
Plays
Many, if not all, of the tasks and activities we do as department heads, directors and managers roll up into the department pillars. I call these actions "plays." Are you coming up with a capacity plan? This is a resource play. Defining design principles? This is a purpose play.
You run plays to get the outcomes you want from your team. For me, the outcomes are those six designer expectations: impact, customer-orientation, imagination, craft quality, collaboration and efficiency.
For example, plays for the purpose pillar could be establishing design principles; UX health metrics; product KPIs; customer archetypes; vision concepts; etc.
Procedure plays can be about design process guides; project tracking and intakes; file and asset management; a review and feedback cadence; etc.
Support plays could be ensuring accessible management and leadership; regular growth feedback and 1:1s; design leveling and growth guides; education campaigns for cross-functional, internal partners; skill development opportunities; tools and resources; maturity and culture assessment; connection opportunities; internal visibility and recognition; etc.
And resource plays could be establishing a clear and sufficient budget; capacity tracking; requisite skills and headcount; hiring process; external visibility and recognition; contracting guidelines; etc.
Putting Into Practice
I like to think about this framework as a guide to get better results from your team by following the below four steps in regular intervals.
Identifying—identify how your team is doing against the six designer expectations. There are many ways you could assess this. You could do this anecdotally from your own observations. Or via written or verbal "360" feedback from your leadership or peer teams. Or in a more structured way through internal surveys, etc. With this new sense of awareness, identify the most important areas to grow.
Hypothesizing—based on your assessment in step one, identify the contributing reasons why performance in those areas are where they are. Hypothesize what department pillars map to these contributing reasons.
Running—with a sense of what pillars might be at the root, choose your most relevant plays to run. You can base this on which have the biggest potential impact given the scale, stage and internal appetite of the team. Then focus on them as departmental projects or initiatives, for a set time period, with clear exit criteria.
Assessing—As you work through running your plays, assess and share progress at regular intervals. One tactic is to choose a cadence to apply the framework. I have often used quarterly or every six months for reporting and planning. Each cycle I review the progress we made, communicate it, and start from the top of this list again.
Identifying and running the right plays requires some judgement. The framework is not meant to be dogmatic. The playbook won't choose your plays for you; you're the coach of your team after all! You have to make the decisions based on your team's unique predicaments. All of this can be customizable to your culture and business. That is by design! A playbook is more flexible than a rulebook.
For example:
Let's say you are getting a lot of feedback from management about your team not thinking about the business KPIs when designing new features. You are too dependent, they say, on other teams. This is the identifying stage. Maybe you determine you want to help your team have more impact by being more data literate.
After polling your team and cross-functional partners on the issue, you infer the reason for this is accessibility of data (purpose) and a lack of process around how and when to review (procedure). Experience with understanding metrics also seems to be a contributor for the team (support). Several designers have limited experience with using metrics to make decisions. Several others get it but don't seem to know how to incorporate metrics into their storytelling. This is hypothesizing the issues and using the pillars to help identify relevant reasons.
You decide to priorities some key projects this quarter to help resolve this. You align with the team that the biggest levers would be to create a design KPI dashboard (a purpose play) to improve accessibility. You want to set up bi-weekly metric review meetings to analyze together with product and analytics (a procedure play). This also gives designers a chance to learn from cross-functional peers and ask questions. Lastly, you ask your managers to use existing 1:1s with their reports to coach the several designers who aren't as experienced into how to leverage this data (a support play).
As you near the end of the quarter, you reach out to the same parties who gave the feedback, the involved designers, etc, and assess the progress you made. From there, you sum up outcomes and share with your manager, team or leadership team. Then, taking this baseline, you plan for the next quarter by going back to the identifying stage to see if this is still a primary problem or there are other areas to continue developing.
Conclusion
Leading and growing design teams is hard work. The shape this difficulty takes differs for every team, stage and culture I've been a part of. The underlying forces at work aren't that different though. The PDD Playbook helps take the unpredictability out of it by giving these forces a name. This way you can spend less time identifying and more time solving.
The PDD Playbook is built around the premise that design departments have roughly two goals:
Ensure we build great products that perform in market
Nurture and grow the team and culture needed to make it happen
Without goal two you can’t achieve goal one. So the PDD Playbook focuses on:
Clarifying what is expected of designers so they can help build great products for your organization
Defining what the levers are that the department leadership can pull (or the plays they can run) to support the team in doing so
The PDD Playbook has worked for me. If it works for you, great! If not, that's okay too. Do what works. In either case, I'd love to hear how you leveraged the playbook and what did or didn’t work. Now get out there and go get em!