How to combine Objectives and Key Results (OKR) and Agile Product Management

How to combine Objectives and Key Results (OKR) and Agile Product Management

Objectives and Key Results (OKR) are a powerful way to enable autonomous (product) teams while keeping a company-wide focus on building what matters. And while there are few 'hard' rules around how to implement OKR, there certainly are some best practices to follow when you want to see it unfold its true potential.

But when you introduce a progressive tool like OKR to an organization which is already working using Agile methodologies, you can run into some challenges: How do OKR and Epics relate? Which impact have OKR on my product roadmap? In which way can I integrate OKR into my existing Scrum routines? And what are actual good OKR for Product Managers?

So, let's take a closer look at the challenges of combining OKR and Agile Product Management - From theory, to best practices, up to integrating it into your daily life.

Tim Herbig Sonja Mewes OKR Product Management Consulting

A big thanks goes out at this point to Sonja Mewes, Founder and OKR Coach at Beautiful Future for the opportunity to collaborate on this topic.

Don’t have time to read the whole guide right now?

No worries. Let me send you a copy so you can read it when it’s convenient for you. Just let me know where to send it (takes 5 seconds):

OKR - Agile Goals for your Organisation

OKR stands for Objectives and Key Results. In short, OKR combine the best aspects of goal setting into one framework: A highly-inspiring qualitative vision and concise and measurable metrics to determine success or failure. 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 do in a set time frame, and can be done by the person or people who have set it, independently. An Objective should typically check these boxes:

  • Qualitative and inspirational
  • Time-bound
  • Actionable by the team 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 about three Key Results for an objective. Key Results can be based on anything you can measure. If you select your KRs wisely, you can balance forces like growth and performance, or revenue and quality, by making sure you have the potentially opposing forces represented.

A commonly used example for a 'good' OKR goes like this:

Objective: Launch an awesome MVP

Key Result 1: Forty percent of users come back two times in one week

Key Result 2: Recommendation score of eight

Key Result 3: Fifteen percent conversion to Premium plan

The 'invention' of OKR is often-times credited to Andy Grove during his time at Intel. Later on, it got popularized through the wide-spread implementation by Silicon Valley companies like Google. And while many admire the improvements Google was able to generate for the performance management of their employees, OKR have evolved to become much more.

The attraction of OKR for agile product teams lies nowadays in its core promise for changing the way we work:

  1. More focus
  2. More autonomy
  3. More alignment

But what does this mean, exactly?

More focus

A common cycle for OKR is a quarter. Smaller companies could combine that with a yearly OKR to let every aim at something beyond the next three months.

And while it's common (and ok) to set up to three OKR for a team per quarter, this already poses a drastic improvement in terms of being able to focus on a few key initiatives. While some stakeholders confuse 'Agile' with changing their mind every two weeks just in time for the Sprint Planning, OKR provide a continuous path to pursue throughout the entire quarter.

And even though OKR don't necessary need to cover ALL of your work (everybody knows some maintenance work can be critical), they sure should reflect what's most important for your team.

More autonomy

On purpose, good OKR don't talk about features. Instead, they shift the conversation to the impact a team should seek to make, opposed to being measured by the number of released features. For your stakeholder environment this means to delay their urge to talk with you about their feature wish list, but instead agree on a set of outcome metrics first. 

For the teams it means to focus on the (most critical) problems first for a higher chance to find a bigger lever to reach their (ambitious) Key Results.

"On purpose, good OKR don't talk about features. Instead, they shift the conversation to the impact a team should seek to make, opposed to being measured by the number of released features."

Click to Tweet

More alignment

The process of defining OKR should involve all levels of a company. While it's natural that the company level OKR are defined by a leadership team, the next step is to get the rest of the company on board.

Only through that, it's possible that a single team gets inspired by the overall direction of the company to define their own contribution in form of a matching OKR. By making the OKR definition and review a focussed effort for the entire company at the beginning/end of a quarter, misunderstandings about interdependencies and priorities across teams get reduced significantly.

OKR Alignment Process

The full Objectives and Key Results cycle for Agile goal setting


Watch my FREE Webinar 'Combining OKR and Product Execution' with Sonja Mewes, Founder and Lead OKR Consultant at Beautiful Future.


