OKRs for Product Teams: Focus on Outcomes, Not Output

Product teams are often measured by what they ship: features delivered, releases made, roadmap items completed. But shipping a feature is not the same as solving a customer's problem. OKRs give product teams a way to focus on outcomes, the changes in customer behaviour and business results that the work is supposed to create. This guide explains how to write and use OKRs for product teams, with frameworks for choosing product metrics, examples for different product stages, and how OKRs fit with discovery, roadmaps and Scrum.

Key takeaways

• Product OKRs should measure outcomes, such as customer behaviour, not output, such as features shipped.
• Frameworks such as AARRR and Google's HEART help choose meaningful product metrics.
• Good product OKRs give teams a problem to solve, not a solution to build.
• Discovery and experiments help teams find what actually moves key results.
• In Scrum, product OKRs connect to the Product Goal, and the Product Owner orders the work to achieve them.

Output versus outcome

Output is what a team produces: features, releases, pages. Outcome is the change that output causes: customers completing a task more easily, buying more often or staying longer. Output is easy to count but does not guarantee value. A team can ship ten features that nobody uses.

Output	Outcome
Ship a new onboarding flow	More new customers complete onboarding
Add three payment methods	Fewer customers abandon checkout
Build a recommendations feature	Customers buy more items per order
Redesign the mobile app	Customers use the app more often

Product OKRs should mostly describe outcomes. The features are initiatives: bets the team makes about what will create the outcome. For more on writing OKRs, see how to write good OKRs.

Empowered product teams

Marty Cagan, in his 2020 book Empowered, contrasts "feature teams", which are given features to build, with "empowered product teams", which are given problems to solve and held accountable for results. Outcome-based OKRs support the second model: leaders set the objective and key results, and the team works out the best way to achieve them. This matches Scrum, where the Developers decide how to do the work and the Product Owner is accountable for maximising the value of the product.

Choosing product metrics

AARRR, or "Pirate Metrics"

Dave McClure introduced the AARRR framework in 2007, nicknamed "Pirate Metrics" because of how the acronym sounds. It follows the customer journey through five stages:

• Acquisition: how people find the product
• Activation: whether they have a good first experience
• Retention: whether they come back
• Revenue: whether they pay
• Referral: whether they recommend it to others

It helps product teams choose key results at the stage where the product most needs improvement.

Google's HEART framework

Kerry Rodden and colleagues at Google described the HEART framework in 2010 for measuring user experience at scale:

• Happiness: user attitudes, such as satisfaction
• Engagement: how much and how often people use the product
• Adoption: new users of the product or a feature
• Retention: the rate at which existing users return
• Task success: how efficiently and effectively users complete key tasks

The framework pairs each category with goals, signals and metrics, which maps neatly onto objectives and key results.

Product OKR examples by stage

These examples are illustrations. Numbers should come from your own data.

A new product finding its market

Objective: Prove that small businesses find real value in our invoicing tool.

• Get 50 small businesses to send at least three invoices each in their first month
• Reach a 40% share of trial users still active after four weeks
• Collect and analyse 20 customer interviews about what they value most

A growing product

Objective: Make the first week with our app a success for every new customer.

• Increase onboarding completion from 55% to 75%
• Increase the share of new customers active in week two from 35% to 50%
• Reduce first-week support contacts per new customer by 30%

A mature product

Objective: Keep our most valuable customers for longer.

• Reduce monthly churn among business customers from 3% to 2%
• Increase the share of business customers using three or more features from 40% to 55%
• Raise satisfaction among business customers from 7.2 to 8.0 out of 10

Discovery, experiments and OKRs

Product teams often do not know in advance which ideas will move a key result. Product discovery, the work of learning what is worth building, helps: talking to customers, testing prototypes and running small experiments. OKRs give discovery a clear target. For example, if the key result is to raise onboarding completion, the team might interview customers who dropped out, test two simplified flows with small groups and measure which works better, before building the full solution.

Some product teams include learning-focused key results early in a new product's life, such as validating a key assumption. Over time, key results usually shift toward measurable customer and business outcomes.

Outcome-based roadmaps

Traditional roadmaps list features with dates. Many product teams now use outcome-based roadmaps that show the problems they plan to solve and the outcomes they aim for, often organised by time horizon such as now, next and later. OKRs fit well: the "now" column reflects the current quarter's objectives and key results. This gives stakeholders a clear picture of direction without promising specific features that may turn out to be the wrong answer.

Product OKRs and Scrum

In Scrum, the Product Owner is accountable for maximising the value of the product and managing the Product Backlog, including the Product Goal. Product OKRs can inform the Product Goal and give the Product Owner a clear basis for ordering the backlog. Sprint Goals are chosen to move the product toward the Product Goal, and progress on key results can be reviewed with stakeholders at the Sprint Review. See OKRs and Scrum and our complete Product Owner guide.

Working with stakeholders

Stakeholders often ask for specific features. Outcome-based OKRs help turn those requests into conversations about the problem behind them: "What would this feature achieve?" If the answer connects to a key result, the request can be considered alongside other ways to achieve the same outcome. If not, the OKR gives a clear, shared reason to say "not now". See how to manage a Product Backlog for handling requests.

Common mistakes for product teams

• Feature lists as key results: shipping becomes the goal, not solving problems.
• Vanity metrics: page views or sign-ups without activation or retention.
• Too many metrics: teams chase several numbers and move none.
• No counter-measures: engagement pushed up with tactics that annoy customers.
• Ignoring discovery: building the first idea instead of testing what actually works.
• OKRs that override the Product Owner: outcomes should guide the backlog, not dictate every item in it.

Learn more

Our complete OKR guide covers the basics, and common OKR mistakes explains what to avoid. Scrum Agile OKR Plus covers using OKRs with agile teams; it includes self-paced training and an online exam on ExamVault by CertExpert with three attempts included, and the certificate and digital badge are valid for two years. For product ownership skills, see Product Owner Plus (Associate).