Objectives and Key Results (OKR) are a powerful way to enable autonomous (product) teams while keeping a company-wide focus on building what matters. Also, while there are few 'hard' rules around how to implement OKR, there indeed are some best practices to follow when you want to see it unfold its real potential.
However, 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? What is the impact of OKR on my product roadmap? In which way can I integrate OKR into my existing Scrum routines? Moreover, 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.
If you like this article, you might wanna take a look at our hands-on 1-day training program, designed for product teams who are either already working with OKR or thinking about introducing it to their Agile processes.
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. 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 fixed it, independently. An Objective should typically check these boxes:
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?
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. Key Results take all that inspirational language and quantify it through 2-5 holistic measuring criteria.
A company should have about three Key Results for an objective. Key Results can base 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 of a 'good' OKR goes like this:
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. Also, 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:
But what does this mean, exactly?
A typical 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.
Also, while it's standard (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.
Moreover, 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.
On purpose, good OKR don't talk about features. Instead, they shift the conversation to the impact a team should seek to make, as 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 more significant 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, as opposed to being measured by the number of released features."
The process of defining OKR should involve all levels of a company. While it's natural that a leadership team sets the company level OKR, 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 contribution in the 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.
Watch the full replay of my webinar with Sonja Mewes, Founder and Lead OKR Consultant at Beautiful Future on merging the best of OKR and 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:
Let's take a closer look at what's behind each of these steps to understand the touch points of implementing Objectives and Key Results into your Agile Product Management process.
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 methods, which embrace uncertainty instead of trying to fight it with deadlines.
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 represents a more significant user or business problem you want to discover a solution (aka Epic) to reach your goals.
The three categories of a typical theme-based roadmap can be differentiated like that:
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'.
While themes give a rough direction to look at for reaching your goals, your Product Discovery process should help you at figuring out WHAT to 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):
Alignment - Focus on getting your team and stakeholders on the same page about what needs to be done, which resources are required, 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 studies to get to the bottom of things.
Ideation - In this phase, it's about becoming creative on how to solve the identified problems within your user group potentially. 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.
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 are.
Refinement - When the core value proposition of an idea has been validated, it needs to be broken down for future development. What so far has looked shiny in a design file now needs to be sliced into small and ideally independent releasable pieces. An excellent tool for achieving just that is User Story Mapping.
Ideas are worth nothing if you don't execute them properly. This phase 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 look like this:
All routines of a typical Scrum cycle can mainly 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 two 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.
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 focusses on the customer, iterative progress and cross-functional collaboration.
Every activity within a company falls into the bucket of WHY, WHAT or HOW. A company's vision, mission, and strategy, for example, looks 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.
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 to adopt both frameworks successfully, and we need to integrate them into all regular decision-making processes.
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 critical 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 your market is in, objectively. 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 essential 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 link 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 specific 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 to achieve the goals of your team defined in the OKR.
In my talk OKR – 3 Letters for Effective Product Organisations at the 2019 Product Management Festival Europe, I shared more insights on how Product Teams can utilize OKR for their daily work:
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"
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?
When your company is still stuck in static yearly roadmap processes, you will soon encounter a (typical) 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:
While the repetitive steps of Product Delivery allow for a more likely 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.
Objectives and Key Results only complement Agile if you're able to focus your Key Results on Outcomes and integrate OKR into your existing tools and routines.
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 current 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 the focus for her Product Discovery efforts.
One of the biggest fears after a quarter is what happens to previous focus topics? Will the key results we focussed on so far start to plummet due to new OKR? Health metrics are a great way to tackle that concern.
Health metrics can e.g. be one of the themes you cared most about in the past quarter while keeping track of them using a simple traffic light grading.
Health metrics can be a great addition to your OKR to avoid setting up too many OKR. Instead of trying to cover all aspects of your business with an OKR, only focus on the ones which really matter (rarely more than 3 for a quarter/team). Everything else can be measured on a less granular level using health metrics.
But don't confuse a "red" grading of a health metric with a shift of focus. If you would stop working on OKR to improve a health metric, it probably should have been an OKR. Tasks to influence your health metrics should accompany your main focus work. Not distract you from it.
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.
Satisfy existing enterprise clients to lay the foundation for contract renewals
Key Result 1
"0 major incidents (like blocker bugs or data-loss) per client
Key Result 2
Every requested and implemented feature gets used by the respective client at least once
Key Result 3
Establish a feedback process for enterprise clients with the average feedbing being "satisfied"
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%
Our users are excited about what we‘re building next.
Key Result 1
JIRA integration User Research, Ideation, and Validation of most promising ideas.
Key Result 2
Test three new research techniques which capture user excitement.
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
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.
Please log in again. The login page will open in a new tab. After logging in you can close it and return to this page.