A Practical Guide to Using OKRs in Product Management

In this hands-on guide, I will show you how to make the most out of using OKRs when you’re working in Product Management.

These are the exact techniques that I use to help Product Teams around the globe to go from setting goals “the Google way” to taking an individual approach that allows them to focus on Outcomes and build better products.

In this in-depth guide, you’ll learn:

• The fundamentals about using OKRs from a Product Management perspective
• How to collaborate with your Product Team to define meaningful OKRs that represent the success of your product in the form of Outcomes and that are easy to measure
• How to successfully use OKRs in Product Management practices like Product Strategy, Product Roadmaps, Product Discovery, and Scrum.

If you’ve ever wondered how you can connect Product Strategy and your Product Discovery/Delivery efforts through Outcome-oriented goals, you’ve come to the right place.

Let’s get started.

Introduction

In recent years, a growing number of product companies started adopting Objectives and Key Results (OKRs) to set their goals. For Product Managers, that’s great news because OKRs help you create more focus and align your efforts with the whole company. At least, in theory.

But in real life, I have seen companies struggling with issues like:

• Preplanned OKR sets that specify features and leave no room for Product Managers to focus on behavior changes
• Product Managers, who ask themselves how OKRs can be beneficial during Product Discovery and Delivery adding processes and meetings
• Understanding how OKRs, Product Strategy, Product Discovery, Product Roadmaps, and Scrum influence one another.

Do these challenges sound familiar? If so, you will find answers and practical examples for overcoming them in this helpful guide to using OKRs in Product Management.

Finding success through using Objectives and Key Results (OKRs) doesn’t depend on just the type, quality, and choice of your chosen metrics, but even more on how you use them.

Product Teams certainly spend a significant amount of time with their heads down, focusing on Product Discovery or Delivery. But when they look up to seek guidance for their next move, they shouldn’t just be presented with a list of features and release dates.

That’s what differentiates the effective real-life usage of OKRs from blindly following someone else’s playbook and “best practices.”

Content Overview

The Fundamentals of OKRs
From a Product Management Perspective

What are the benefits of using OKRs in Product Management? 🔗

An Objective is like a mission statement, only for a shorter period of time. A great Objective inspires the team, is hard (but not impossible) to accomplish in a set time frame, and can be done by the person or people who have set it, independently.

Key Results take all that inspirational language and quantify it. You create them by asking a couple of simple questions: How would we know if we met our Objective? What numbers would change? A company should have two to five Key Results per Objective. In general, Key Results (KRs) can be based on anything you can measure.

OKRs in Product Management Definition

If you select your Key Results wisely, you can balance forces like growth and performance, or revenue and quality, by making sure you have both the potentially opposing forces represented.

Here’s an example of a balanced OKR set:

• Objective: We are an integrated and mature platform solution.
• Key Result 1: Our Enterprise client satisfaction rate is > 75 percent.
• Key Result 2: No sales pitch is lost through “immaturity of the product.”
• Key Result 3: 100 percent of interviewees associate our website with the terms enterprise, trustworthy, and capable.

But this only describes the technical side of OKRs. What we mean when we talk about Objectives and Key Results and how they compare to other goal-setting frameworks like NCTs. But from my work with product organizations around the globe, I have landed on three attributes that are much more telling if OKRs are effective–Beyond the by-the-book definitions.

1. A rooting in proven evidence or explicit explorative goals 

OKRs are about focus. And to create focus, teams need a clear line of reasoning for why a certain OKR is worth their attention over the everyday business. This reasoning means that great Outcome OKRs don't automatically appear. Product Teams either need access to strong evidence about the required changes in behavior in their target audience (internal or external) OR can use OKRs to structure and track explorative Product Discovery activities.

We’ll talk more about Outcome versus Output OKRs later. For Product Teams, it means focusing on the (most critical) problems first to reach their (ambitious) Key Results.

Outcome OKRs don’t talk about features. Instead, they shift the conversation to the impact a team should seek to make, as opposed to the number of released features.

2. High Relevancy for the everyday decision-making

It doesn't matter how perfect of an Outcome your Key Results are or how well they align with the company OKRs; if the changes (or lack thereof) of the Key Results don't influence what a team is doing, they are useless. OKRs that can only change in hindsight or that describe goals outside of a team's influence don't provide tangible for a team's way of working.

