ebook from John Cutler/Dotwork to help product leaders operationalize the product operating model in their unique context. https://www.dotwork.com/product-operating-model

• aka POM Start Pack

Excerpts (partial)

What problem are we trying to solve?

Many companies today are attempting to shift toward what Marty Cagan has labeled the Product Operating Model (POM)

A key challenge product leaders face is figuring out how to operationalize the product operating model in their unique context.

the central design challenge: defining the rituals, artifacts, frameworks (explicit and implicit), guidelines, language, and behaviors that support the transition to the product operating model.

At Dotwork, we refer to this collection of elements as a Product Operating System—the unique set of design decisions

The Dotwork POM Starter Pack is intended to provide companies with something they can start using right away—or use as inspiration for tailoring their own version

Who are we trying to help? You’re a product leader or product operations leader who has been tasked with “moving to the product operating model.”*

Principles

Before we jump into tools, objects, and operating systems, we want to be clear about the principles we believe matter most in building a sustainable, adaptive, and human Product Operating Model. These aren’t theoretical.

1. Stable, Empowered, and Entrepreneurial Teams

The team—not the project—is the core unit of value creation. (the team is the focus)

2. End-to-End, Customer-First, Value Chain Thinking (customer-driven, Whole Product)

If we over-optimize for autonomy, we risk losing the whole.

3. When We Commit to Big Things, We Go All In

Most of the time, we want to optimize for loosely coupled, independently operating teams. But sometimes we need to do something big together. When that happens:

• It should feel different.
• It should feel focused.
• We pause everything else and form a real team.

4. Ask: What Should We Do?

It's easy to get stuck in “what can we do?” mode—especially in constrained environments. But that mindset locks us into incrementalism.
Product thinking means challenging the status quo.

5. Intentional Between-Team Interactions

Not every team can—or should—be fully autonomous

don’t leave these relationships to chance.

• Make interfaces explicit: requests, expectations, responsibilities.
• Choose the right interaction mode: embedded, service-oriented, facilitating.
• Design working agreements that evolve with the relationship.
• Don’t overstandardize. Don’t over-optimize. Just be intentional.

6. Embrace Writing (and Reading) as Collaboration

Not just for knowledge capture, but for active thinking and shared decision-making. (Org Writing Practices)

7. Thinking in Bets (and Bets Come in All Shapes and Sizes)

Don’t just talk about “opportunities”—talk about the bet you’re placing.

8. Apply Product and Design Thinking to How We Work

The way we work is a product. Treat it like one.
Start with the why. (Gardening Your Product Process)

Now, with that foundation in place—let’s move into the building blocks

Teams

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”

Individuals

Product Teams

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

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. (product triad)

A Note on Roles

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.
That’s why, in the Dotwork POM Starter Pack, we’ve placed special emphasis on making these role dynamics transparent.

Assign multiple roles to individuals across different teams

Create ad hoc teams —temporary configurations of individuals from different product and functional teams

Track time-splits to make it clear when someone is contributing to multiple teams and how their attention is divided

Team Topologies

We’ve chosen to make Team Topologies a foundational element of the Dotwork POM Starter Pack.

At a high level, the framework outlines four fundamental team types:

• Stream-Aligned Teams – aligned to a flow of work from a segment of the business (e.g. customer segment, product feature, etc.)
• Platform Teams
• Enabling Teams –
• Complicated Subsystem Teams

And three primary collaboration patterns :

• Collaboration – teams work together closely for a defined period
• X-as-a-Service
• Facilitating – one team helps another team acquire missing capabilities, then steps away.

Why Team Topologies?