Skip to content
Nerdy beta

Product Operating Model

Product Strategy

Strategy without structure is just a speech. An operating model gives your organization the connective tissue between what you aspire to and what value you actually produce.

Overview

You already have one. Someone sets direction, teams pick what to build, work moves through a queue, and check-ins keep it roughly on track. Nobody wrote any of it down, which is why nobody can fix it.

Our default model makes the shape explicit. It names seven components — the functions your organization already performs, whether or not it has language for them — so a team can point at the specific place alignment broke instead of arguing about culture.

None of it prescribes tools or ceremonies. Trade Jira for index cards and all seven functions are still running. The only variable is whether you can see them.

Here is the shape. Six components pass work and intent along a spine; the seventh sits underneath and keeps the other six from drifting apart.

operating-model-cascade

The Seven Components

Vision — the future state you are working toward. Stable enough to guide decisions, loose enough to survive learning something new. It can be product (the experience you want to create), technical (the architecture you want to build), or organizational (the team you want to become). Teams inherit it or write their own.

Strategy — the principles that connect vision to Tuesday. The “how in principle”: policies like “prioritize developer experience over feature velocity” or “default to user research before building.” A principle that has never cost you anything isn’t a strategy — it’s a preference.

Frame — a living document that says why a team exists and what it is trying to accomplish inside a specific time horizon. This is the centerpiece; the other six either feed it or read from it. See Framing for anatomy, lifecycle, and patterns.

Roadmap — a time-oriented view of the outcomes you are working toward, in Now (committed this cycle), Next (the cycle after), and Later (directional, six months out). Now items trace to frame objectives. Later items stay coarse on purpose, because detail added early is detail you throw away. See Roadmapping and the Outcome-Based Roadmap template.

Funnel — how the team decides what work to pursue: collection (how possible work reaches you), prioritization (how you rank it), and commitment (how something moves from “possible” to “we are doing this”). The funnel is where you say no. If nothing was declined this quarter, you don’t have one. See Intake Funnels.

Pipeline — the queue of work the team has committed to. At its simplest: Backlog, In Progress, Done. Only work vetted by the funnel enters it, and everything the team does is visible in it, including the favors and the side quests. Favor collaboration over elaborate handoff states.

Events — the scheduled check-ins that keep the other six in rhythm: weekly work reviews, monthly frame reviews, and quarterly funnel, roadmap, strategy, and relationship reviews. The Continuous Planning Playbook details how they assemble into a quarterly planning system.

How They Connect

Read the spine as a narrowing. Vision anchors direction, strategy turns direction into decision rules, the frame makes those rules concrete for one team over one horizon, the funnel filters arriving work against the frame’s objectives, and the pipeline makes what survived visible. The roadmap is the one branch pointing outward rather than downstream.

Events are the loop underneath. Weekly work reviews keep the pipeline honest. Monthly frame reviews test whether the objectives still hold. Quarterly roadmap and strategy reviews connect one team’s execution back up to organizational direction. Cut the events and the other six don’t fail loudly. They drift, quietly, until the roadmap and the pipeline are describing two different companies.

How You Know It’s Broken

Each missing component leaves its own fingerprint. Match the symptom to the box.

  • Vision — a slogan on a wall no team can trace a decision back to. Every prioritization argument restarts from zero.
  • Strategy — a deck nobody cites when they are actually arguing a trade-off. Trade-offs get settled by volume and seniority instead.
  • Frame — the team can’t state its outcome in one sentence without opening a tool. A purpose that lives in Jira isn’t shared, it’s stored.
  • Roadmap — a roadmap review that never mentions a number. You are inspecting a delivery schedule and calling it strategy.
  • Funnel — work arrives by whoever asked loudest, and nobody can say what was declined. With no record of the noes, capacity is a rumor.
  • Pipeline — “when will this ship?” requires archaeology. If the answer takes three interviews to assemble, the work isn’t visible, it’s remembered.
  • Events — planning happens once a year. A twelve-month feedback loop corrects nothing; by the time the signal lands, the plan it would have corrected is gone.

Implementation

Phase 1: Start Small (First 2 Weeks)

  1. Pick one team to pilot with
  2. Create a basic frame: purpose, 1-2 objectives, success measures
  3. Set up a simple pipeline using whatever tool you already have
  4. Draft a basic roadmap: Now/Next/Later with a few key outcomes
  5. Define your funnel: how work gets to you and how you decide what to do
  6. Schedule weekly work reviews, 30 minutes maximum

Phase 2: Add Structure (Weeks 3-8)

  1. Refine the frame with community and working agreements
  2. Establish frame review cadence, monthly or quarterly
  3. Connect with dependent teams by sharing frames and discussing relationships
  4. Evolve the roadmap by connecting Now items to frame objectives
  5. Define team strategy: 3-5 principles that guide decisions
  6. Clarify vision, either inherited from above or team-specific
  7. Refine funnel with explicit prioritization criteria

Phase 3: Scale (Months 2-4)

  1. Roll out to related teams, usually 2-3 at a time
  2. Create team-of-teams frames for groups of related teams
  3. Add roadmap and relationship reviews as quarterly cross-team sessions
  4. Connect roadmaps across teams where dependencies exist
  5. Align strategies so team strategies support higher-level vision
  6. Establish a vision cascade from leadership through individual teams

A Rollout We Ran

A global online travel company brought us in while they were standing this up, and the tell was mundane: “when will this product ship?” required archaeology. The answer was scattered across twelve competing custom “team” fields in a Jira estate that had grown one merger at a time. Vision and strategy were sound. The pipeline was unreadable, so the roadmap was fiction, and the events reviewed the fiction on schedule. We treated the tooling as a product decision rather than an admin one — the full account is in From Tooling Sprawl to Product Alignment.

You are running all seven right now. The only question is whether you designed them or inherited them.

Resources