OKRs don't need to cover ALL of your work (everybody knows some maintenance work can be critical), but they should reflect what's most important for your team.

3. A clear connection to Company Priorities through OKRs or Strategy

The process of defining OKRs should involve all levels of a company. Though it’s natural that a leadership team sets the company-level OKRs, the next step is to get the rest of the company on board.

That’s how a single team gets inspired by the company’s overall direction to define their contribution in the form of a matching OKR. Making the OKR definition and review a focused effort for the entire company at the beginning or end of a quarter reduces misunderstandings across teams significantly.

How are OKRs different from Product Strategy? 🔗

Product Strategy and OKRs share a common attribute: Guide product teams to help make the right decisions to progress across the various levels of a company. While Product Strategy outlines the broader efforts to move closer to the long-term Product Vision, OKRs implement specific aspects of the Product Strategy throughout short cycles like a quarter.

A concept I like to call the Product Strategy-Metrics Sandwich describes the relationship between Product Strategy and OKRs tangibly:

Product Strategy articulates the core choices and trade-offs along a few shared patterns, independent of the framework or canvas you're using:

• The Strategic Narrative creates the WHY around your other choices. The Strategic Narrative consists of your Vision, Principles, and mid-to-long-term goals to provide this context.

• The Playing Field describes the market you want o focus on, including internal and external audiences, their most pressing jobs, and the alternatives they can use today to get these jobs done.

• The Winning Moves outline the choices you need to make to position your product to the best advantage on this playing field. It includes distribution channels, value propositions, offerings, and your best chances to differentiate from your competitors.

The specific choices along these patterns' lines then serve as critical input for a Product Team's OKR definition. In essence, you try to answer the question "How would success look like?" for your choices. These choices then lead to specific Key Results that help the team assess if their tactics and actions help them understand if their strategy has worked.

Below is an example of a fictional mental fitness product area within a larger digital health company.

In my Path to Product Strategy Course, you can learn more about how to shape and articulate your Product Strategy and connect it to the usage of OKRs and Product Discovery.

The OKR Cycle for Product Teams 🔗

The “common understanding” regarding the length of an OKR cycle is one quarter, but there’s no written rule about that. Depending on how your company operates (b2c versus b2b) or what other dependencies might play a role (i.e., fiscal year schedule), you should feel free to adapt the length of your cycle.

While keeping in mind that you want to adjust your actions based on the progress toward your goals, you should pick a length that allows for measuring change to chosen Key Results without spanning unnecessarily long time horizons that are too hard to predict.

In addition to setting up a cycle for success through collaborative, Outcome-focused goals through OKRs at the beginning, one of the main benefits of using OKRs should come from regular check-ins. You can achieve a feeling of surprise at the end of a cycle when the carefully crafted goals haven’t been reached, and a team’s actions didn’t adjust to that without using OKRs.

Don’t feel surprised at the end of a cycle if the carefully crafted goals haven’t been reached, but you also didn’t regularly revisit them and adjust your actions accordingly.

Throughout the OKR cycle, you want to explicitly check the progress of each Key Result on a weekly or biweekly basis while making hard choices about which actions matter to make progress (and which ones don’t).

It’s not just a box to tick off; it’s THE opportunity to adjust your actions.

We’ll talk later about the dependency of your OKR cycle cadence to other disciplines like Product Discovery.

Starting with the WHY behind using OKRs 🔗

As with all frameworks, there is no one “right way” of using OKRs. But, there are better practices for shaping OKRs based on the individual context of your company and team (i.e., skills, structures, incentives, etc.). The way you implement OKRs in Product Management should be set through a system derived from the desired benefits your team or company expects from adopting OKRs.

The way you implement OKRs in Product Management should be set through a system that is derived from the desired benefits your team or company expects from adopting OKRs.

Starting with the WHY can be a decisive first step. Within your Product Team or Product Management community of practice, you can get started with these questions:

• What does the organization we want look like? What are the common themes?
• Why do we want to work with OKRs?
• What do we want to achieve with OKRs, specifically in Product Management?

Once you have landed on a set of changes you want to achieve by using OKRs, start measuring it. Don’t try to reinvent your organization overnight, though. Instead, focus your first efforts on the most important ones. Are OKRs primarily a way for you to enable more transparency about progress and success? Or to enhance collaboration within a Product Team? Or is a shift toward Outcomes your absolute priority?