Layers of Agile Product Management

The execution of building digital products can often-times be mistaken as the simple pushing of tickets and releasing code. Instead, I want to broaden your horizon for the three levels of a sustainable Agile product management process:

  1. Planning - Working with Themes instead of time-based roadmaps
  2. Discovery - Determining what to actually build in order to solve customer problem
  3. Delivery - The actual process of building the product, which focusses on the iterative development based on tasks and user stories

Don’t have time to read the whole guide right now?

No worries. Let me send you a copy so you can read it when it’s convenient for you. Just let me know where to send it (takes 5 seconds):

Let's take a closer look at what's behind every of these steps to understand the touch points of implementing Objectives and Key Results into your Agile Product Management process.

Planning with Roadmaps

Sadly, most business still rely on time-based roadmaps following a Gantt chart style visualization for planning product development up to 12 months into the future. While this approach may have worked for the static waterfall planning we used to do 'back in the days', it's hardly suited for agile and iterative approaches, which embrace uncertainty instead of trying to fight it with deadlines.

Time-based roadmaps vs. Theme-based roadmaps

Comparing static time-based roadmaps and truly agile theme-based roadmaps

A more fitting approach for planning your efforts is based on so called theme-based roadmaps. They enable you to prioritize broader initiatives, rather than fixed feature sets and acknowledge increasing uncertainty the further you look into the future.

You can also compare themes as the parent element of specific epics. A theme simply represents a bigger user or business problem you want to discover a solution (aka Epic) for in order to reach your goals.

The three categories of a typical theme-based roadmap can be differentiated like that:

  1. Now: Stuff that you are currently working on.
  2. Next: Stuff that’s coming up soon.
  3. Later: Stuff that you’d like to work on in the future, but need to do a bit more research before you move on.

Examples for a theme could be things like 'User Growth', 'Revenue', 'Churn' or 'Enterprise'. Corresponding epics could then be 'Referral Mechanism', 'Free Trial' or 'Single Sign On'.

C. Todd Lombardo delivered a great presentation on this modern approach of building roadmaps at the Mind the Product San Francisco Conference in 2018:

Setting up a Product Discovery Process

While themes give the rough direction to look at for reaching your goals, your Product Discovery process should help you at figuring out WHAT to actually build. The term 'Discovery' should be taken quite literally here as an approach for your mindset so you remain flexible enough for which solution might emerge from your journey.

While there's no one-size-fits-all approach for THE Product Discovery, successful ones share a couple of steps you might want to work through in roughly that order (depending on your stakeholder environment and organizational structure):

Agile Product Discovery Process

'Typical' Product Discovery Cycle

Alignment - Focus on getting your team and stakeholders on the same page about what needs to be done, which resources are needed, what the actual goal is and which side effects to avoid. There are multiple frameworks available for achieving alignment but most importantly, it should be about creating autonomy for you and your team.

Research & User Problems - This is the phase where you work through existing qualitative and quantitative data to discover patterns about potential user problems or run your own studies to get to the bottom of things.

Ideation - In this phase, it's about becoming creative on how to potentially solve the identified problems within your user group. Ideation works best in a diverse group of people to avoid existing bias as much as possible and to stay open-minded.

Creation - Now it's time to make the most promising ideas more tangible. By creating scrappy high or low fidelity prototypes based on the results of your ideation session, you get a sense for how your solution(s) could look and feel like.

Validation - Before any code is written, it's about finding out how valid the created solutions are by putting them (somehow) back into the hands of your users. By using tools like usability interviews or fake landing pages, you have to determine how valuable your ideas really are.

Refinement - When the core value proposition of an idea has been validated, it needs to be broken down for the upcoming development. What so far has looked shiny in a design file now needs to be sliced into small and ideally independent releasable pieces. A great tool for achieving just that is User Story Mapping.

Iterating through the Product Delivery Cycle

Ideas are worth nothing if you don't execute them properly. This is where the part of Product Delivery comes into play. Using agile frameworks like SCRUM or Kanban, you now need to orchestrate the execution of identified and validated idea as part of a cross-functional team.

If you're e.g. using Scrum for organizing your work, the development cycle you want to set up might looks like this:

