Launch Your Product Operating Model

After defining team scopes, topologies, and funding models, most teams should be in a strong position to articulate a candidate set of Actionable Inputs—the key levers they can influence directly.

The Product Operating Model emphasizes autonomy and ownership. But autonomy only works if teams can focus on what they actually control. If all you chase are lagging business outcomes or high-level OKRs, you'll miss the opportunity to build the muscle required for continuous learning and iteration.

What Are Actionable Inputs?

Actionable Inputs are proximate, accessible, meaningful variables—measured either qualitatively or quantitatively—that teams can directly affect in their day-to-day, week-to-week, and quarter-to-quarter 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. What shifts over time is which input(s) get the team's attention based on the evolving strategy.

Example

Let's say a team owns the onboarding experience.

At a high level, onboarding success might be a function of a few stable levers:

• 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 the guidance matches user goals
• User-initiated engagement during onboarding — number of actions taken unprompted
• Activation support response time — speed and quality of help when users are stuck

These are all Actionable Inputs—things the team can study, iterate on, and influence directly. Some may align with the team's capability scope (e.g., providing guidance), while others relate to surrounding systems or support teams. Over the years, the team may try various tactics to move these inputs, but the levers themselves remain relatively stable.

Keeping the Learning Loop Alive

Each team should:

• Define its core actionable inputs
• Regularly review metrics and qualitative signals related to those inputs
• Adjust focus and resourcing over time based on what's most relevant

This helps teams build durable context, which they can return to quarter after quarter—even as projects, OKRs, and priorities shift.

What the Starter Pack Supports

In the Dotwork Starter Pack, teams can:

• Define one or more Actionable Inputs
• Nest inputs into a tree to represent causal relationships (if helpful)
• Assign metrics or qualitative indicators to each input
• Log observations, experiments, and notes over time
• Adjust and track focus percentage by input, over defined time periods (e.g., quarters)
• Revisit and revise that focus as strategy shifts

If you're following along, this is one of the most important parts of the Starter Pack: We're trying to help teams build a web of context that is stable enough to serve as a foundation—something teams can return to, reflect on, and improve against. Much of product work is ephemeral: a project, a quarter, a goal. But this underlying scaffolding—scope, ownership, levers—gives teams something durable to return to.

Notes on the North Star Framework

One approach we've seen work well is the North Star Framework (NSF). This model identifies a single North Star Metric—a leading indicator of long-term, differentiated business success—and maps input metrics beneath it. These inputs are typically Actionable Inputs.

In practice, however, we've found that most teams don't start with a well-defined strategy—they start with tacit assumptions and fragmented views.

That's why we recommend starting from the bottom up: Make the proximate levers visible, track them, talk about them, and build from there. This gives you the raw material to work "up" toward a North Star Metric over time. Without that grounding, North Star discussions can feel vague or performative. But with Actionable Inputs in place, you can have much more honest and useful conversations about direction, alignment, and impact.

Transitioning to Rituals

You've probably noticed by now that we've said very little about the things people usually associate with work—projects, goals, even strategy. That's intentional.

Most companies struggle to clearly communicate the "as-is" reality without immediately jumping to current workstreams, OKRs, or strategic bets. Teams are often defined solely by what they are doing, right now. We see this as a dangerous slope. Your company, whether it realizes it or not, already has a narrative that exists independent of "the work." That work emerged from assumptions, constraints, and context. And your teams already have boundaries—or lack thereof—that shape what they can and can't do.

Of course, where you're going matters. But you should be able to describe a product team in just a few short statements:

• Who do they serve?
• What is their sphere of ownership?
• What levers do they move?
• What is the shape of the team? (topology)
• Who is on the team?
• What kinds of things do they tend to do?

This is crucial, often-undiscussed context. Many teams write a mission statement once, then never return to it. What we've done so far is build the scaffolding around the things that are more stable—the things that tend to remain true, even as goals shift and projects come and go.

In the next section, we'll shift focus to rituals—not goals or deliverables, but the rhythms, meetings, and intentional moments that help teams stay connected to their purpose and each other.

We'll get to the "work" soon enough. But for now, sit back, and let's talk about the rituals that make all this context live and breathe.