Teams
The core building blocks of the Product Operating Model
At the heart of the Product Operating Model (POM) are product teams—and more broadly, groups of product teams—that focus on enduring problem spaces, capability sets, customer journeys, personas, market segments, or well-bounded domains. These teams are designed to take full responsibility for solving problems and delivering outcomes within their defined scope.
Yes, teams change, split, and merge over time—and in many cases, it's beneficial to allow team composition to evolve. But a critical component of the product operating model is a degree of team stability, both in terms of team membership and team focus. This stability supports autonomy, deeper customer understanding, long-term accountability, and better cross-functional collaboration.
To support the Product Operating Model, the Dotwork Starter Pack introduces a set of foundational "objects"—a basic vocabulary to describe the people, teams, and structural elements of your product organization. These are intentionally flexible and adaptable.
| Object | Description |
|---|---|
| Individuals | The people who work at your company—regardless of role or affiliation. All other constructs center around the work and experience of individuals. |
| Product Teams | The core execution units in the POM. A product team is a durable, cross-functional group of individuals aligned around an enduring problem space. These teams are the primary locus of time, energy, and collaboration. Most individuals spend the majority of their time within a product team. |
| Functional Teams | These represent the craft-based or discipline-based affiliations—design, product management, engineering, data science, product marketing, etc. Individuals may split affiliation between a functional team (for coaching, standards, career development) and one or more product teams. |
| Product Groups | Collections of related product teams. Product groups typically have a small leadership team representing product, design, and engineering, responsible for coordination, staffing, and strategy across teams. |
| Product Areas | Optional higher-level groupings of product groups. Product areas are useful in larger orgs and provide an added layer of coordination and strategy. They often include leaders who oversee multiple product group leads. |
| Business Domains | For companies that don't center around a digital product, business domains reflect broader business structures—e.g., "Consumer Electronics," "Supply Chain," etc.—that product areas or groups may report into. |
| Triads | A triad is a cross-functional leadership group typically composed of representatives from product, design, and engineering. While triads exist naturally at the product group and area levels, many organizations also explicitly define triads at the product team level. Triad membership may rotate depending on team maturity, staffing, and organizational design. Triads serve as a shared leadership mechanism, guiding the team's direction, staffing, and quality of execution. |
A Note on Roles
In an ideal world, every product team would have fully embedded, dedicated support—designers, data scientists, product marketers, QA specialists, and more. But in the real world, that's rarely the case.
Teams often include part-time contributors, shared resources, and individuals who wear multiple hats across multiple teams. A designer might split time between two product teams. A data scientist might consult on multiple initiatives. A product marketer might rotate across launches. These patterns reflect real constraints—staffing levels, company stage, team maturity—and they're part of how work actually gets done.
That's why, in the Dotwork POM Starter Pack, we've placed special emphasis on making these role dynamics transparent.
You can:
- Assign multiple roles to individuals across different teams (e.g., one person might be a product manager on one team, and a contributor to another team's discovery effort).
- Create ad hoc teams—temporary configurations of individuals from different product and functional teams, often formed around projects, initiatives, or investigations.
- Track time-splits to make it clear when someone is contributing to multiple teams and how their attention is divided.
By recognizing and explicitly modeling this complexity, your Product Operating System becomes more realistic, adaptive, and actionable—not just a reflection of ideal conditions, but a tool for navigating the messiness of real-world work.