Prioritizing Outcomes Across Product Teams

Prioritize outcomes across product teams with explicit criteria, dependencies and capacity, so cross-team priorities rest on evidence and strategy.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

Prioritizing outcomes across teams is the decision at the heart of outcome-driven roadmap prioritization: which of several desired results the organization will pursue first, and which teams will pursue them. Inside Outcome-Driven Roadmapping, this happens before initiatives are ranked, because ranking features under the wrong outcome is wasted effort.

The problem is focus. Hope Gurion, writing on Product Talk, quotes Richard Rumelt: "Good strategy works by focusing energy and resources on one, or a very few, pivotal objectives whose accomplishment will lead to a cascade of favorable outcomes." Most organizations generate more candidate outcomes than they can pursue. Without a shared way to rank them, every team gets a slice of every priority and none moves far.

Roman Pichler's guidance for a single product is to pursue one outcome at a time where possible, because multiple goals dilute focus, undermine teamwork and make progress harder to track (Pichler). Across several teams the equivalent is a short ranked list, with each team owning few outcomes and the dependencies between them visible.

Leadership has a defined role. Marty Cagan argues that team objectives fail when leaders treat empowerment as less management, and that leaders "need to step up and do their part to turn product strategy into action" (Team Objectives). This skill gives that leadership decision a structure: explicit criteria, independent scoring, a calibration discussion, a capacity check and a written rationale. The result is an outcome prioritization framework the organization can reuse each cycle.

How It Works

The process separates three questions that usually get mixed together. First, how valuable is each outcome if achieved? Second, how confident are we that we can achieve it? Third, what does it cost, and does anything have to happen first? Mixing them lets a vivid pitch substitute for evidence.

Value is judged against the strategy. Pichler recommends two different orderings depending on the product's life cycle stage (Product Roadmap Prioritisation). Before maturity, order goals as a logical progression toward the strategy, for example acquisition before activation before retention, taking dependencies into account. For mature products with smaller, unconnected goals, he uses cost of delay: ask how big the loss is if each goal waits, and address the largest first.

Confidence and effort can be scored with any consistent scale. Intercom's RICE model was built for project ideas: reach, impact, confidence and effort, with confidence explicitly penalizing ideas that lack data. Pichler mentions using an impact and effort metric like RICE when a workshop produces too many candidate outcomes (Pichler). The value of a score is consistency. Treat it as an input to the discussion; the final ranking is still a judgment.

The discussion needs a decision rule. Pichler's approach is a collaborative workshop that aims for consent, where nobody has a meaningful objection, with the person in charge of the product able to make the final call if agreement is not reached. He also warns against letting the highest-paid person's opinion set the order. At the cross-team level the decision owner is usually the head of product for the area.

Capacity and dependencies come last. A ranked list that ignores who can do the work is a wish list. Map each outcome to the teams that could own it, note where one outcome depends on another team's work, and cut the list where capacity runs out. Cagan notes that important problems often need several teams to collaborate, so shared outcomes should name one lead team and the contributing ones.

Step-by-Step Guide

Step 1: Collect candidate outcomes in one format

Gather the outcomes each team and stakeholder wants to pursue, and rewrite each in the same format: metric, baseline, target, timeframe, the business objective it serves and the proposing team. Merge duplicates. Reject items that are outputs rather than outcomes and send them back for rewriting. A common format is the precondition for comparing them fairly.

Step 2: Agree the criteria before scoring

Choose the criteria and how they combine before anyone scores: strategic fit, expected value, confidence based on evidence, effort and cost of delay are common choices. Decide whether to use a formula such as RICE or a simpler ordered judgment. Publish the criteria so teams can see how their proposals will be judged. Changing criteria after seeing the scores undermines trust in the result.

Step 3: Score independently

Have a small group of scorers from product, engineering, design and the business rate each outcome alone before any discussion. Independent scoring exposes disagreement that a group conversation would smooth over. Ask each scorer to note the evidence behind their confidence score. Collect the scores and highlight the outcomes where ratings diverge most.

Step 4: Calibrate in a facilitated session

Bring the scorers together and spend the time on divergent scores. Ask each side to share its evidence; often one person knows something the others do not. Use a facilitator so the person in charge of the product can focus on the decision, as Pichler recommends for outcome workshops (Pichler). Update scores only when new evidence is presented.

Step 5: Rank and check the order against strategy

Produce a ranked list from the calibrated scores, then read it as a whole. Does the order tell a coherent story toward the strategy, as Pichler asks of a roadmap in its growth stages? For a mature product, does it address the goals with the largest cost of delay first? Adjust where the ranking contradicts the strategy, and write down why.

Step 6: Apply dependencies and capacity

Assign each ranked outcome a lead team and list contributing teams. Mark dependencies, where one outcome cannot progress until another team delivers something. Walk down the list, allocating capacity, and draw a line where it runs out. Everything below the line waits for the next cycle, with a note on what would move it up.

Step 7: Publish the decision and rationale

Share the ranked list, the line, the owners and the reasoning with every team and stakeholder who proposed an outcome. Explain why the items below the line are waiting. Pichler's advice for stakeholders who insist on their priorities is to listen, then bring the request to the next roadmapping workshop instead of giving in (Product Roadmap Prioritisation).

Step 8: Re-rank on a fixed cadence

Schedule the next prioritization at the same cadence as the strategy review, commonly quarterly. Trigger an extra one when a major assumption breaks, such as a market shift or an outcome that is achieved early. Carry forward the scores and evidence so each round starts from the last decision.

Best Practices

• Rank outcomes before initiatives. Ranking solutions first locks in answers to questions nobody has prioritized.
• Keep the owned list short. Each team should own few outcomes at once, in line with Pichler's one-goal-at-a-time guidance (Pichler).
• Separate value from confidence. A valuable outcome with weak evidence may deserve a discovery slot rather than a full team.
• Name the decision owner in advance. Consent is the aim, but someone must be able to break a deadlock.
• Show the line. Stakeholders accept waiting more easily when they can see what is above them and why.
• Use team objectives. Cagan's advice is to focus on team objectives instead of separate manager or individual objectives, which pull cross-functional teams apart (Team Objectives).

Common Mistakes

• Scoring in the room: Group scoring anchors on whoever speaks first. Score independently, then discuss.
• Letting the formula decide: A composite score treats rough estimates as precise. Use it to structure the conversation and record the judgment that follows.
• Giving every team a piece of every outcome: Spreading effort thinly means no outcome moves enough to measure. Concentrate teams on a few outcomes each.
• Ignoring dependencies: An outcome ranked first but blocked by another team's backlog will stall. Check dependencies before committing.
• Deciding by seniority: When the highest-paid opinion sets the order, teams stop bringing evidence. Keep the criteria visible and ask for the evidence behind every position.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Outcome-Driven Roadmapping

Related Skills

• Defining Measurable Outcomes for Product Roadmaps
• Setting Leading and Lagging Metrics for Roadmap Outcomes
• Mapping Product Initiatives to Business Outcomes
• Building Outcome-Based Roadmap Presentations
• Running Outcome Review Ceremonies and Check-Ins
• Transitioning from Feature to Outcome-Based Roadmaps

Sources

• Hope Gurion: Product Outcomes, Not Business Outcomes
• Roman Pichler: Get the Outcomes on Your Product Roadmap Right
• Roman Pichler: Product Roadmap Prioritisation
• Marty Cagan: Team Objectives Overview
• Intercom: RICE prioritization

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.