Agile Product Execution Cycle SCRUM Process

'Typical' Scrum product delivery cycle

All routines of a typical Scrum cycle can essentially be divided into two parts: Organizing the work of the current cycle and preparing what to work on next.

While the Sprint Planning is about committing the work for the next 2 weeks, the Review and Retrospective focus on what has been accomplished respectively what the team could improve. The Backlog Refinement and Feedback & Estimation meeting on the other hand, discuss the potential issues for the next sprint and ensure that there's clarity about what needs to be done and how complex these issues might be.

Don’t have time to read the whole guide right now?

No worries. Let me send you a copy so you can read it when it’s convenient for you. Just let me know where to send it (takes 5 seconds):

Playing together - Dual Track Agile

The relationship between Product Discovery and Product Execution is commonly referred to as 'Dual Track Agile' as both work streams need to adapt a mindset which is focussed on the customer, iterative progress and cross-functional collaboration.

Dual Track Agile Process

Dual Track Agile process

Connecting the Dots

Every activity within a company falls into the bucket of WHY, WHAT or HOW. A company's vision, mission and strategy for examples looks at the long-term (1 year and beyond into the future) and thereby define a the WHY of a company. Objectives and Key Results and Agile Product Execution on the other side are centered around the short- to mid-term timeline - Ranging from the everyday priorities all the way up to planning the quarterly goals. 

Company Time Horizon Comparison

How OKR and Agile product execution levels play together

Let's compare the different layers of product execution and their respective time horizon with the granularity OKR as an agile goal system offer us. It becomes clear that in order to adopt both frameworks successfully, we need to integrate them into all regular decision making processes.

Integrating OKR and Product Execution Part I

Linking OKR and User Stories in your Product Backlog

Integrating OKR and Product Execution Part II

Tracking the success of a User Story with Key Results

On the highest level, your defined and committed Objectives and Key Results can be connected with your Agile Product Management processes when creating the alignment for a specific initiative. A great framework to achieve that, is the mission briefing framework, developed by the strategy consultant Stephen Bungay. By adopting an outcome-first mindset when outlining the key tasks for your Product Discovery, you don't get ahead of yourself and instead focus on the qualitative goal defined in your existing OKR and the corresponding success criteria.

The mission briefing is a simple document, which focusses on the five essential aspects of a project:

First, write down the context your team works in - Here you should describe the situation your product and/or your market is in, in an objective way. Gather all the facts which would make an external observer understand the status quo and what change led to an initiative like yours.

Second, explain the Higher Intent - While this section is often-times seen as the place to put a CEO quote, it’s important for you as a leader to show your peers where their efforts fit in with the big picture—ie. the vision, mission, and strategy of the company. So, the (seemingly) simple question to answer here is “How does this align with our overall mission and strategy?”

Third, detail My Intent - Here’s where you motivate your peers to follow you on this journey. You want to simplify the complications of real life and enable your peers to act by giving them an overall purpose: it is an insight into the essentials. Think about how to make the link to the higher intent visible as well.

Fourth, note Key Implied Tasks - Don’t get confused by the title. It’s not about writing a step-by-step playbook for your team on how to execute this project (remember how domain experts resist people stepping into their fields?). Instead, outline what kind of outcomes your team needs to achieve along the way so that working towards them can be divided and assigned further.

Fifth, define Boundaries - Here we can add the right kind of guard rails for the creative playground we want our peers to fill. It’s about stating what we explicitly won’t do as part of this project and what is not allowed to happen as a side effect. Metrics like this are often-times also called Key Failure Indicators (KFI), which are metrics you don’t want to see go in a certain direction as part of this initiative. KFI are meant to counter the main KPI of the project for a healthy balance, ie. “Grow revenue while maintaining gross margin.”

The mission briefing is meant to frame the specific Product Discovery effort you're about to embark on in order to achieve the goals of your team defined in the OKR.

When it comes to Product Execution, you need to make sure that as many items in your product backlog can be associated with an OKR. Only through that, you enable the connection of 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. The built-in dashboards then give you a concise overview of how much work of a team has been dedicated to reaching an OKR: 

