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 has 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. 
 
A big thanks at this point 
to Sonja Mewes, Founder 
and OKR Coach at 
Beautiful Future for the 
opportunity to 
collaborate on this topic. 
 
 
 
 
 
 
 
 
 
   

 
 
How to combine OKR and Agile Product Management 

1 
What’s in this guide 

OKR - Agile Goals for your Organisation 

More focus 

More autonomy 

More alignment 

Layers of Product Execution 

Planning with Roadmaps 

Setting up a Product Discovery Process 

Iterating through the Product Delivery Cycle 

Playing together - Dual Track Agile 

Connecting the Dots 

Combining OKR and SCRUM Routines 

Integrating OKR into your Product Roadmap Process 

Utilizing OKR in Product Discovery 

OKR Examples for Product Managers 

OKR for Remote Teams 

Key Takeaways 

What to do next 

 
 
How to combine OKR and Agile Product Management 

2 
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. Do 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 
 
   

 
 
How to combine OKR and Agile Product Management 

3 
The 'invention' of OKR is often-times credited to Andy Grove during his 
time at Intel. Later on, it got popularized through the widespread 
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 necessarily 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. 

   

 
 
How to combine OKR and Agile Product Management 

4 
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." 

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 focused 
effort for the entire company at the beginning/end of a quarter, 
misunderstandings about interdependencies and priorities across teams 
get reduced significantly. 
 

 
 
How to combine OKR and Agile Product Management 

5 
The full Objectives and Key Results cycle for Agile goal setting 
 
 
 
Watch the FREE Webinar 'Combining OKR and Product Execution' I 
co-hosted with Sonja Mewes, Founder and Lead OKR Consultant at 
Beautiful Future​: 
 

 
 

 
 
How to combine OKR and Agile Product Management 

6 
Layers of Product Execution 
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 
execution process: 
 
1. Planning​ - Working with Themes instead of time-based roadmaps 

2. Discovery​ - Determining what to actually build in order to solve a 

customer problem 

3. Delivery​ - The actual process of building the product, which 

focusses on the iterative development based on tasks and user 
stories 

Let's take a closer look at what's behind every one 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 businesses 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. 
 

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

 
 
How to combine OKR and Agile Product Management 

7 
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 of 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: 
 

 
 
How to combine OKR and Agile Product Management 

8 
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): 
 

 
'Typical' Product Discovery Cycle 
 
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. 
 
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. 
   

 
 
How to combine OKR and Agile Product Management 

9 
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 U
​ ser Story Mapping​. 
 

   

 
 
How to combine OKR and Agile Product Management 

10 
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: 

'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. 

   

 
 
How to combine OKR and Agile Product Management 

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

 
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 look at the 
long-term (1 year and beyond into the future) and thereby define the WHY 
of a company. Objectives and Key Results and Agile Product Execution on 
the other side are centered around the short- to the mid-term timeline - 
Ranging from the everyday priorities all the way up to planning the 
quarterly goals.  
 

 
 
How to combine OKR and Agile Product Management 

12 
  
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. 
 

 
Linking OKR and User Stories in your Product Backlog 

 
 
How to combine OKR and Agile Product Management 

13 
 

 
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. 
 
   

 
 
How to combine OKR and Agile Product Management 

14 
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. 
   

 
 
How to combine OKR and Agile Product Management 

15 
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: 
 

 
Custom OKR impact field in JIRA issue 
 

 
OKR impact dashboard in JIRA 
Source: ​die kartenmacherei 
 

 
 
How to combine OKR and Agile Product Management 

16 
Combining OKR and SCRUM Routine​s
Next, to the previously mentioned links of your OKR from every single 
backlog item, you can also link each 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. 
   

 
 
How to combine OKR and Agile Product Management 

17 
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:

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 a 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. 
   

 
 
How to combine OKR and Agile Product Management 

18 
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. 
 

OKR and Product Discovery Cadence compared 

 

 
 
How to combine OKR and Agile Product Management 

19 
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:​ Become the most user-centered product department in 

the industry 

● 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 
 

 
 
How to combine OKR and Agile Product Management 

20 
OKR for Remote Teams
Aligning remote teams around shared goals can be quite a challenges. 
Here are some best practices and advice 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. 
 

 
 

   

 
 
How to combine OKR and Agile Product Management 

21 
Key Takeaways 
When you embark on the journey of combining Objectives and Key 
Results, here are the three things you should keep in mind for making it a 
success: 
 
● Challenge the way your roadmap planning works and pursue a 
theme-based approach to truly work with agile goals. 

● Make sure you’re integrating your OKR into every level of your 
product execution and make them visible in as many meetings and 
tools as possible. 

● Focus on defining your Key Results for impact and not already 
specific tasks. 

What to do next 
The first time I started to work with OKR in one of my teams, I quickly 
realized how valuable external support is for making this change. If you 
own the OKR process as a Product Manager/Team Lead/CEO yourself, you 
might find it hard to push the OKR of your team just to the right level. 
Instead, it’s easy to get caught up in the comfort zone. 
 
So, if you’re looking for professional support to help your team adopt OKR, 
here’s where to look: 
 
 
 
Reach out to S​ onja Mewes​, Founder, and OKR Coach at 
Beautiful Future to bring your OKR system to the next 
level. 
 
 
 
 
Hop on a ​Remote Coaching call​ with me to discuss the 
challenges of your Product Execution team and cycles. 

 
 
How to combine OKR and Agile Product Management 

22