Photo by Frank Cone on Pexels

OKRs in Product Management

Published on 1st December 2020

OKRs—objectives and key results—have experienced a renewed popularity in recent years. Consequently, I am regularly asked if and how OKRs can be applied in product management. This article shares my thoughts.

Listen to this article:

OKRs in a Nutshell

OKRs are a method for setting and tracking goals. An objective describes what is to be achieved. The key results state how we accomplish the objective. Let’s say, for example, that the objective is to “increase engagement.” The key results might then be “daily active users are up by 20%,” “session length is increased by 10% on average,” and “the objective is achieved by 30 June 2021.”

OKRs can be used to create cascading goals—goals that are systematically linked. This is done by using higher-level key results as lower-level objectives, as the following example shows.

Figure 1: Sample, cascading OKRs

In figure 1, the key result “daily active users are up by 20%” becomes an objective with two new key results, “add feature alpha” and “implement auto login” thereby connecting the two OKRs.

It’s worthwhile to note that OKRs were originally invented by Andy Grove at Intel in the 1970ies to facilitate “excellent execution,” that is, to help people set hard, measurable goals and to be able to clearly determine if these have been met. And that’s exactly how I experienced OKRs when I worked at Intel in the late 1990ies.

Goals in Product Management

As I explain in my book How to Lead in Product Management, setting the right goals is crucial to align stakeholders and development teams and to achieve product success. Does this mean that there is a natural fit between goals in product management and OKRs? In order to answer this question, let’s look at a set of product management goals. Figure 2 below shows the goals I recommend.

Cascading Product Management Goals
Figure 2: A Chain of Product-related Goals

Figure 2 contains a set of cascading goals: vision, user and business goals, product goals, and sprint goals. The vision guides the user and business goals, which are contained in the product strategy. The user and business goals help select the right product goals, which I capture on the product roadmap. A product goal, finally, helps determine the right sprint goals.

At the same token, a sprint goal is a step towards a product goal; achieving a product goal helps you make progress towards the user and business goals; and the latter two finally help you move closer towards your vision. (For a more detailed explanation of the goals above, please see my article “Leading through Shared Goals,” and if you would like to learn more about goal setting in product management, then check out my book How to Lead in Product Management.)

Let’s now explore how the goals in figure 2 can be captured as OKRs.

Capturing Product-related Goals as OKRs

Say that I’d like to offer a product that helps people eat more healthily. I could then capture the goals shown in figure 2 as OKRs in the following way:

Sample Product Management OKRs
Figure 3: Sample Product-related OKRs

There are three things in figure 3 above that I’d like to bring to your attention: First, the top-level OKRs describe vision and product strategy. The vision is the objective, and the product strategy is expressed by the key results.

Second, I have derived the product goal objective from the first and third key result of the top-level objective (as illustrated by the grey arrows). I have also used the first key result of the second objective to determine the third objective. This creates a set of cascading OKRs. I wasn’t able, however, to reuse higher-level key results as lower-level objectives, as shown in figure 1.

Third, the second OKRs are the equivalent of the first entry on a goal-oriented product roadmap. If you want to work with a roadmap that looks further ahead, you will have to add additional OKRs to the ones in figure 3.

Should You Use OKRs for Your Product?

To answer this question, let’s consider some major benefits and drawbacks of applying OKRs in product management, starting with the positives:

  • Consistency: Using OKRs means that all goals adhere to the same format. This can be particularly helpful when OKRs are widely used in the organisation and the stakeholders and development team members are familiar with the method.
  • Validation: Coupling objectives with key results can help you tell if and when a goal has been met.
  • Links: Being able to use key results as new objectives is very useful, even though I was not able to take advantage of it in the sample OKRs in figure 3.