Breaking down the target further will make it more realistic and help you adjust your OKR process without making it feel like an overwhelming catalog of meetings, routines, and requirements.

But these initial WHY questions should also inform the initial MVP for your OKR System. Without getting stuck with analysis paralysis, some critical aspects of how you want to get started should be in place:

• Will you start with a pilot team? If yes, which team?
• Who will take on the responsibility for facilitating the OKR process and guiding the team through their drafting and check-ins?
• What is the process for decision-making? Completely bottom-up and democratic? With a veto right by the team lead? Through top-down instructions by company management?
• What aspects of a team's work do you plan to cover through OKRs?
• Is the measuring and reflection of OKRs integrated into existing routines and tools? If yes, how and who takes care of it?

You can expand your OKR system over time as you expand and reflect on your OKR adoption.

In my Outcome OKRs for Product Teams Course, you will learn what it takes to make OKRs a useful practice for product teams beyond rigid by-the-book approaches. I walk you through a conscious adoption of OKRs ranging from a clear WHY all the way to the tactical connections of everyday Product Management.

How to define OKRs in Product Management

Capturing a holistic view of your Product’s success through Key Results 🔗

Answering the question “How does success for our product look at the end of this cycle?” can be difficult if a Product Team lacks tangible guidance. After all, granting the autonomy to define OKRs from the bottom up doesn’t automatically clarify what should come next.

That’s why it’s the responsibility of the Product Team to either demand access to or create the inputs required for the definition of their OKR sets.

These inputs can include (but are not limited to) elements like:

• Quarterly or yearly company/department OKR sets
• Company Purpose and Vision
• Product Vision and Product Strategy
• Previous OKR sets and existing Theme-based Product Roadmap elements
• Product Discovery Insights in the form of proven user problems or validated solutions

The quality or lack of these inputs can often reveal significant flaws in a team or company. How can you expect articulated Key Results containing what should be achieved, instead of what should be done, if a team doesn’t have the possibility or skills to interact with users through Product Discovery directly? 

How should a team name their contribution to business goals if there’s no clarity about where the company is headed? And how can you expect defined OKRs to match cross-team priorities if there’s no alignment and communication about agreed high-level initiatives?

Though each of these inputs brings benefits to the table, I have seen the absence of a Product Strategy as the most harmful. I would even say that if you don’t have a clear and tangible Product Strategy, it does not make sense to use OKRs.

If you don’t have a clear and tangible Product Strategy, it does not make sense to use OKRs.

The inputs listed above are not an exhaustive list every team has to complete before they are “allowed” to draft their OKRs. Furthermore, these should serve as orientation for the required clarity that informs the quality of the defined OKR sets. If one or more of these are missing, simply prioritize completing the puzzle until the next cycle to improve your way of working. But there's certainly a strong correlation between the quality of your OKR definition inputs and the usefulness of your resulting OKR sets.

As mentioned earlier, defining the success of a product through Key Results shouldn’t just be a list of all the same performance-driven KPIs you measure already. Instead, use the idea of Key Results to define how success would look from as many angles as possible.

There’s nothing wrong with starting your OKR definition process by focusing on already established performance indicators like revenue or growth. But don’t stop there; challenge yourself to think about other measurable expressions of your product’s success.

Exemplary metrics suited to represent holistic success could be:

• A product’s or service’s conversion rate
• Customer satisfaction in the form of NPS or a similar methodology
• Product reviews from platforms like G2 or the App Store
• The number of new users completing an onboarding sequence
• Changes in behavior from the sales team like the number of necessary follow-up calls or steps to perform a product demonstration
• Results generated through User Testing Sessions or other Experiments
• Churn or retention metrics indicating customer preferences through behavior

How to set up the definition of meaningful OKRs with your Product Team 🔗

Defining OKRs in Product Management should be a collaborative practice. One that includes all (ideally) cross-functional team members to make sure the OKR definition is based on the capabilities and commitments of the people “doing the work.”

A practical setup comes in the form of a workshop. Ideally, a dedicated facilitator guides the team through the process, so domain experts like the product manager(s), designers, or engineers can focus on the content.

