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.
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):
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.”
Explore the Content
The Fundamentals of OKRs
From a Product Management Perspective
In this chapter, I want to establish a shared understanding of the importance and role of OKRs in Product Management.
Your Main Takeaways:
- The potential benefits OKRs can introduce to Product Management
- How to avoid confusing OKRs for Product Strategy and what to do instead
- The importance of establishing the WHY behind using OKRs before getting started with defining OKRs
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.
Nowadays, the appeal of OKRs for Agile Product Teams lies in its three core promises for improving the way we work.
1. A clear Focus to work on Priorities, not just whatever is “next”
Though it’s a good starting point to set up to three OKRs for a Product Team per cycle, this already poses a drastic improvement in terms of being able to focus on a few key initiatives. Although some stakeholders confuse “Agile” with changing their minds every two weeks just in time for the Sprint Planning, OKRs provide a continuous path to pursue throughout the entire quarter.
Moreover, even though OKRs don’t need to cover ALL of your work (everybody knows some maintenance work can be critical), they should reflect what’s most important for your team.
2. More team autonomy to identify the right solution
By design, Outcome OKRs don’t talk about features. Instead, they shift the conversation to the impact a team should seek to make, as opposed to measuring the number of released features.
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.
For your stakeholder environment, this means peers and management will delay talking to you about their feature wish list, but instead agree on a set of Outcome metrics first. 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.
3. More substantial vertical and horizontal alignment around drafted OKRs
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.
Tip for Practice: Anticipating Alignment Periods
Plan for an Alignment Period well before the next quarter to avoid “rush and commit” behaviors after multiple teams have drafted their OKRs.
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.
Company- and Team-Level OKR Alignment Structure
Having clarity about the expected benefits from OKRs and connecting them to the specific OKR practices of a product organization is also one of the most important aspects to avoid OKR Theater. Next, let's take a closer look at how OKRs connect to other domains of Product Management.
How are OKRs different from Product Strategy? 🔗
- What are the essential problems your product is solving for your users, and which ones do you want to address in the future?
- What alternatives could your users employ to solve that problem (i.e., direct and indirect competitors)?
- What are the core value propositions that define your product?
- What makes your product unique compared to those direct and indirect competitors?
A Product Strategy needs to highlight the gaps of the status quo to set the right priorities for achieving the future vision of the product.
The Gaps in your Product Strategy inform your OKR priorities
Product Strategy Choices are also the starting point for Product Discovery. But Product Teams shouldn’t blame it on their manager or the C-level if the Product Strategy isn’t clear. Instead, I encourage Product Teams to create clarity about their strategic direction themselves. By utilizing collaborative frameworks like the Product Field, you can outline the strategic direction of your product and identify the existing blind spots pretty quickly.
This, of course, requires a clear understanding of what a Product Strategy is about compared to, for example, a Product Vision. Check-out this video, where I’ll clearly differentiate Product Vision from Product Strategy and show how they relate to and benefit each other.
One of the most commonly communicated benefits of OKRs is their ability to bridge Strategy and Execution. But Product Management happens on different levels and nuances. This is why the usage of OKRs in Product Management shouldn’t be seen just in the context of Product Strategy and Delivery but also with the Product Vision, Product Roadmaps, and Product Discovery in mind.
Holistic Domains and Responsibilities in Modern Product Management
The disciplines within one flight level are connected, but the insights and experiences from one field flow up or down to inform the other flight levels. Because of that, the quality of each of these six disciplines radically influences how well one of the others can be implemented. When Product Strategy isn’t clear, many teams struggle when asked to “define goals for the quarter.”
Arriving at the “right” set of OKRs is a journey that requires iteration—often both within and between goal cycles. But it can get a lot easier when Product Teams have the right strategy to begin with.
Deep Dive: From Product Strategy to Actionable Goals
Learn the fundamentals of designing a Product Strategy that supports a focus on Outcomes in this free preview lesson from my “Outcome OKRs for Product Teams” course.
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.
Product Management OKR Cycle
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 your skills, priorities, and needs. 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.
How to define OKRs in Product Management
OKRs that help you and your team measure progress and focus on Outcomes require more than following “best practices.” This chapter will help you to facilitate the drafting of meaningful OKRs that work for your team.
Your Main Takeaways:
- The inputs required to capture the holistic success criteria of your product
- Differentiating Outcome and Output OKR sets
- Identifying OKRs that help measure the progress and success of your activities
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
Strategic vs. Product Team-owned Inputs for the OKR Definition
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.
Don’t fool yourself into thinking that there’s just one “right way” to arrive at OKR sets that work for your team. Though there are benefits to starting with the qualitative statement in the form of the Objective, you can also “work your way up” from Key Results or tasks.
Versatile OKR Definition Directions and Approaches
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.
Deep Dive: Drafting Outcome OKRs
My “Outcome OKRs for Product Teams” course provides all the practical strategies and templates you need for an effective OKR drafting with your Product Team.
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:
- 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.
- 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.
Strict OKR Cascades lead to Output focus; Weak Links encourage Outcomes
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.
Tip for Practice: HMW Statements
Try to rephrase your Key Results as a “How might we...?” statement. This way, you can sanity-check your focus on Outcomes and uncover premature discussions about feature ideas.
Here’s a practical example of how Outcome OKR and Output OKR sets might differ:
Product Management Outcome vs Output OKR Set Comparison
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. Typical examples could be “number of marketing emails sent,” “page views of product detail pages,” or “CTR of homepage banner.”
Leading and Lagging Indicators compared to Outcome and Output OKRs
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.
Picking the right metric to measure progress for your team and product requires different perspectives
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
No matter how Outcome-oriented your drafted OKRs are, they are of no use if you can’t integrate them into your everyday decision-making. This chapter provides tangible advice for connecting the practice of OKRs to Product Management domains like Product Discovery and Scrum.
Your Main Takeaways:
- How OKRs relate and connect to the different domains of Product Management
- Communicating chosen priorities from the OKR definition through Product Roadmaps
- How can Product Discovery and OKRs influence each other?
- Combining OKRs with Scrum practices and routines
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.
Connecting OKRs to Product Management Domains and Time Horizons
Making sure OKRs and Product Roadmaps don’t create a parallel universe 🔗
Product Roadmaps are one of the most polarizing artifacts in Product Management. Everyone needs to use them in one form or another to communicate priorities (at best), but few Product Teams seem to recognize their necessity and value.
And in the context of OKRs, the role of Product Roadmaps becomes even more critical without getting easier to handle. They 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.
Product Roadmap and OKR Set Relationship
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 Roadmap and OKR Set Relationship
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.
But it’s 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:
- Why is this a problem worth solving?
- 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.
Differentiating the Problem Space and Solution Space of Product Discovery
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.
On the other hand, how should you decide on which area to focus if you don’t know the goals for the next quarter yet? Here’s where the concept of the Theme-based Roadmap comes in 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” representing an important Discovery activity for the “Enterprise” theme during the following cycle.
This way, the Dual Track efforts of an Agile team can be organized using OKRs, and the Product Manager and their team have clarity about what to focus their Product Discovery efforts on.
Deep Dive: A Practical Guide to Product Discovery
In this in-depth guide, you’ll learn what Product Discovery is, why it matters, how Product Discovery phases can play together, as well as lots of advanced tips, strategies, and tactics for your everyday work.
Making working in the Problem Space visible through OKRs
Though Product Discovery focuses on the problem space, many Key Results focus on Delivery and business results (which is a discussion in and of itself). The biggest problem here is that this draws attention away from the Discovery activities of a team. By agreeing on and regularly revisiting a dedicated Discovery OKR, teams can raise awareness for this (often unseen) part of their work.
By agreeing on and regularly revisiting a dedicated Discovery OKR set, Product Teams can raise awareness for this (often unseen) part of their work.
If your company agrees that OKRs should reflect the top priorities, that’s an even bigger argument for utilizing a dedicated set of Product Discovery OKRs. After all, Product Discovery should be one of your priorities. A separate OKR set can help establish a shared understanding of that.
Metrics for these OKR sets can include (but are not limited to):
- Quality criteria for necessary research, ideation, or validation activities
- Desired results from qualitative customer interactions
- Specific user behaviors that indicate the success of new features
Please 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.
How the Delivery Progress of Backlog Items determines the success of set Product Management Key Results
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.