But I also see the following drawbacks:

  • Lack of visualisation: Using OKRs to capture goals leads to a rather text-heavy approach. This feels like turning back the clock and not taking advantage of the visual product management tools developed in recent years like my product vision board and GO product roadmap or Alexander Osterwalder’s business model canvas. These tools make it easier, though, to understand, validate, and evolve a product strategy, product roadmap, and business model respectively.
  • Overuse: Objectives should be significant, concrete, and action-oriented, writes John Doerr in his book Measure What Matters. And Andy Grove pointed out that key results should be “so specific that a person knows without question whether he has completed them and done it on time or not.” While you can use OKRs to capture a vision and strategy—as I did in figure 3—it seems to me like shoehorning them into a format they don’t naturally fit into. I personally find that OKRs are best used for what they were invented for: to facilitate execution.

Should you now use OKRs? I recommend applying them if they help you set and track the relevant goals and if the they can be easily understood by the stakeholders and development teams. If you are in doubt, experiment with the goal-setting approach and see how it works for you. Make sure, though, that you stay in charge of the product and don’t allow powerful stakeholders to dictate product OKRs to you.

Post a Comment or Ask a Question


  • Liz says:

    Hi Roman, How do you set an OKR Maturity Criteria for products? What qualifies a product’s OKR to be High , Medium , Low in Maturity?

    • Roman Pichler Roman Pichler says:

      I am sorry Liz, but I honestly don’t know. As I mention in the article, I am not a fan of using OKRs in product management; and I am certainly not an expert in assessing the maturity of an organisation’s OKR practice. What matter most IMO is that the right goals are set. If these are captured as OKRs or using visual tools like my product vision board is secondary.

  • Rashmi says:

    Hi Roman,

    Thanks for sharing very helpful information as always. I wanted to validate something in terms of OKR cascade as my understanding is that OKRs downstream should align with top level OKRs not necessarily cascade. I think that is what is happening in your picture of OKRs setting at multiple levels. So the Key results for top level Objectives are a guideline for products downstream to derive their objectives. Also I also am using the format you have provided in go product roadmap where goal is translated as Objective and measures as key results. Any thoughts you can share will be much appreciated.

    • Roman Pichler Roman Pichler says:

      Thanks for your feedback and questions Rashmi. I find it helpful to ensure that lower-level goals are aligned with higher-level ones, no matter what goal-setting method is used. One way to achieve this is to use cascading goals. When you look at my goal setting framework, the vision guides the user and business goals, and the latter direct the roadmap goals, for example. Nice to hear that you work with the GO product roadmap. You can, if you want to, view the roadmap goals with objectives and the other elements are key results. Hope this helps!

  • Simeon Biedner says:

    Hi Roman, Doesn’t fit the Go Product Roadmap perfectly to OKRs? For me, it is an natural extension to the OKRs. The time frame can be the same like an OKR-Cycle (e.g.) and as mentioned above the goals are the Objectives and the Metrics are for shure the Key Results. So I think, it can be visualized great with your tools. Even a department wide overview with a version of your Portfolio Board.

    Only thing what I have to clarify for me is what do I do with goals which are not part of the OKRs for a time frame. But the more I think about it they should not be placed in the goals because they should not be important enough to be mentioned there.

    Greetings and thanks,

    • Roman Pichler Roman Pichler says:

      Thanks for your comment Simeon. I am glad that you find that there is a good fit between OKRs and the GO product roadmap. As I indicated in the article, I am personally not a big fan of using OKRs in product management. But leading through shared goals, no matter if they are formulated as OKRs or not, is a powerful practice for product people. Happy goal setting 😀

  • Joanne L Irwin says:

    When developing OKRs for Product Management, who typically drives the development of these? Is it typically Development driven, Products driven?

    • Roman Pichler Roman Pichler says:

      Thanks for sharing your question Joanna. I recommend that the person in charge of the product, the product manager or Scrum product owner, should set the OKRs in collaboration with the key stakeholders and development team representatives. This leverages the expertise of the individuals, creates shared understanding and alignment, and increase the chances that people buy into the objectives and work towards them.

  • Chris says:

    Hi Roman,

    I enjoyed listening to your podcast accompanying the blog post. It offers a nice alternative way of learning and provides personality to the post.



Leave a Reply

Your email address will not be published. Required fields are marked *

Sign up for great new content from Roman

Hear about his latest product management work including new articles, videos, podcast episodes, and more.