Objectives and Key Results (OKRs) are point-in-time, focus-forcing functions for organizations' goal-setting and product performance management. They are akin to guardrails or filters and can be strung together in parallel and sequenced to construct a roadmap, which can then be used to communicate strategic themes. They are designed to help businesses achieve differentiated value while empowering teams. This guide will walk you through the essential aspects of creating and using OKRs effectively.
Understanding OKRs
Listed below are some fundamental principles to keep in mind:
Circumstances: Depending on the business context, an organization might not need to employ OKRs. Large and complex organizations, tangled webs of cross-functional team dependencies, issues with focus, and so forth are all signs that OKR tooling could be a good fit. Consider timing and the situation the business is currently in or about to be in. Additionally, ensure there is a foundation of trust within the organization, as OKRs require leadership to empower teams to solve problems and achieve form-context fit.
Strategy First: It's crucial to have a strategy in place before setting OKRs. This strategy should diagnose the problem and thematic opportunities to focus on, helping the company add differentiated, low-cost value. A product strategy is all about deciding which problems/opportunities to work on and which teams should work on them.
Objectives as Answers: Objectives should be formulated as answers (what a desired outcome looks like), not questions. Ensure that the right questions have been asked before crafting OKRs.
Focus on Work, Not Individuals: OKRs are never about individuals. They are always about the work, not employee performance. This approach encourages risk-taking and prevents "sandbagging" of goals.
Size of OKRs: OKRs come in two sizes (it's crucial to explicitly state which category each OKR falls into when setting them.):
Roof shots: ~80% chance of achieving
Moon shots: ~20% chance of achieving
Tracking Progress: Use red (at risk), yellow (potential risk), and green (making progress) colors with qualitative written updates to indicate trends toward key results. A good cadence for updates is every 6-8 weeks.
Shared OKRs: Separate teams within a product line can and should share team-level OKRs when it makes sense given the context.
Crafting Effective OKRs
When drafting OKRs, consider the following guidelines:
Time Frame: OKRs are not necessarily tied to quarters. This is a common misconception, often driven by finance departments and their standard reporting cycles, which (in some circumstances) unless they are taking the approach of activity-based costing (ABC), have little to nothing to do with product lifecycle stages and the pace product teams need to operate under to be successful. OKRs can span any timeframe necessary to address a particular opportunity. Consider using rolling quarters or halves, with a 6-month cadence often being ideal. Thinking at the altitude of halves (a 6-month cadence) constrains you to write objectives at the right level of concreteness. The further out in time they stretch, the more vague they must get, and thus the less useful and reliable they become.
A reasonable heuristic:
New products (i.e., new product development/zero to one work) benefit from a roadmap. This is because new product development generally needs more discovery and development time than a feature of a product. Using sequenced, and potentially stacked, OKRs can help teams stay motivated and focused during these uncertain times.
Building on an existing product (i.e., new feature development) requires framing individual projects, sometimes under the guidance of a single OKR. A roadmap in this scenario is not required since each project has a discrete intent/motivation and the market realities (empirical outcome(s)) of a given project will/should be quickly realized, which can and should redirect what you pluck next from the hopper.
Both situations benefit from a blue ocean strategy and from having a coherent mission with clearly stated underlying principles. NOTE: Roadmaps are visual artifacts (e.g., they can be constructed from a string of OKRs running in parallel and/or in sequence) that serve a strategy or strategies. Roadmaps generally do not have a duration shorter than 6 months. They are forward-looking from 6+ months out, often with a horizon of one year or longer.
Appetite: Assign an "appetite" or time budget to each OKR, asking, "How much time do we want to spend on this OKR?" This helps set the level of detail at the right altitude when wording objectives.
Sequencing: Not all objectives should be acted on simultaneously. Some OKRs build on each other, some should be done in parallel, and others may need to be pushed to later (post 6 months out). Naturally sequence your OKRs, considering their interdependencies (the number of inputs and outputs of each (see Connection Circles)) and the current context of the business’s priorities.
Long-term Planning: Avoid setting detailed OKRs beyond a one-year timeframe due to potential slippage. Another good reason to avoid long-term planning is that people might feel the need to conform to “golden” plans set in the past, i.e., only doing what they thought (which might have aged poorly) and not what they are now thinking/learning. For longer-term thinking and planning (post 1 year out), rely on your blue ocean strategy and the principles that underly your mission rather than specific objectives.
Constraining Projects: OKRs are there to constrain what types of projects get pitched at a given point in time. Raw ideas for projects may be added to an upstream project pipeline’s (hopper) option pool for the company or team to consider framing, and perhaps then shaping (pre-development or building). NOTE: Projects here in this article are defined as shaped solutions that build on an existing product and are never budgeted for more than 6 weeks at a time.
Types of OKRs
There are three main types of OKRs:
Maintenance OKRs: These define a Minimum Acceptable Value (MAV) for metrics that don't need continuous improvement. Example of a MAV objective: Not “Prevent 90% of the fraudsters. Now 92%, then 94%…, etc.”, but instead "We need to operate blocking at least 90% of the fraud cases." Be careful if you are to move from a MAV to a performance OKR or vice versa if it does not support the business.
Performance OKRs: These have value-based key results and a backstop measure. They require an existing baseline value (x) to improve upon. Generally, we want two key results for each objective:
The first key result is the primary measure.
A supporting key result is a measure of quality, sometimes called a "backstop," to ensure that the first key result is not inadvertently achieved by hurting something else. For example:
Objective: "Reduce the frequency of parcels delivered to the wrong address."
Key Result 1 (primary measure): Reduce the percentage of incorrect deliveries from x% to y%
Backstop measure: Ensure that total deliveries continue to grow
Learning OKRs: Also known as discovery or novelty search OKRs, these are used when there's no baseline metric to achieve or work from or a target MAV. Example of a learning objective: "Discover n strategies to perform a task effectively." These are set when we are in the declarative stage of learning, i.e., before performance routines have become automatic. In this stage, cognitive resources need to be allocated to mastering the processes required to perform well rather than to the attainment of a specific level of performance. Do not leverage learning OKRs when you should be using performance OKRs, and vice versa. Often great achievements have no goals or roadmaps. The X-Ray is pretty good, and so is penicillin, and neither was discovered with a practical objective in mind. When the electron was discovered in 1897, it was useless. And now we have an entire world run by electronics. Haydn and Mozart never studied the classics. They couldn't. They invented them.
Best Practices for Implementing OKRs
Team Involvement: Teams must come up with value-based key results, not management. They should then back-brief to management for alignment. This approach ensures that those closest to the work are defining how success will be measured. OKR creation must be a collaborative process and requires strong leadership that can empower teams to solve problems. Give yourself a month to create, review, align with the budget, and announce.
Regular Updates: Provide qualitative written updates on progress towards key results. A good cadence for these updates is every 6-8 weeks.
Flexibility: Be prepared to adjust OKRs as progress is made and circumstances change. This does not mean your mission, its principles, and your blue ocean strategy should change often. Those you can revisit every year if necessary.
Decoupling from Performance Reviews: How well OKRs were met by teams should not be seen as a single driver for promotion for any given team member. OKRs should be one of the multiple indirect factors considered in performance evaluations and promotion decisions. This helps maintain the focus on work and outcomes rather than individual performance.
Upstream Project Pipeline: Use OKRs to constrain what types of projects get pitched at a given point in time. Raw ideas for projects can be added to an upstream project pipeline (hopper) option pool for consideration.
By following these guidelines and best practices, organizations can effectively implement OKRs to drive focus, align efforts, and achieve strategic goals while empowering teams and fostering innovation. One of the hardest aspects of getting OKRs right is writing the OKRs well, i.e., they are worded at the right altitude given the appetite. Remember, OKRs are tools to force focus and empower teams, not to avoid doing those things that cannot be measured (sometimes those are the most magical things to pursue) or micromanage teams. They should help the company add differentiated, low-cost value in pursuit of its strategy and its mission.