Before jumping straight into writing and sharing ideas for individual Objectives or Key Results, everyone should be on the same page regarding the context of the next cycle. That means the facilitator sets the stage by revisiting all existing and relevant inputs. Ideally, the owners of any of these inputs are present during this phase as well. That way, the intent of, let’s say, company OKRs isn’t lost through proxies and misinterpretation.

Before jumping straight into writing and sharing ideas for individual Objectives or Key Results, everyone should be on the same page regarding the context of the next cycle.

Here's the issue the issue with conventional wisdom suggesting a linear path: Have the participants define the qualitative Objective first, and only then have them draft quantitative Key Results.

This linear path of OKR definition does not always lead to the most OKR Set. Since articulating a concise, inspiring, and positive Objective is more Art than science, I see a lot of teams get stuck at this “first” level of the OKR definition. Is sticking to a given order more important than making progress when drafting OKRs? I don’t think it is; hence more Product Teams should adopt a non-linear path to drafting OKRs.

The main thing to pay attention to is whether you’re coming up with ideas that match your OKR WHY and the current level of discussion.

The Danger of “trickling down” Key Results throughout Cascades 🔗

Though there’s nothing inherently wrong with different OKR cascades within a company, these pieces of advice make things a lot easier:

1. Less is more: Reduce the number of cascades as much as possible. Though company-level OKR sets can provide crucial guidance, department OKRs rarely do and instead only limit the Product Team to focus on Outputs, not Outcomes.
2. Weak links, not strong ties: While company or department-level OKRs are a relevant input for the OKR definition, there’s a common myth that any Key Results of a higher-level OKR set need to be synonymous with the Objectives of the team’s OKR sets.

Avoid narrowing the corridor for the team-level OKR definitions, which would contradict the idea of bottom-up Outcome OKRs defined by the Product Team.

Differentiating Outcome and Output OKR sets 🔗

There’s a common misbelief that OKRs come with “built-in” Outcomes. Setting goals this way will automatically limit your discussion to fewer solutions, i.e., Outputs.

Before we go further, let’s go over what I mean when I talk about Outcomes and Outputs.

To me, an Outcome describes a measurable change in behavior that contributes to an Impact. (This definition is inspired by Josh Seiden’s excellent book Outcomes Over Outputs.)

An Outcome is a change in human behavior that creates an Impact.

An Output, on the other hand, is an artifact that has been delivered through activities. It’s one way of creating this behavior change, whether for customers, users, or internal stakeholders.

OKRs can work with either Outcomes or Outputs. As with every framework, the benefits of OKRs highly depend on how you use them. It’s certainly possible to set some or all of your Key Results as Outputs. In some instances, this might even be a better way to get started. Some teams get stuck in the Key Results definition process because they try to turn everything into an Outcome—just for the sake of it.

For Product Teams, being aware of the difference between Output and Outcome OKRs is an essential first step to drastically improving the definition of their OKRs. Realizing whether they are already talking about solutions or are still focused on articulating the changes in behavior, Product Teams aim to create a big difference for their continued use of OKRs.

Here’s a practical example of how Outcome OKR and Output OKR sets might differ:

As we will discuss later, there’s more to shifting to Outcome-based OKRs in Product Management than merely defining more “Outcome-ish” Key Results simply.

Balancing specific and responsive OKRs by picking the right leading or lagging indicators 🔗

As mentioned earlier, one of the most desired benefits of using OKRs in Product Management is the capability to help Product Teams measure progress and adjust their actions accordingly.

But to achieve that benefit, Product Teams need to pay attention to more than just their focus on Outcomes or Outputs. Though it’s aspirational to aim to describe a change in behavior instead of a completed task, this can lead to a lag between your prioritized actions and measurable results. It’s ok if your more action-oriented Key Results are not perfect “by the book,” but they enable you to make choices instead of having to wait until the end of a cycle to notice a change in your Key Results.

It’s ok if your more action-oriented Key Results are not perfect “by the book,” but they enable you to make choices instead of having to wait.

This concept is referred to as leading and lagging indicators, and in my experience, it’s one of the most overlooked criteria for selecting drafted Key Results to measure progress.

By the time company revenue or user growth has changed in a significant way, you can’t tie these lagging indicators to one of your last efforts and are probably already working on the next one.