"When it comes to Product Execution, you need to make sure that as many items in your product backlog can be associated with an OKR. Only through that, you enable the connection of everyday tasks with the higher goals of the organization."

Click to Tweet
JIRA OKR Field Tracking

Custom OKR impact field in JIRA issue

JIRA OKR Dashboard

OKR impact dashboard in JIRA

Combining OKR and Scrum Routines

Next to the previously mentioned links of your OKR from every single backlog item, you can also link every of your Agile routines to your goals by tying your activities to questions which check their relevance:

Bi-weekly Sprint Planning: What are the next priorities, to make progress with our OKR?

Bi-weekly Review: Which output AND outcome did we achieve?

Bi-weekly Retrospective: How did our collaboration hold up to our norms?

Integrating OKR into your Product Roadmap Process

When your company is still stuck in static yearly roadmap processes, you will soon encounter a (common) conflict between the introduction of an Agile goal system like OKR and this type of planning. When OKR (typically) 'only' focus on one quarter, what on earth should you then put on the requested roadmap for the other nine months of the year?

One answer to this conflict is the introduction of a yearly OKR to share an overarching direction for the coming 12 months. While you keep your quarterly focus for the execution of solutions, a yearly OKR can certainly help stakeholders to relax. Even though they might not get the (perceived) security and level of detail from it like a feature-based roadmap for the entire year, you still have a rough (but more reliable) understanding of when this year will be successful.

If you put a yearly OKR next to the more dynamic theme-based roadmap approach I told you about above, these two roughly play together like this:

Yearly OKR and theme-based roadmaps

How to combine Yearly OKR and the theme-based roadmap approach

Utilizing OKR in Product Discovery

While the repetitive steps of Product Delivery allow for a more predictable use of OKR, integrating Objectives and Key Results into the more unforeseeable sequences of a Product Discovery poses some challenge.

For one, there's the aspect of timing: When you have defined your OKR at the beginning of the quarter, then embark on a (typical) 6 week discovery phase, you have hardly enough time left to make an impact with what you're building. Especially if you're considering that shipped features sometimes need weeks in the hand of customers to cause change in behavior and thereby metrics.

On the other hand, how should you decide on which area to discover, if you don't know the goals for the next quarter yet? Here's where the concept of the theme-based roadmap comes in again handy.

Because you have a rough understanding of which areas your team wants and needs to work on 'Later', you can define a Product Discovery OKR for the existing quarter. This might include Key Results like 'Understand the key needs of 10 Enterprise product prospects' as one of your themes for the following quarter is called 'Enterprise'.

This way, the Dual Track efforts of an Agile team can both be organized using OKR and the Product Manager has clarity about what to focus her Product Discovery efforts on.

Combining Product Discovery and OKR

OKR and Product Discovery Cadence compared

OKR Examples for Product Managers

Whether your organization decides to cascade OKR down to the individual level or to 'stop' at the team level, here are some specific OKR examples for Product Managers to give you a starting point for your own OKR definition process.

  • Objective: Successfully launch version 3 of our main product
  • Key Result 1: Get published product reviews in over 15 publications
  • Key Result 2: Get over 10000 new signups
  • Key Result 3: Achieve trial to paid ratio of over 50%
  • Key Result 4: Achieve sign-up to trial ratio of over 25%


  • Objective: Understand what our users and non-users really think
  • Key Result 1: Support team to conduct 50 phone interviews with churned accounts
  • Key Result 2: Design team conduct 30 web-based user testing sessions on new and old users
  • Key Result 3: Product management to interview 25 external team leaders (non-users)
  • Key Result 4: Sales team to conduct 50 phone interviews with key accounts


  • Objective: Activate user-testing of our product
  • Key Result 1: Conduct at least 21 face to face user testing & interview sessions
  • Key Result 2: Receive at least 15 video interviews from Usertesting.com

Source: okrexamples.co

OKR for Remote Teams

Aligning remote teams around shared goals can be quite a challenges. Here are some best practices and advices from a recent talk I gave at the OKR Meetup Hamburg. In it, I shared our approach for making Objectives and Key Results work in a fully distributed team setup at iridion.

Want to save this guide for later?

No worries. Let me send you a copy so you can read it when it’s convenient for you. Just let me know where to send it (takes 5 seconds):