Setting Team OKRs When You No Longer Own a Single Product's Numbers

Team OKRs for a multi-product group should express something only visible at the aggregate — a shift in retention, expansion, or platform cohesion — never a rollup of each product's own key results. Assign every product one or two outcome KRs it exclusively owns, ladder them into that shared objective, and reserve output KRs for enabling work no single product covers alone.

Quick answer: Write the team objective one level above what any single product could achieve by itself. Give each product exclusive ownership of distinct outcome KRs so nothing gets double-counted, and use output KRs sparingly — only for shared infrastructure or enablement work that sits between products.

The Layering Problem: Why Team OKRs Are Not a Sum of Product OKRs

A team objective that just restates "grow retention, activation, and revenue across all our products" is not a strategy — it is three product OKRs wearing a trench coat. The fix is to write the team-level objective at a level of abstraction only the aggregate can occupy: cross-product stickiness, platform-wide trust, category leadership. If any single PM on your team could hit the objective alone, it belongs one level down, not at the team.

This matters because of "line of sight." When you owned one product, your OKRs and your team's OKRs were nearly identical — you were the layer. As a group PM, you now sit above several people who each have their own line of sight to their product's numbers; your job is to define the layer above theirs, the one that only becomes visible once their individual results are combined.

Andy Grove's original formulation of objectives and key results at Intel, later popularized by John Doerr in Measure What Matters, was built around exactly this cascade — but a cascade of increasingly specific contributions to a shared goal, not a copy-paste of the goal down every level. A quick way to test whether you've written a rollup instead of a real team objective:

• Weak (rollup): "Grow revenue, activation, and retention across all three products this quarter."
• Strong (aggregate): "Become the platform customers consolidate their spend into, rather than fragment across three vendors."

The weak version is just three products' targets glued together with "and." The strong version names a customer behavior — consolidation — that no single product can produce alone; it requires Payments, Onboarding, and Analytics to each contribute a different piece.

Christina Wodtke's Radical Focus offers a useful discipline here: separate your health metrics (the vital signs you watch but don't chase, like support ticket volume or NPS) from your key results (the handful of numbers you are actively trying to move this quarter). At the team level, most of what looks like "the sum of product metrics" is actually health metrics dressed up as KRs — worth monitoring, not worth spending your team's limited OKR slots on. That filtering instinct only gets more important once you've made the shift to portfolio thinking across products rather than ownership of one.

If you're new to reasoning about a group of products instead of one, this shift is worth working through before you touch a single KR — see our complete guide to the group lead PM role for the operating model this article assumes.

Outcome KRs vs. Output KRs: The Distinction That Multiplies Across a Team

An outcome KR measures a change in customer or business behavior; an output KR measures something your team shipped. At the single-product level, mixing the two is a minor foul — everyone roughly knows what "done" means. Across a multi-product team, the confusion compounds: five output KRs from five products create the appearance of a busy, productive quarter with zero evidence anything actually moved for a customer.

Marty Cagan and the Silicon Valley Product Group have spent over a decade making this the central argument of the "empowered teams" model: teams given output targets (ship features, hit deadlines) will hit them and still fail the business, because delivery speed was never the real constraint. Jeff Gothelf and Josh Seiden built an entire book, Outcomes Over Output, around the same failure mode — a team can be extremely busy and completely ineffective, and a KR list full of shipped-feature counts is exactly how that gets hidden until the quarter ends.

The practical test: ask "if we hit this KR and the customer's behavior didn't change, would we still call it a win?" If yes, it's an output. That's not automatically wrong — a compliance certification or a platform migration with a hard deadline is a legitimate output KR — but it should be the exception on your team's scorecard, not the default.

Converting an Output KR Into an Outcome KR

Most output KRs can be pushed one step further without much extra work. Take "ship self-serve signup flow by Q3" — instead of stopping at the ship date, ask what behavior the flow is supposed to change, then measure that instead.

1. Name the shipped thing's intended effect. The signup flow exists to reduce sales-assisted onboarding.
2. Attach a number to that effect. "Increase self-serve signups from 20% to 45% of new accounts."
3. Keep the ship date as a milestone, not a KR. It still matters for planning; it just no longer counts as evidence of success.

A useful forcing function when you're deciding what outcome to chase in the first place: ground the KR in the customer's actual job, not your feature list. A Jobs to Be Done lens and a mapped customer journey tell you where a behavior change would actually matter to the customer — a far better source of outcome KRs than a brainstorm of "things we could measure."

The Double-Counting Trap: Keeping Metrics From Overlapping Across Products

Double-counting happens when two or more products on your team claim the same underlying metric as their own KR — three PMs all citing "increase revenue" produces a scorecard that looks impressive and proves nothing, because no one can say which product actually moved the number. The fix is an exclusivity map: before finalizing a single KR, list every metric under consideration and assign exactly one owning product to each.

Build this as a literal grid, not a mental note. For every candidate KR, ask three questions:

1. Is this metric primarily driven by one product's changes, or by all of them together? If it's genuinely shared, it belongs at the team level as an aggregate KR — not duplicated as a KR under each contributing product.
2. Would two PMs both claim credit for the same movement in this number? If yes, split it — one PM owns the KR outright, the others get a leading indicator they can point to without owning the target.
3. Does hitting this KR require another product's KR to move first? If they're causally linked, sequence them rather than run them in parallel — the second team shouldn't set a target it can't reach until the first one delivers.

A metric belongs to one product. If two PMs can both point to the same KR and claim credit for it, it isn't a KR yet — it's a debate waiting to happen.

This is the same discipline Kaplan and Norton built into the Balanced Scorecard decades ago: metrics cascade through cause-and-effect chains, but each one has a single accountable owner at each level, not a shared blur of partial credit. Google's own internal OKR guidance — the scoring convention where 0.6–0.7 out of 1.0 signals a well-calibrated stretch goal — only works if the number being scored is unambiguously one team's to move. Overlapping ownership is what breaks that calibration; teams sandbag or inflate targets once they suspect their score depends on someone else's execution.

Avoiding double-counting is also a standards problem, not just a math problem — it requires the whole team to define KRs the same way without you dictating every metric yourself. That's the same tension covered in setting product standards without becoming the bottleneck: give PMs a shared template and a review checkpoint, not a rule for every number.

A common variant of this trap shows up at renewal time: Payments and Onboarding both propose an "improve retention" KR because retention is genuinely something both teams influence. Rather than letting both claim it, split the causal chain — Onboarding owns the leading indicator (time-to-first-value, since that's what it can actually move in a quarter), and retention itself becomes the team-level aggregate KR that both feed without either owning outright.

A Worked Example: Cascading One Team Objective Into Three Non-Overlapping Product KRs

Take a group PM overseeing three products inside a B2B SaaS platform: Payments, Onboarding, and an Analytics add-on. The team objective: "Become the platform our customers expand into, not just the one they started with." That's genuinely a team-level statement — no single product can prove platform-wide expansion on its own.

Cascading it well means each product gets an outcome KR that is a distinct, non-overlapping lever on that objective, plus one true aggregate KR that lives above all three:

Notice what makes this non-overlapping:

• Payments owns churn caused by payment failure — a specific, defensible slice, not "reduce overall churn," which would collide with Onboarding and Analytics the moment either of them also touched retention.
• Onboarding owns time-to-value for new customers, a metric Payments and Analytics have no lever over and no reason to claim.
• Analytics owns expansion into a second product, the direct mechanism behind the team-level KR without literally being the same number — the team KR aggregates expansion across all three products, while Analytics' own KR is its specific contribution to that aggregate.

Run each of these through the three-question test from the section above and none of them fail: each is driven primarily by one product, no two PMs could plausibly claim the same movement, and none depends on another product's KR moving first.

The one output KR in the table is deliberate, not an oversight: a shared event pipeline is genuinely an enablement dependency no single product PM can build alone, and it has a hard technical deadline rather than a customer-behavior target. That's the exception case from the section above — legitimate, but rare, and clearly labeled as infrastructure rather than dressed up as an outcome.

If you're running this cascade conversation for the first time, expect it to feel like you're managing less and enabling more. That shift is exactly what's covered in moving from doing the work yourself to enabling a team of PMs to do it — writing non-overlapping KRs is one of the more concrete places it shows up.

Where a Portfolio View Helps You See the Ladder

Holding this whole cascade in your head — three products, their outcome KRs, the aggregate team KR, and the exclusivity map that keeps them from colliding — gets genuinely hard past two or three products, especially once each PM is iterating on their own numbers weekly. This is precisely the reasoning problem a portfolio view is meant to support: one place that holds every product's goals side by side instead of scattered across separate docs and slide decks.

Prodinja's Workspaces view is designed to hold multiple product areas together as cards in one place, so you can reason about how each product's outcomes ladder into a single team-level goal rather than reconstructing that map from memory every planning cycle. It won't make the exclusivity-mapping judgment call for you — deciding which PM owns which metric is still yours to make — but it's built to keep the cascade visible as you make it, instead of buried across five separate documents.

Key Takeaways

• Write the team objective one level above any single product's reach — if one PM could hit it alone, it belongs at their level, not the team's.
• Separate outcome KRs (behavior changed) from output KRs (something shipped) and default to outcomes; keep output KRs rare and explicitly justified.
• Build an exclusivity map before finalizing KRs — every candidate metric gets exactly one owning product, with everyone else demoted to a leading indicator.
• Use health metrics to watch, not to chase — support volume, NPS, and similar vital signs belong on a dashboard, not in your quarter's KR slots.
• A true team-level KR is an aggregate no single product can move alone — like cross-product adoption — distinct from any one product's own outcome KR.
• Sequence causally linked KRs rather than running them in parallel when one product's result depends on another product shipping first.
• Expect this to feel like less control, not more — a well-cascaded set of team OKRs means your PMs own their numbers and you own the shape of the ladder.