If you don’t want to default to using Outputs as your main success criteria, you need metrics that LEAD teams toward creating and measuring success, which brings us to leading indicators. Below is an exemplary reverse-engineering of a lagging indicator based on the previous example for a mental fitness product area:

Here’s the critical question for defining leading indicators:

 “Which customer behaviors do we need to encourage to achieve our business goal?“

The core idea of leading indicators is to help Product Teams measure their success and progress within a given (goal) cycle. This means that you might have to experiment with the level of behavior changes you can measure and influence within a given time frame.

Leading indicators are not all that matter. After all, your company still mostly cares about those lagging metrics. But leading indicators—like changes in customer or user behavior—help you to predict your contribution to the company impact. They increase (or decrease) your confidence in pursuing an identified problem space.

At least to a certain degree. This comes back to the idea that you need to understand which solved problems and user behaviors will ultimately lead to achieving the business’ overarching goals and use these as a starting point for defining your Product Team–level OKRs.

Using OKRs to Guide the Everyday
Decision-making in Product Management

Before we talk about the specific tactics of increasing our defined OKRs in Product Management practices, it’s worth taking a step back to understand the bigger picture.

The Product Vision and Product Strategy guide the long-term WHYs. Why does my company exist? What do I stand for? Why do I have a right to win in the market I have chosen to compete in? From this, the quarterly OKRs can be derived, representing a miniature version of this larger WHY which can also be called a “strategy in a nutshell.”

OKRs are a “strategy in a nutshell” for individual Product Teams, helping connect short- and mid-term priorities to the overarching WHY.

In contrast, there is also the WHAT, which is represented by the concrete Product Roadmap themes, Discovery priorities, and activities, as well as individual user stories and tasks. Themes and Discovery priorities often cover a medium-term time horizon. They usually describe larger chunks of work or specific features that come with a longer lead time until they impact users of the business. On the other hand, user stories and tasks have a shorter lead time because they are part of short development cycles, i.e., Scrum sprints.

Making sure OKRs and Product Roadmaps don’t create a parallel universe 🔗

In the context of OKRs, the role of Product Roadmaps are one of the few essential artifacts as both an input for the OKR drafting and Output to communicate the chosen priorities needed to achieve drafted and committed OKR sets.

Of course, not all Roadmaps are created equal. The most common interpretation of a Product Roadmap tries to beat the uncertainty of the future with more rigid and prescriptive features and shipping dates. It’s commonly referred to as a Feature-based Roadmap.

Considering that a Roadmap is a vital input for the OKR drafting process, it should be no surprise that the Feature-based Roadmap is more of  an obstacle than an enabler of Outcome OKRs for Product Teams.

A feature-based Roadmap is more of an obstacle than an enabler of Outcome OKRs for Product Teams.

A more flexible approach that balances guidance with the autonomy to make decisions about the specific activities and solutions to pursue is called the Theme-based—or Now/Next/Later—Roadmap. It works with rather loosely defined time horizons that can, if necessary, be mapped to a current OKR cycle, the next one, and/or everything beyond.

Product Management OKRs and Theme-based Product Roadmaps play nicely together before and right after you have committed and aligned OKR sets, e.g., quarterly. You don’t need to turn Key Results into release dates and Gantt charts right away. Instead, the themes from the Roadmap inform your OKR priorities and vice versa.

You don’t need to turn Key Results into release dates and Gantt charts right away. Instead, the themes from the Roadmap inform your OKR priorities and vice versa.

It’s also not about choosing between themes OR Epics at this point. A Theme-based Roadmap also incorporates the Epics (IF identified through Product Discovery).

But what if you haven’t done the Product Discovery work to decide which Epic to pursue? Then there’s little to no point in using Outcome OKRs in the first place. You could have just tasked teams with building “this thing.”

How can Product Discovery and OKRs influence each other? 🔗

Product Discovery describes the iterative way of collaboratively answering two key questions:

1. Why is this a problem worth solving?
2. What solutions are worth pursuing?

As mentioned, Product Discovery works excellently in combination with Theme-based Roadmaps. This encourages your Product Team to think about Outcomes instead of settling on detailed feature ideas right from the start.

