agile3
Product Management

Outcome-Based Planning

Planning around the results you want, such as fewer support calls, instead of the features you'll ship.

2 min read · Practitioner

In 30 seconds

  • Outputs are what you ship; outcomes are what changes as a result.
  • Plans and roadmaps state outcomes and how to measure them.
  • Teams choose the outputs most likely to move the outcome.

Output vs outcome

OutputOutcome
Launch a help centreSupport calls drop 20%
Add saved addressesCheckout completion rises
Redesign onboardingMore new users active after week one

Writing outcome goals

  • Name the behaviour change, not the feature
  • Pick one metric and a target
  • Set a timeframe

Many teams express these as objectives and key results (OKRs).

What changes

Roadmaps list outcomes per period. The backlog holds options for reaching them. Sprint Reviews look at movement in the metric, not just features shipped.

Myth vs reality

Myth · Outcome planning means no feature plans.
Reality · Features still get planned; they're means, not ends.
Myth · Outcomes are too slow to measure.
Reality · Leading indicators give early signals.
Myth · Only leadership sets outcomes.
Reality · Teams can set outcomes for their area.

FAQ

How do outcomes relate to the Product Goal?

The Product Goal is often a longer-term outcome.

What if an outcome is hard to measure?

Choose a proxy metric and refine it over time.

Do stakeholders accept outcome roadmaps?

Most do once they see progress tracked against them.