Outcome-Based Planning

Overview

Outcome-based planning shifts the unit of planning from features (what we will build) to outcomes (what will change as a result). It answers a different question at the planning stage: not "what will we deliver?" but "what will be different for users or the business when we are done?" This shift changes what gets prioritised, how success is measured, and how teams and stakeholders communicate about value.

For the metrics that define outcomes, see Metrics Interpretation. For testing whether a planned change achieves its intended outcome, see A/B Testing Fundamentals.

Why It Matters

Output is not value. A team that ships ten features in a quarter has produced output. Whether any of those features changed user behaviour, improved retention, or generated revenue is a separate question — and the one that actually matters.

Output-based planning produces the wrong incentives. A team measured on features shipped will ship features. A team measured on outcomes achieved will make harder decisions: invest in the features most likely to move the metric, kill features that are not working, and sometimes do nothing rather than ship something neutral.

Outcomes create shared language with stakeholders. Stakeholders do not ultimately care about features — they care about results. "We will improve first-session activation by 15% in Q3" is a commitment they can hold a team to and relate to business results. "We will ship the new onboarding flow" is a deliverable whose value remains unclear until it is measured.

Outcome-based planning enables better prioritisation trade-offs. When the question is "which of these two features moves the north star more?", the answer is at least theoretically measurable. When the question is "which of these two features is more important?", the answer is always subjective.

OKRs without outcome thinking are just goal-setting dressed up. Many teams adopt OKRs (Objectives and Key Results) and write key results that describe outputs ("ship the redesigned checkout") rather than outcomes ("increase checkout completion rate by 8%"). The framework only works if key results are genuinely measurable outcomes.

Standards & Best Practices

Outputs vs outcomes vs impacts

Clarify the hierarchy:

Planning at the output level is the default. Shifting to the outcome level requires explicitly connecting features to behaviour changes. Shifting to the impact level requires longer time horizons than most product cycles.

Outcome-based planning operates at the outcome level. Impact is tracked as a lagging signal that outcomes are compounding as expected.

OKRs: Objectives and Key Results

OKRs are the most common framework for outcome-based planning:

• Objective: A qualitative, inspirational goal that describes the desired direction ("Make checkout effortless for returning buyers")
• Key Results: 2–4 measurable, time-bound outcomes that define what success looks like ("Increase checkout completion rate from 72% to 80% by Q3")

Good key results are:

• Measurable: There is a metric and a baseline
• Time-bound: There is a specific deadline
• Outcome-focused: They describe what changed, not what was built
• Ambitious but achievable: Typically targeting 70–80% completion signals appropriate ambition

Bad key results:

• "Ship the new onboarding flow" (output)
• "Improve user experience" (not measurable)
• "Increase activation" (not specific or time-bound)
• "Achieve 100% of the roadmap" (100% OKRs signal underambition)

Connecting features to outcomes

Before adding a feature to a roadmap:

1. Name the outcome: What behaviour change do we expect this feature to produce?
2. Name the metric: Which specific metric measures that behaviour change?
3. Estimate the effect: By how much do we expect the metric to move?
4. Justify the estimate: What evidence supports that expectation? (Prior experiments, user research, analogous cases)

Features that cannot be connected to an outcome at this level of specificity are either addressing a genuine user need that has not been articulated yet (worth exploring) or are output-focused tasks masquerading as product decisions.

The bets-based roadmap

Traditional roadmaps are output plans: a list of features organised by time. A bets-based roadmap organises the quarter around a small number of explicit bets:

Bet 1: If we reduce the steps in onboarding from 5 to 3, activation will increase by ≥10% within 30 days.

Bet 2: If we add team-level reporting, average accounts per organisation will grow by 15% in Q3.

Each bet is a falsifiable hypothesis with a metric, a target, and a time window. At the end of the quarter, each bet is explicitly won, lost, or inconclusive. The bets-based roadmap makes outcome thinking visible to stakeholders — they can see exactly what the team believed and whether it was correct.

Quarterly outcome review

At the end of each quarter:

1. What were the outcomes we committed to?
2. Which were achieved? Which were missed? Which were inconclusive?
3. For missed outcomes: was the output delivered but the outcome not achieved? (Feature was built; users did not adopt it — this is a different failure mode than the feature not being shipped.)
4. What do the results imply for next quarter's priorities?

This review is the most important feedback loop in outcome-based planning. Without it, OKRs and bets are just planning documents.

How to Implement

Quarterly planning process (outcome-based)

6 weeks before quarter start:

• Review the previous quarter's outcomes: what worked, what did not?
• Identify the top 3–4 user or business problems to address next quarter

4 weeks before quarter start:

• Draft OKRs or bets for each problem area
• Connect each key result or bet to a specific metric and baseline
• Identify the features or initiatives most likely to achieve each outcome
• Estimate the effort required

2 weeks before quarter start:

• Review draft OKRs with engineering leads: are the outcomes achievable in the timeframe?
• Review with stakeholders: do the objectives align with business priorities?
• Finalise and communicate the quarter's outcomes

During the quarter:

• Track metric progress bi-weekly alongside sprint delivery
• Adjust features if early data suggests an approach is not working
• Flag risks to key results as early as possible

Feature-outcome mapping

For each feature in the backlog:

## Feature-Outcome Mapping — [Feature name]

**Feature:** [Brief description]
**Objective it serves:** [Which quarterly objective]
**Expected outcome:** [Specific behaviour change]
**Metric:** [Which metric will we track]
**Baseline:** [Current value of that metric]
**Target:** [Expected new value after feature ships]
**Measurement window:** [How long after shipping will we wait before evaluating]
**Evidence for the estimate:** [User research / prior experiments / analogous data]

Tools & Templates

OKR template

## Objective: [Inspirational, qualitative goal]

### Key Results

**KR1:** [Metric] from [baseline] to [target] by [date]

- Feature bets: [Features expected to drive this]
- Owner: [Name]

**KR2:** [Metric] from [baseline] to [target] by [date]

- Feature bets: [Features expected to drive this]
- Owner: [Name]

**KR3:** [Metric] from [baseline] to [target] by [date]

- Feature bets: [Features expected to drive this]
- Owner: [Name]

Quarterly outcome review template

## Quarterly Outcome Review — Q[N] [Year]

### Summary: [N/N] Key Results achieved

| KR    | Target   | Actual   | Status       | Notes   |
| ----- | -------- | -------- | ------------ | ------- |
| [KR1] | [target] | [actual] | ✅ / ⚠️ / ❌ | [notes] |
| [KR2] | [target] | [actual] | ✅ / ⚠️ / ❌ | [notes] |

### Retrospective

**What contributed to achieved KRs?**

- [Finding]

**What caused missed KRs?**

- [Finding: output delivered but outcome not achieved / output not delivered / metric moved in wrong direction]

**What does this imply for next quarter?**

- [Priority change or opportunity]

Common Pitfalls

Output KRs. "Ship the new dashboard" is not a key result — it is a story in a sprint. Key results must describe outcomes: what changed, by how much, by when. Teams that write output KRs get the process right and the mindset wrong.

KRs without baselines. "Improve activation" is not measurable without a starting value. Every key result must have a baseline — the current value of the metric — to define what improvement means.

100% achievement as the goal. OKRs should be ambitious. Consistently achieving 100% of key results signals that targets are too conservative. The standard is 70–80% achievement on ambitious targets, not 100% achievement on safe ones.

Disconnecting features from outcomes. Teams that plan features on a separate roadmap from OKRs produce two independent documents that do not reinforce each other. Features should be explicitly mapped to key results. If a feature cannot be connected to any key result, it is either not part of the current quarter's work or the OKRs are incomplete.

Not measuring after shipping. A feature shipped without measuring its outcome has no feedback loop. Outcome-based planning requires closing the loop: ship, measure, and report whether the expected outcome was achieved.

Blaming the metric for missed targets. When a key result is missed, the tempting explanation is that the metric was wrong, the target was unrealistic, or external factors intervened. These may all be true. But before reaching those conclusions, ask whether the features shipped actually targeted the outcome, and whether the assumed mechanism was actually valid.