Product Management Playbook

Distributed Project Teams

Product Management

An important thing to consider for any playbook and team to be set up for success and scaling is what Product Management means in each organization. Product management has its own ambiguity as a practice, as it differs between industries and types of product management (internal, consumer, B2B- SaaS), and individually within organizations. The role and meaning of product management will not be defined nor established in this playbook, but the foundations that can enable a product team to operate, produce, and scale will be.

Introduction

Purpose

This playbook is designed to guide product managers (PMs) working with distributed teams. It emphasizes collaboration, transparency, and agility in a remote working environment.

Audience

Product Managers, Practice Leads, Project Team Leads, and Stakeholders involved in distributed projects.

Scope

The playbook covers processes, tools, communication strategies, and best practices specific to managing distributed teams and projects.

Principles of Distributed Product Management

Transparency

Transparency is key for the success of any team and project, whether all team members and stakeholders are in the same space, or distributed across the globe. In a distributed environment, with varying time zones, where all communications are actively sought out or scheduled, it bears even more importance, so that everyone is aligned on the same principles, vision, and scope, and all are working towards the same goals. All team members MUST have access to the same information, and all decisions must be documented and shared openly.

Collaboration

Much like transparency, collaboration is of absolute importance. It is the mixer that blends all the ingredients and kneads the dough to make the bread! Foster a culture of collaboration across time zones, using asynchronous communication where necessary.

Empowerment

Having experienced a diverse mix of product and project teams, I have come to believe Empowered teams (Thank you, Marty Cagan for Empowered), are the strongest, healthiest, most productive teams; the teams that build great products and make organizations grow. It will be discussed further in the next section, but it is important to empower team members by trusting them to manage their time and contributions effectively.

Flexibility

What is product management without agility, flexibility, and/or ambiguity??? Playbooks, processes, and guides are all great, but no two teams work the same way, and no two projects or stakeholders will be identical. Embodying the theory behind the Agile development frameworks we all love to work with (whether Scrum, SAFe, Kanban, Lean, etc.), we must adapt processes to accommodate different working styles and time zones.

Setting Up the Team

Team Composition

Depending on the organization, the project, and the reality of available resources (people), there may or may not be much input a PM has in the makeup of the team. That said, the PM Leadership should always work with other practice leads (and in some cases, higher leadership, depending on org size and level of involvement) to assemble cross-functional teams with skillsets that best fit the project needs. From a leadership side, we must ensure a mix of skills across product, design, engineering, delivery, and QA. The project team PM is often the team lead, and as such, they should always ensure the team has clear roles and responsibilities.

Onboarding

Onboarding can be one of the most taxing, expensive, and tricky steps of an individual’s participation in a project. Clear documentation and resources can make onboarding both quick and efficient, both at the very beginning of a project as well as at any time throughout the duration of it, when team changes occasionally happen; we sure try to avoid them, but we are humans, and things happen. Provide a comprehensive onboarding process that includes an introduction to tools, communication protocols, and the project’s goals. The project’s PM should work with Sales, leadership, and stakeholders before the official kick-off to ensure they can furnish a Project READ ME, and with the Engineering leads to customize a project-specific onboarding guide. These documents need to be revisited regularly and diligently updated with changes and new information.

Roles and Responsibilities

Clearly define the roles of each team member, including the PM, engineers, designers, and any other relevant roles. I cannot stress the importance of clear and “signed-off” Roles and Responsibilities between team members, with details and examples specific to the project. I’ve lived the dysfunctional world of blurred lines of roles and ownership, and seen it affect the team and individual’s mental health, productivity, and almost project success. I found it very effective to dedicate time and 1-2 activities for the team members to work on this at the very beginning to ensure everyone is aware of what they expect to do, what is expected from them and who to go to for everything.

