POM Starter Pack

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). In his excellent book Transformed, co-authored with Chris Jones, Cagan synthesizes patterns observed in high-performing digital product companies.

A key challenge product leaders face is figuring out how to operationalize the product operating model in their unique context. There is broad consensus that this is not a tools or process problem—so when we say "operationalize," we are not referring to process gates or software implementations. Instead, we're talking about 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 that bring the POM to life within a given context.

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. Product operating systems are deeply contextual. There is essentially a 0% chance you'll want to adopt this as-is. But if you're looking for a scaffold to get things moving—with an expiration date and an agreement to revisit and adapt it—we've got your back.

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." You're aware of the many hurdles—skills gaps, organizational inertia, politics, environmental constraints. You want to design an operating system that fosters the right behaviors and interactions, and nudges your team in the right direction.

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. They reflect real challenges we've seen across teams—and the values that anchor the Starter Pack's design.

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.

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

We've chosen to make Team Topologies a foundational element of the Dotwork POM Starter Pack. Originally developed by Matthew Skelton and Manuel Pais, Team Topologies is a framework that helps organizations define types of teams and collaboration patterns between teams.

The Four Fundamental Team Types

• Stream-Aligned Teams – aligned to a flow of work from a segment of the business
• Platform Teams – provide internal services to accelerate other teams
• Enabling Teams – help stream-aligned teams overcome obstacles and adopt new skills
• Complicated Subsystem Teams – own areas requiring deep specialist knowledge

Three Primary Collaboration Patterns

• Collaboration – teams work together closely for a defined period
• X-as-a-Service – one team provides a well-defined service that another team consumes
• Facilitating – one team helps another team acquire missing capabilities

Why Team Topologies?

There are countless frameworks available to describe team structure and interaction—but we chose Team Topologies for several reasons:

• It's simple, but deep. The model is accessible yet capable of describing complex dynamics.
• It's widely recognized. The language is increasingly familiar to product and engineering leaders.
• It clarifies team purpose. It helps organizations align on why teams exist.

Team scope refers to what a team owns, cares for, and makes decisions about over time. It's not just about day-to-day work. It's about the enduring parts of the business or system for which a team provides stewardship.

Scopes can take many forms:

• A segment of the technology stack
• A defined product surface area
• A customer segment
• A set of capabilities
• A customer journey stage
• A lifecycle stage in an internal value stream
• A specific market or geography
• A compliance or regulatory domain

Think of Scopes as a tagging system on graph steroids—a flexible, interconnected way to express enduring responsibilities.

Once you've defined the teams, the individuals, their topologies, and their scopes, you're ready to have meaningful conversations about how teams fit into your Product Operating Model.

First: What Is the Fundable Unit?

The first step is determining whether a team is a fundable unit on its own—or whether funding is applied to something broader that the team contributes to.

Advanced Funding—Team Stages

Not all teams will (or should) define a stage. This concept is reserved for teams/groups with a higher degree of autonomy—where leadership wants to make differentiated investment, staffing, and governance decisions.

Actionable Inputs are proximate, accessible, meaningful variables—measured either qualitatively or quantitatively—that teams can directly affect in their day-to-day work.

They are not OKRs, and they're not meant to change every quarter. If chosen wisely, a team might work with the same core set of actionable inputs for quarters or even years.

Example

A team that owns the onboarding experience might track:

• Time-to-value — how quickly users complete a critical first task
• Setup completion rate — percentage of users who finish onboarding
• Onboarding content relevance — how well guidance matches user goals
• User-initiated engagement — actions taken unprompted
• Activation support response time — speed and quality of help

Keeping the Learning Loop Alive

Each team should:

• Define its core actionable inputs
• Regularly review metrics and qualitative signals
• Adjust focus and resourcing over time

The choice of rituals is highly contextual, so in the Starter Pack, we're offering broad-swatch recommendations to help you get started.

Key Principles

• Fractality: The more frontline rituals resemble those at higher levels, the more you reinforce common language and enable upward mobility.
• Show, Not Tell: Include multiple levels so leadership can model behavior through action.
• Single Purpose or Open Agenda: Avoid hybrid meetings that try to do both.

Core Rituals

Actionable Input Reviews — Biweekly reviews that form the foundation of ongoing alignment. Teams reflect on their actionable inputs, direction and variation, what's changing, and where focus should shift.

Product work tends to follow a predictable path:

1. Insights — patterns, signals, or learnings that suggest something is worth exploring
2. Opportunities — specific problems, needs, or gaps we might pursue
3. Options — different ways we might approach those opportunities
4. Bets — structured, evaluable commitments with a hypothesis and learning model
5. Execution — experiments, projects, or workstreams
6. Release — a moment of delivery where something changes
7. Impacts — evidence of results, effects, or behavioral changes

Impacts connect to a team's Actionable Inputs, which contribute to Drivers—more directional outcomes that influence business performance. Those Drivers are key inputs into a shared Product North Star.

It is Fractal!

The flow from insight to impact isn't a one-time process. It's a fractal, layered system that plays out across multiple time horizons. A 1–3 year strategic opportunity may give rise to multiple 1–3 quarter bets, each inspiring several short-term experiments.

Artifacts are the connective tissue between strategy, decision-making, execution, and learning. When done right, they create alignment, clarify ownership, and serve as documentation and dialogue starters.

Strategic and Vision-Level Artifacts

Bet-Level Artifacts

The Dotwork Starter Pack is designed to reflect and support a layered, graph-based model—not flatten it. Each element in the flow (from bets to business outcomes) is treated as a first-class object and is fully graph-aware.

Once you've defined your teams, assigned scopes, clarified topologies, set funding models, and identified actionable inputs, your team is in a strong position to run with clarity and purpose.

The Dotwork Starter Pack offers a flexible approach to goals. It's designed to reflect how teams actually work—not how we wish they worked in a perfect world.

Principles Behind Goal Design

• Goals don't need to follow a single cadence. Some align with quarters; others span a year.
• Goals come in many forms. Metric-anchored, milestone-based, or anti-goals.
• Be careful with cascading. Overly rigid cascades stifle learning.
• Don't conflate goals with performance management. Goals are sense-making tools.

Goal Taxonomy

💬 Talk to Your Dotwork Customer Success Partner

Every Dotwork account includes a dedicated Customer Success representative. They're not just here for troubleshooting—they're your strategic partner in bringing the Product Operating Model to life.

They can help you:

• Tailor the Starter Pack to your organization's current maturity
• Suggest templates and approaches based on your context
• Walk through how to model your bets, scopes, and inputs in Dotwork
• Set up your initial workspace, facilitate onboarding, or run a quick Q&A