But there are also challenges when using OKRs in Product Discovery. For one, there’s the aspect of timing: When you have defined your OKR at the beginning of the quarter, then embark on an (exemplary) six-week Discovery phase, you have hardly enough time left to make an impact with what you’re building. 

Remember that shipped features sometimes need weeks in customers’ hands before they cause a change in behavior and, thereby, metrics.

When you’re in the process of reducing uncertainty about both the problem and the solution space, it’s more difficult to anticipate what specific user behaviors might be worth changing. But that does not mean that you cannot measure the progress and success of your Discovery efforts.

In my Adaptable Product Discovery Course, you can learn more about how to apply a broad range of Discovery techniques to collaboratively reduce uncertainty about assumed problems and feature ideas.

Making working in the Problem Space visible through OKRs 🔗

In short, I believe that you have two (viable) options to use OKRs in those scenarios:

First, you could emphasize the process. While a particular way of ’doing things’ is never a guarantee for the ultimate results you’re aiming for, it can be a helpful leading indicator for staying on track. This type of KRs aims to set thresholds for how your way of working might have to change.

Examples could include:

• Number of user interactions or workshops conducted (Output)
• A particular share of quantitative or qualitative efforts as part of your research and experimentation activities (Outcome)
• Specific cycle times of how the Product Team interacts with users or tests ideas (Outcome)

The second type of OKRs is about measuring user behaviors that indicate the future success of your product. For this type of KRs to be meaningful, you probably should have a rough idea of how your Discovery might unfold. You want to pick metrics that help you understand whether the most critical assumptions about your feature idea are accurate. 

Examples could include:

• Success/completion rates of usability tests
• Customer effort score in prototype testing
• Open Rate and CTR from marketing or experiment emails
• Opt-in/Opt-out rates out beta programs

I recommend investing in these types of exploratory Key Results when you use OKRs to structure your work during Product Discovery or while your product is still in stealth mode. It is also helpful to rethink your OKR cycle length. Three months might be too long and difficult to predict, depending on your stage.

By agreeing on and regularly revisiting exploratory Discovery OKRs, Product Teams can raise awareness for this (often unseen) part of their work.

Keep in mind that the primary job of a Product Discovery OKR is to make Product Discovery work a visible priority for your team. It doesn’t need to be the perfect incarnation of existing OKR blueprints.

For more insights, check out this video in which I break down the different key phased of Product Discovery as a range of options Product Teams can choose:

Combining OKRs with Scrum Practices and Routines 🔗

When it comes to Product Delivery, you need to ensure that as many items as possible in your product backlog can be associated with an OKR. That is the only way to connect your team’s everyday tasks with the higher goals of the organization. If you’re using JIRA for managing your user stories and Agile processes, you can easily integrate this OKR connection through a set of custom fields.

Of course, the same approach works for other task management tools like Asana, Trello, or monday.com. The critical point is that you establish a temporary link between individual tasks and an OKR to make all team members’ contributions (and thereby their meaning) clear.

In my talk “OKR:  3 Letters for Effective Product Organizations” at the 2019 Product Management Festival Europe, I shared more insights on how Product Teams can utilize OKRs for their daily work:

Takeaway: Finding Your Path Toward Focusing on Product Management Outcomes Using OKRs 🔗

One of the biggest challenges Product Teams face when making OKRs a valuable tool for amplifying their existing practices is not necessarily the complexity of the methodology itself. Instead, it’s the rigidness of how the usage of OKRs is promoted and touted elsewhere and a lacking iteration and adaptation mindset in most teams.

These include Google’s, now infamous, OKR Video, how to-guides for the “right OKR,” an increasingly present dogma of Outcomes being “the only right way” to use OKRs, and a seemingly overwhelming amount of OKR examples to choose from for your next goal cycle.

In addition to needing  clarity about the intentions behind using OKRs, a regular practice of reflection, and adaptation to using them, Product Teams need to be willing to begin from an imperfect starting point. Though a sole focus on Outcomes is an inspiring aspiration, chances are that it will take more than just “better” OKR drafting questions to achieve it.

For every Product Team that gets discouraged by an over-glorified definition of Outcomes, there should be at least one that is not held back and instead gets at it.

Don’t follow a prescribed OKR approach others came up with. You have the unfair advantage of knowing what your organization and Product Management work and ethical requirements are. Use that advantage to find your approach.