• Example (and my go-to): Ask each practice lead in the team (Lead Eng, Product Manager, Product Owner, Delivery or Project Manager, Designer, QA to asynchronously write out what they think their role entails and what their responsibilities are. Once done, build out a board (I’ve used Miro for it in the past) with all the provided data and go over them one by one with the team in a live meeting to identify the owner and the contributors. This clarity can truly help a team work better together, and work faster. It can also aid in the onboarding we covered above.

Product Development Lifecycle

Discovery Phase

Discovery is the first, most integral part when starting a project, it is ongoing throughout and all the way to the end (at least, it should be!). This Discovery & Framing presentation is my trusty companion for stakeholders and new teams alike.

• Conduct industry, market & user research, and stakeholder interviews to ensure awareness of the known-knowns, the known-unknowns and get a sense of the unknown-unknowns. Ensuring input from all team members is important as they bring in different perspectives and need answers to different things.

  • Involving project/delivery managers & engineers in this phase is important for the following reasons:

    • User Compassion

    • Sanity check/validation: do other brains understand the synthesis and insights the same way we do? Do they see something else? Are they confused by something?

      • These checks aren’t there to prolong the process, and they won’t undo or restart the D&F, but they provide room for different perceptions, and questions and can prevent ambiguity, confusion, or discovery gaps.

    • Early understanding of “needs to address”

    • Early feasibility checks

    • Early ideation and planning for architecture, data ingestion, and structure, third-party services or integrations, setting up for authN & authZ

    • Enable project/delivery managers for planning, preparation, budgeting, etc.

  • Synthesis should be conducted by Product and Design and shared early and often with the other practice leads and the entire team to capture different questions, and perspectives and build/maintain alignment.

    • Synthesis should produce Insight & Actions (example from Shopkick project) and Needs to Outcomes (example from Truss project) for the next steps of the development cycle and maintain an iterative process.

    • Once refined and ready for ideation, Insights & Actions should be shared with client stakeholders to establish transparency, informing about our findings and understanding that will be the building blocks for development. Sharing these can help build trust, and alignment and curb stakeholder expectations.

• Conduct Vision (6mo, 1Y, 3Y, 5Y) and Strategy (6mo, 1Y) discovery with stakeholders and leadership to gain perspective and understand how this product fits into the bigger picture.

• Establish Discovery Definitions of Done to avoid delays, and prevent getting lost in too much detail or going down the wrong rabbit hole.

• Use tools like Miro or Figma for collaborative brainstorming and design sessions. Ideate, and invite team members and stakeholders in concept testing rapid prototyping activities to create an open, collaborative environment and build an engaged environment.

• Document user needs and actions, personas, and journey maps in a shared space.

• Identify the key needs to address, ideate the ideal solution collaboratively with the team, and then break it down to MVP, Must have follow-ons, and Nice to haves. Arrive at the MVP.

Planning

• Create All-The-Roadmaps!

  • High-level roadmap with objectives for leadership & more distanced stakeholders.

  • Create a project roadmap that aligns with business goals and is flexible enough to accommodate changes.

  • Create the MVP (in-focus level) roadmap that will focus on MVP Epics, Dependency work, Bug allotment, and Legacy/Infra/Refactoring work. Ensure all dependencies are accounted for. Review with all team members for accuracy, timing, dependencies, and stretches.

• Documentation, documentation, documentation. Lack of documentation leads to assumptions, and assumptions lead to mistakes and do-overs. Set the team up for success with clear and thorough documentation, from Confluence pages, READ MEs, Briefs, Epics, etc.

• Use project management tools like Jira or Trello to track tasks, assign ownership, and manage dependencies.

• Identify, Define & Establish OKRs, KPIs, and all relevant project and team metrics of success.

• Communicate! Once the roadmap is cleared with the team practice leads, share it with the entire team. Not as a quick demo during planning, nor as a shared doc/page/board. Conduct a team activity to walk through the plan together and define what is needed to succeed, what can cause setbacks, and what gives the team pause. It will ensure clear understanding, and alignment and bond the team as all feel heard and in control.

Execution

• Define delivery and deployment cadence (strive for CI/CD), release cadence, sprint length, sprint resource allotment, and sprint capacity.

• Break down the work into sprints, ensuring that the workload is evenly distributed across the team. Depending on the team composition, if there is a project/delivery manager, planning capacity, pointing style and definitions could already be done. It is time to ensure this is all defined and communicated.

• Establish and conduct sprint planning and backlog refinement* sessions to prioritize tasks.

  • * : I prefer refinement instead of grooming mostly due to its anti-DEI wording and less due to its negative connotations about backlog management

• Use GitHub or GitLab (or anything else already established) for version control and code reviews.

• Schedule & conduct demos consistently and frequently (depending on sprint length), internally with the team, and externally, with stakeholders.

• Schedule and conduct roadmap reviews and periodic strategy/vision checks.

Testing and QA

This area can be drastically different depending on the existence of dedicated QA, self-testing practices, and the level (and extent) of established testing automation. While any of the above will impact how it happens and the level of difficulty, as the PMs, we need to plan and establish the team’s processes around testing & QA.

• Implement continuous integration and continuous deployment (CI/CD) pipelines to automate testing. Most engineers I’ve worked with live and breathe CI/CD, but I have personally experienced the difference it makes by being able to review work early and often within a sprint, saving time in development and delivery.

• Ensure that QA processes are integrated into the sprint cycle, with dedicated time for testing and bug fixing. Define QA and review owners and sign-off process. (Swimlane automation can be your best friend here!)

• Use tools like Selenium or Cypress for automated testing.

Launch

• Plan and execute product launches with clear communication to all stakeholders.

  • Release notes? Demo? Walk-throughs?

  • Do the stakeholders need documentation for their release notes, publications, or their own stakeholders?

    • Product marketing, Marketing, and Client Success / Account Managers can be your besties here!

• Coordinate across teams to ensure that all aspects of the product, including marketing and support, are ready for launch.

• Monitor the launch closely, with a plan in place for addressing any issues that arise.

• Plan metrics review cadence and start creating snapshots to capture and communicate success.

Retrospectives and Continuous Improvement

Regular Retrospectives

Hold regular retrospectives at the end of each sprint to reflect on what went well and what could be improved. Many people hate retrospectives; others are afraid of them and always stay silent; others love them for the wrong reasons, and some just can’t live without them! It takes a trusting environment, and an empowered team, to have a truly meaningful retro! We all like seeing the Ups/ Keep it going/highs and generally all the things we did well. We are ok to share our dislike when the Downs/Don’t repeat/Lows are about a third party, a stakeholder, and so on. But bringing up the difficult stuff, the issues or concerns we have amongst us? This takes a team that feels safe, feels trusted, and feels that everything is open to growth and improvement! Make them good and make them matter!!

Feedback Loops

Create feedback loops with users and stakeholders to continuously improve the product. Along with the demos, and roadmap reviews, there needs to be feedback and continuous discovery, to ensure alignment between us and the stakeholders.

Process Iteration

Regularly revisit and refine processes to ensure they remain effective for the team’s needs. Iteration is much a part of development, roadmaps, and discovery, as it is a part of team and project processes.

Tools and Resources

• Communication: Slack, Zoom, Microsoft Teams

• Project Management: Jira, Trello, Asana

• Collaboration: Miro, Figma, Confluence

• Development: GitHub, GitLab, Docker

• Testing: Selenium, Cypress, Jest

• Documentation: Google Drive, Notion, Confluence

Best Practices for Distributed Teams

• Over-communicate: In a distributed environment, it’s better to over-communicate than to assume everyone is on the same page.

• Be Inclusive: Ensure that all team members, regardless of location, have a voice in decisions and discussions.

• Focus on Outcomes: Measure success by the outcomes achieved rather than the time spent working.

• Prioritize Well-Being: Encourage work-life balance, and be mindful of burnout, especially in different time zones.

• Be a human: When in a shared space we interact with people randomly, and without intent, by crossing paths, attending a meeting together, etc. When in our own spaces, countries, and continents apart, we must strive to have human relationships too. Learn about the people on the team. Who are they?

• Promote trust and honesty: Be prompt, honest, and clear about issues, disagreements, disputes, or any negative stuff. It is easier for resentment to build when we don’t get to interact or resolve any issues. Lead by example and ensure all team members feel comfortable doing so too.

Case Studies and Examples

• Project README

• CMS Disco Fever: Discovery & Framing for Truss project with CMS

• Guide to Trussels in Internal Initiatives

• Why Discovery & Framing?

• Truss_CMS_Miro-project-board

Conclusion

Circling back to the beginning, this is only a guideline informed by education, research, practical application, and experimentation. Two teams will never be the same, nor will two projects, organizations, etc. I know that I will have to make adjustments to this playbook for practically any team I work with next. But the main principles are here to build around and transform.