OKR Product Management Guide for Outcome-Oriented Goals

Contents:

• What are OKRs?
• Who created the OKR framework, and why?
• What are the limitations of OKRs?
• The benefits of OKRs for leaders
• The value of OKRs for product management functions
• Establishing robust product OKRs
• Reviewing product OKR progress
• The interplay between OKRs and product strategy
• The role of OKRs in product discovery
• How OKRs & Scrum synergize with one another
• Using OKRs for product decision-making
• OKR traps to avoid

One mark of a successful executive leader is the ability to drive significant progress towards a given vision of the business. While leaders must bring a myriad of skills and talents to the table, a specific mental model called Objectives and Key Results (OKRs) can help you achieve this progress with less time and effort.

We’ve written this guide to OKRs for C-suite executives and product leaders who seek to set and achieve ambitious business goals. By implementing OKRs for yourself and for the functions that you manage, you’ll have the ability to identify what matters to your business, to set targets for what your teams should achieve, to track progress towards targets, and to diagnose the root cause for unexpected results.

What are OKRs?

The Objectives and Key Results framework (OKR framework) is a flexible and action-oriented structure for identifying business priorities, setting measurable outcome-oriented goals, and inspiring action at all levels of the organization to create value for customers.

Many organizations have spun up their own specific processes around OKRs. We wrote this guide to help you shape and mold the processes that make the most sense for your needs and your context, rather than to “import” a particular flavor from a particular company that might do more harm than good for your specific organization.

To begin, every OKR implementation contains two components: objectives and key results.

• Objectives are qualitative aspirations that represent the direction that the business seeks to move towards, rather than a tangible end state
• Key results are quantitative goals that represent the progress that teams have made towards the objective

Every team should have a single objective for the quarter. Teams should then decide on multiple key results that support this objective.

As an example, imagine a company that sells cooking pots. The objective for one of their teams might be “become a trusted provider of cooking pots for home cooks.”

This team might choose the following three key results to support this objective:

• Decrease refund rates from 0.5% to 0.2%
• Increase repeat purchase rates from 5% to 15%
• Improve top-of-mind brand awareness from 10% to 25%

The specific combination of qualitative objectives and quantitative key results is powerful because it drives directed and synergistic action across every member of the team.

Imagine a team that had only objectives but no key results. This team would not have sufficient insight into the progress they’ve made towards those objectives, and would not know which behaviors to change or actions to take to make meaningful progress.

Furthermore, teammates might individually elect to pursue objectives in ways that make sense to them, but wind up not aligning well together.

For example, one person might seek to target enterprise accounts for selling cooking pots, while another person might seek to target SMBs. Or, one person might seek to increase prices to demonstrate brand strength and prestige, while another person might seek to decrease prices to drive affordability and accessibility.

Using these examples, we can easily see how shared key results at a team level help to keep teammates on the same page.

On the other hand, imagine a different team that had only key results but no objectives. This team would lack the business context to make the right tradeoffs and might narrow-mindedly optimize their metrics in the short term at the cost of long term business success.

And, they might suffer from information overload in trying to juggle many metrics at once, without an overarching objective that tells them which metrics to prioritize in which situations.

Therefore, by pairing qualitative aspirations and quantitative goals together, we align and motivate teams towards taking actions that will advance our businesses forward.

Before we dive deeper into the best practices for implementing OKRs, let’s first discuss why OKRs were invented, and the impact that this framework has had on well-known companies.

Who created the OKR framework, and why?

Intel CEO Andy Grove established the OKR framework in the 1970s to empower workers at all levels in all functions to identify and capture business value.

His driving motivation for creating a new “operating manual” for companies was because he had seen firsthand the problems of top-down managerial control and front-line disempowerment when he worked at Fairchild Semiconductor.

Grove conceived OKRs as an engine for learning, rather than a performance management system. The goal of OKRs was not to reward people for beating targets or to punish people for missing targets. Instead, both managers and direct reports needed to reflect on what they had learned based on the progress they had made on OKRs, irrespective of whether they had surpassed, met, or missed their targets.

Grove built the OKR framework on top of the “management by objectives” (MBO) system Peter Drucker shared in his 1954 book The Practice of Management, where Drucker advised managers to set clear goals for their direct reports to achieve.

But, Grove sought to avoid key disadvantages that came with such a rigid structure that centralized too much decision-making in the hands of managers and supervisors. In his 1983 book High Output Management, Grove provided this critique: “If the supervisor mechanically relies on the MBO system to evaluate his subordinate’s performance, or if the subordinate forgoes taking advantage of an emerging opportunity because it was not a specified objective, then both are behaving in a petty fashion.”

That’s why objectives are typically set by leaders and managers, and why key results are typically set by teams and individuals. This way, supervisors and subordinates partner together to drive high-level business progress through success on the front lines.

The OKR framework was then further popularized by John Doerr in 1999, when he brought this framework to Google. At the time, Google had fewer than 50 employees, and its founders Larry Page and Sergey Brin had been PhD students just a year before.

As Doerr shares, “Kleiner Perkins had just invested in Google, and as a strong advocate of OKRs, I offered to introduce the OKR system to Larry, Sergey, and the leadership team. Larry and Sergey saw the value immediately. They liked having a quarterly set of priorities for the company.”

By focusing their efforts on these priorities, Google quickly became a darling for internet users who had previously relied on portal sites like Yahoo or Lycos to navigate the web. Google IPO’d in 2004, just 5 years after OKRs had been implemented at Google.

What are the limitations of OKRs?

We now see how OKRs helped Intel grow from $1.9 billion to $26 billion in annual revenue under Grove’s leadership, and how OKRs helped Google become the dominant search engine on the Internet.

But, OKRs are not silver bullets—we need to make sure that we don’t accidentally misuse OKRs. Specifically, OKRs should not replace either business vision or business strategy.

Vision defines the overarching direction of the business over years and decades. OKRs are set at a quarterly level and are therefore rooted in day-to-day execution. Without a guiding vision, leaders cannot create OKRs that make meaningful long-term progress, because the very definition of “meaningful progress” is set by the vision.

And, OKRs cannot supplant business strategy; rather, OKRs help breathe life into strategies. A true strategy requires a diagnosis and a set of guardrails to drive tradeoffs, whereas OKRs focus on executing to achieve results that fit within those predefined guardrails.

We won’t dive further into “how to set a compelling vision” or “how to craft a winning strategy,” as these topics are out of scope for this guide. If you’d like to learn more about vision or strategy specifically, we run corporate workshops on both vision and strategy at Product Teacher.

Thus far, we’ve learned where OKRs came from, and we have a good working definition of what ORKs are. But, as leaders, why should we use OKRs rather than alternative approaches?

The benefits of OKRs for leaders

Using the OKR framework provides leaders with five key benefits:

1. Ability to measure progress

First, OKRs encourage us to crystallize the goals of the business into easily-measured targets.

In other words, OKRs are a forcing function that makes us verbalize what exactly we care about for the business, why we care about it, and which results matter. We create accountability and transparency, and we avoid “cherry picking” good results later.

Say that one key result for your organization is “increase new customer acquisition rates by 10% this quarter.” If a team winds up “increasing contract value for current customers” but doesn’t “increase new customer acquisition rates,” you know immediately as a leader that this result was not what you had sought to achieve.

Perhaps, as a leader, you had identified that “gaining new customers” was crucial for driving viral growth, where each newly-captured customer increases your likelihood of capturing the next new customer.

But, if you had only tasked your team with “increasing revenue,” then they would have believed that “increasing contract value” was a good way to increase revenue without understanding that your desired strategy was centered around gaining new customers.

Avoiding cherry picking is especially important for running A/B tests. Any experiment could easily yield changes across dozens of possible metrics, and someone could easily select “only positive results” to make their tests look good when their results had actually failed to create real value for customers.

Therefore, by setting success metrics upfront, OKRs drive accountability and transparency.

2. Alignment of efforts towards business goals

Second, when teams have clarity on which metrics they seek to move, they align their efforts towards those metrics. When team metrics ladder into business goals, we can empower our teams to make decentralized decisions at high velocity to help the business succeed.

As soon as a given team knows which metrics they’ll use to measure their progress, we can let them decide which initiatives to run, which people should run point on those initiatives, and what kinds of processes they’d like to implement. Once our teams convince us that their selected metrics prove progress against the business objective, as leaders we can step into an advisory role rather than an execution role.

As executive leaders, we should aim to have all teams be “tightly aligned but loosely coupled.” In other words, teams should aim in the same business direction, but they should not be bottlenecked against executive intervention or executive approvals.

When leaders feel compelled to micromanage every detail, they become significantly less effective and less strategic. On the other hand, when teams are empowered and tightly aligned, leaders can focus on more scalable uses of their own time and effort.

3. Flexibility to change based on learnings

Third, OKRs can and should change based on what we learn from our customers and the markets that we operate in.

In some quarters, teams might decide that only three key results truly matter for a given objective; in other quarters, teams might decide that they need to keep track of five separate key results.

And, as each business line moves through different stages of maturity (e.g. launch vs. growth vs. decline) on their own pace, we need to reevaluate business goals on a regular basis.

Through the OKR framework, we have the means to change our objectives and the objectives of our teams to focus on the most relevant, highest-value efforts for our customers and our investors.

4. Ability to telescope across different levels

Fourth, OKRs can be telescoped across different levels; that is, OKRs on the front lines can be laddered up into OKRs for middle management, which in turn can be laddered up into OKRs for senior leadership.

As Doerr himself states about his time working at Intel: “It was incredibly powerful for me to see Andy Grove’s OKRs [at the CEO level], my manager’s OKRs, and the OKRs for my peers. I was quickly able to tie my work directly to the company’s goals.”

The value of OKRs is that they can be implemented at any level, whether for CEOs or for front-line employees. The “key results” at the executive level flow into “objectives” at the next level; and, the achievements of front-line teams flow back into the results for executive teams.

When CEOs use OKRs to focus their efforts, they clearly define where the company should be headed over the next quarter, with crisp and easily-visualized targets at the company level.

From there, the heads of various departments can then convert each target into objectives for their respective functions. And, each functional group can then take these objectives and create key results for their teams, who then create their own objectives and key results for individuals.

By driving this telescoping alignment across all levels, executive leaders can provide clarity and spark motivation across functions and seniority.

5. Consistency and standardization

Finally, OKRs give us a universal language to guide our teams. When we have consistency and standardization, we can ultimately move faster and farther as an organization.

Cross-team coordination is one of the biggest amplifiers of company success and company failure. By empowering teams to speak the same language, we drive better collaboration, negotiation, and problem-solving.

When two teams have conflicting goals in the OKR framework, they can work together to modify their own respective objectives and metrics, so that their progress no longer conflicts with one another but rather synergizes with one another.

As an example, let’s say that a customer success team is aiming for less attrition from current accounts, whereas a sales team might be aiming to reach out to a variety of new logos.

Without OKRs in place, these two teams might wind up clashing. If the sales team brings in many new logos that make an initial purchase but then churn, then the customer success team will suffer. And, if the customer success team forces the sales team to qualify logos before letting them purchase, then the sales team will suffer.

But, with OKRs in place, this hypothetical customer success team can work with their hypothetical sales counterparts to refine each of their respective key results. Customer success can measure their progress against “attrition for qualified accounts,” and sales can measure their progress against “conversations with new qualified accounts.”

This way, neither team spends time on poorly-qualified accounts that wouldn’t find value, enabling the company as a whole to focus on the customers that would benefit the most from their offerings.

The value of OKRs for product management functions

Every product seeks to create massive value for their customers, so that the business can then capture value for itself. But challengingly, products can achieve business value in many directions, with some directions being mutually exclusive to other directions.

For example, should a product focus on gaining new users? Or should it focus on driving more engagement from existing users? Perhaps instead it should focus on monetizing its current user base? Or maybe it ought to drive profitability from current revenue streams instead?

We need to choose upfront which of these goals we should tackle this quarter. After all, focusing on one of these goals usually comes at the cost of a different possible goal:

• Gaining more users might require sacrificing profits to fund customer acquisition
• Driving immediate profits might require paywalls that cause drops in user engagement

Therefore, using OKRs to guide the direction of the product can significantly accelerate the impact of the product on the business.

How might we decide on OKRs for a PM team? We can use this OKR template from Miro as a starting point. The template that Miro provided has already been pre-populated with examples for a Content function and for a Partnerships & Events function.

Let’s populate this template with a product management example, then. Let’s say that a head of product sets the objective of “becoming a trusted technology partner for our customers,” with the following three key results:

• Increase the average number of workflows completed, per user, per month
• Increase the number of monthly active users
• Increase the number of integrations that the product has

Each key result is then led by a director of product, who converts their specific key result into an objective to guide their respective product managers.

Consider the director of product who is responsible for “workflows completed.” They might have the following key results for their team:

• Complete a number of A/B tests
• Complete a number of usability tests
• Accelerate workflow completion time by some percentage

Each product manager will then have their own objectives, where they then create key results for their product pods across design, engineering, and other functional counterparts.

Here’s a diagram of what it might look like for this particular product team:

The OKR learning engine is particularly helpful for PM teams for three reasons:

1. Encourages experimentation and learning rather than feature delivery
2. Creates space for bottoms-up discovery with rich customer context
3. Provides guardrails for success

First, product managers need to have the ability to experiment. Keep in mind that product management is all about maximizing upside and taking prudent risks, whereas project management is focused on minimizing downside; the two disciplines are related but distinct.

If we force product managers into project management mode, where their only goal is to deliver some known feature by some known deadline, then product development devolves into project delivery. When we fail to give product managers the space to learn from customers and to launch well-scoped experiments, we cause our products to stagnate, and we cause our companies to fall behind the competitors who take the time to learn about customer pains.

As a side note, transitioning from traditional project management into modern product management is out of scope for this guide on OKRs. If you’re looking to kick off this kind of transformation, we provide corporate workshops and 1:1 coaching through Product Teacher.

Second, by using OKRs, we enable decentralized bottoms-up discovery to be the dominant form of innovation within our organizations, rather than bottlenecking innovation at the executive leadership level.

Product managers tend to be significantly closer to customer context than executive leaders are, whether through customer interviews, customer shadowing, customer feedback analysis, or data analytics. Therefore, product managers should be empowered to make product decisions for their customers, rather than forcing executives into situations where they must give up valuable time to make tactical product choices.

Finally, OKRs establish guardrails for success and connect the success of the customer to the success of the business.

After all, customers are “divinely discontent” and have infinitely many pain points that we could solve for them; their expectations grow over time. Some of these pains, when solved, simply will not yield value to the business. Therefore, identifying which business levers matter is a powerful filter to help product managers prioritize the right kinds of customer pain points.

For example, consider a real estate website where users can input an address to get an estimated home valuation. A hypothetical product manager for this home valuation workflow might identify that they could improve “time to complete workflow,” “workflow completion rates,” or “user satisfaction” by removing just a single step in the workflow. This step happens to ask users whether they’d like to speak with a real estate agent about their needs, and a minority of users have sent in complaints to the customer support team that this step is annoying to them.

Crucially, this step is a monetization step that captures business value. If this product manager removes this call-to-action, the product is no longer capturing value for the business.

With OKRs in place, this hypothetical product manager will realize that the point of their product is to capture value for the business, and therefore will not attempt to remove this workflow step even though it would create value for customers. In other words, even if one of the key results for this PM is “customer workflow completion time,” they will not sacrifice the long-term viability of the business for short-term gains on product metrics.

We now understand the value of OKRs for product management teams. And, as companies discover the power of product-led growth—i.e. using the product to achieve goals for non-product functions like sales and marketing—executive leaders for any function must understand how to set robust product OKRs.

Establishing robust product OKRs

To help you build out product OKRs that will work for your organization, let’s walk through best practices and anti-patterns for objectives and for key results:

Setting a single objective for each team

When implementing OKRs, we need to keep in mind that each team should only pursue a single objective at a time. While different objectives can be sequenced out across multiple quarters, any given quarter should have only one active objective.

As an example, I used to lead a CRM mobile app for real estate agents with the following objective: “empower real estate agents to drive more home sales with less effort.”

I could have broken this objective into three smaller objectives instead, like this:

• Enable real estate agents to collaborate with each other through our products
• Strengthen online visibility for real estate agents
• Automate as many low-value processes as possible

But, if I had wound up using these three separate objectives, I would have run into a problem: which objective do I focus on? When teams have more than one priority in theory, they wind up having zero priorities in practice.

Of course, at a leadership level, we recognize that businesses must juggle multiple conflicting priorities. Even so, one of these priorities is the most urgent for a given team; all other objectives can either be sequenced into the future or assigned to a different dedicated team.

The more objectives you seek to achieve in this quarter, the more dedicated teams you must have; the number of active objectives scales linearly with the number of teams. And, since every business has limited working capital, every business can only have so many objectives active at one time.

To clarify, we cannot ignore real-world demands; rather, we must make difficult choices about what to prioritize now vs. what to prioritize later.

Examples of unproductive objectives

While there are no universally good objectives that apply to every business and every context, we should avoid selecting universally bad objectives.

First, we should avoid objectives that cannot be meaningfully progressed against within a single quarter. For example, “become the market leader in Spain” doesn’t make sense if our organization has no presence in Spain yet.

Instead, we could frame this objective as “learn whether we could viably enter the market in Spain.” By scoping the objective to be reasonable within a quarter, we can then set tangible key results against the objective.

Second, we should avoid setting objectives that force specific product outcomes, especially if we don’t have clarity into customer pain.

For example, an unproductive objective might be “sunset the least-used features to improve margins.” While this might make sense at a surface level, we might not realize that a particular “password recovery” feature is a low-use feature with extremely high value for customers.

When customers cannot change their own passwords and must contact support teams for help, they become frustrated and significantly more likely to switch to competing solutions. Even if we might save a few thousand dollars in maintenance costs, we will likely lose tens of thousands or dollars or more through customer churn.

Another unproductive objective might be “narrow the distance between our feature set and a competitor’s feature set.” When we ask our teams to chase competitors rather than understand our own customers, our products drift away from solving real customer pain and lose their power to capture value for our businesses.

After all, our competitors serve their own specific customer base, and we serve our own specific customer base; each customer base has distinct needs that differ from one another. Therefore, our business objectives must be rooted in the specific context of our customer base, rather than the customer bases of competitors.

If we seek to mimic competitors because we don’t know what pain our customers have, it’s far more productive to set objectives around discovering customer pain rather than setting objectives around competitive feature parity.

Now that we understand what good objectives and bad objectives look like, let’s discuss best practices for selecting key results.

Setting good key results

Key results should identify whether teams have made progress against the selected business objective. Therefore, key results contain three components:

• The metric that we’re measuring
• The current state of the metric
• The targeted end state for that metric

Beware of setting key results that are convenient to measure but don’t align with the chosen objective. For example, consider the business objective of “creating more powerful workflows for users.” Many teams might decide to measure “monthly active users” because it’s easy to instrument and measure. However, “monthly active users” is not a metric that defensibly demonstrates progress towards “creating more powerful workflows for users.”

After all, a team could create deeper workflows but still wind up with the same number of monthly active users. Or, a team could drive significantly more monthly active users by shipping features that drive workflow awareness, but the team might fail to meaningfully deepen the current workflow.

Furthermore, each objective should have 3-5 key results. Ideally, each key result should be distinct from one another and capture different components of the objective. Having more than 5 key results can lead to loss of focus, and having fewer than 3 key results can lead to loss of comprehensive coverage.

For example, say that my objective is to “empower real estate agents to drive more home sales with less effort.” These three key results could make sense together:

• Improve lead-to-sale conversion rates from 30% to 34%
• Increase average monthly home sales per agent from 1.5 to 1.8
• Strengthen the accuracy of home value estimates from 85% to 90%

Establishing viable targets

Furthermore, key results need to come with goals – we can’t simply measure a metric and call it a day. For goals to be actionable for our teams, they need to be SMART goals:

In setting these goals, we should encourage our teams to select stretch goals that are motivating but not impossible.

If the team has a target that they will achieve 100% of the time, they will have less reason to be curious and innovative. But, if the team has a target that they might only achieve 20% of the time, they’ll become disillusioned and discouraged as their target feels distant and unachievable.

A good rule of thumb is that OKR targets should be 60-80% achievable. That is, a team should naturally be able to reach 60-80% of the target with no additional effort, but will need to expend some effort to attempt to hit 100% of the target.

Examples of unproductive key results

As leaders, we will need to coach our teams to select meaningful key results for their objectives.

First, key results should not be “vanity” results, i.e. results that will naturally come over the course of time. For example, “total number of views” or “total number of user accounts” can only grow upwards, irrespective of the team’s efforts in this quarter.

Generally speaking, percentages and ratios tend to be better outcome-oriented goals than totals are. For example, “percentage of active user accounts” is more meaningful than “total user accounts,” because the percentage of active accounts over time tells us whether the product is creating long-lasting repeat value for customers.

Second, the key results that we focus on should actually matter for the business; that is, a key result should connect to customer value or user value.

Logins and views are rarely good choices for key results. When a customer logs in, they haven’t received value from the product yet. Similarly, when a customer views a particular page, their pain has likely not been solved yet.

Completed workflows tend to be better measures of customer value than logins or views. And, somewhat counterintuitively, customer interviews tend to be strong choices for key results. By interviewing customers, teams can identify unmet customer pain, which can then guide them towards making valuable product decisions.

Now our teams have a system of objectives and key results in place. But, we still need to set up regular reviews to drive learnings and iterative improvement across the organization.

Reviewing product OKR progress

As leaders and managers, we need to regularly review the progress that our teams have made against their set OKRs, so that we can encourage them to reflect, learn, and improve.

Keep in mind that OKRs are not meant for performance management – you should not encourage promotions or demotions based on OKRs, as that tends to incentivize “gaming the system.” That is, teams will be incentivized to pick a target that will make them look good, rather than selecting a target that truly drives customer learning and business value.

Focus on rewarding teams that demonstrate thoughtful learning rather than thoughtless execution. After all, the teams that learn are the ones that will create long-term value.

We should formally review OKRs with our teams at least once per quarter. Some product-led organizations review OKRs every 6 weeks, and others might review them every 4 weeks. On the other hand, a 2 week cadence for formal reviews is usually not a good use of time.

Furthermore, we should encourage teams to spin up dashboards so that we can check in at any time on their progress without having to schedule a meeting. By encouraging information flow, we spur the organization to move faster and farther.

Using key result goals to drive learning and business growth

The key result goals that teams have set will lead to one of three possible outcomes:

• The team meets 60-80% of the target
• The team exceeds 80% of the target
• The team doesn’t achieve at least 60% of the target

If the team meets the target, then they should spend time reflecting on their learnings. Which initiatives and processes were effective? How could the team have achieved better results? Were there surprises that we didn’t expect?

If the team overshoots the target, that’s not cause for celebration. Instead, we need to ask whether their goals had been set too low, and whether we had missed out on achieving even more. Or, perhaps the market was more favorable than expected. If that’s the case, then what exactly caused this favorability, and how might the team be able to take better advantage of tailwinds like these in the future?

If the team misses the target, that’s not cause for blame. Instead, we should ask blameless questions in retrospectives, to understand “what are 2-3 things we will do differently next time to be better than last time?”

Some questions that can help this discussion:

• Was there an internal failure? If so, could we have foreseen or mitigated it?
• Were there external factors (e.g. competition or economy) that caused it? If so, how could we have made ourselves more resilient?

Promote a culture of psychological safety, so that teammates can provide candid feedback and drive meaningful iterations.

After each quarter, we as leaders need to reassess the objectives that we had set, based on the progress that our teams have made towards this objective. Do we keep the objective and double down for the next quarter? Or do we instead set our sights in new directions?

We’ve now covered the foundations for a successful implementation of OKR processes. Let’s discuss how OKRs interact with product strategy, product discovery, and Scrum.

The interplay between OKRs and product strategy

OKRs are complementary to product strategy. After all, the objectives that feed into OKRs must first come from product strategy.

Every strategy must contain a diagnosis of “what is a problem in the world that we wish to solve,” as well as an understanding of our assumptions, our constraints, and our proposed path to victory. This proposed path provides the foundation for the objectives within any OKR.

OKRs are focused more on execution, and less on diagnosis or tradeoffs. And, since key results flow from objectives, key results ultimately tie back to the identified product strategy.

But, OKRs do not solely flow downstream from product strategy – they also influence product strategy in turn. Our product strategies should not be static; they should fluidly evolve based on the learnings that our teams have found as they pursue their key results.

In other words, progress against key results can help us identify whether the strategy makes sense to continue pursuing. If we find that multiple teams are struggling to reach their key results, we now have reason to believe that the strategy must be updated to reflect changed market conditions.

As an example, in 2022 the world experienced a heavy economic downturn, and therefore teams were significantly less likely to reach their prior key results. In cases where the underlying terrain has changed, we have to update our strategies to account for new realities.

The role of OKRs in product discovery

Product discovery is the journey through which teams dive into the unaddressed needs of the customer and rapidly iterate through possible product solutions for addressing those needs.

The objectives within OKRs will set product discovery goals for the team. Based on the kind of value that the business seeks to achieve, teams should focus their discovery efforts on those threads of inquiry.

In other words, when teams conduct customer interviews or data analyses, they should do so from the lens of “which customer pains do we prioritize to achieve the given business objective?”

But, in the course of product discovery, teams will learn unique insights from customers that we as an organization may not have realized before. These new insights might wind up changing our objectives.

As an example, perhaps a team uncovers a promising new area of customer pain that we are uniquely positioned to address. Or, perhaps a team learns that “increasing awareness of our existing offerings” might yield significantly more value than “creating new offerings,” based on what they learn in customer conversation.

We would be unwise to discard these learnings solely because they did not align with predetermined objectives. Rather, we should update objectives based on the learnings that we find in product discovery. We should expect a cyclical flow between OKRs and product discovery in this way.

And, the key results within OKRs also signal to us and our teams whether we should continue to dig deeper into an insight that we found through customer discovery, or whether it’s time to conduct additional customer discovery to find new objectives to target.

When teams are unable to reach their key result goals, they cannot reflect in isolation. They need to conduct product discovery with customers to understand why their product initiatives have not met the goals.

And, when teams do successfully reach their key result goals, then they need to identify which new customer pains to address in the coming quarters. This exercise also requires them to conduct discovery with customers.

Ultimately, teams cannot mindlessly “manage by numbers.” OKRs are not meant to pull teams away from customers; rather, the metrics within the OKR framework should provide teams with a scalable lens into the lives and needs of their customers.

How OKRs & Scrum synergize with one another

Scrum is a methodology that teams use to deliver “increments of working value” to customers on a regular basis, e.g. every two weeks. Each block of time, i.e. sprint, contains a sprint goal with a hypothesis for making progress against OKRs.

Scrum cannot work in the absence of OKRs, because “what is valuable” depends on “which business objective we seek to pursue.” OKRs provide clarity to each sprint, and teams are motivated to focus on creating valuable functionality each sprint that will move the metric in a measurable way.

OKRs also benefit significantly from Scrum. Because Scrum encourages teams to deliver meaningful and measurable value every sprint, teams can make faster progress towards their key results and their objectives by leveraging Scrum. By focusing on delivering working components, teams avoid overbuilding and focus on the minimum required functionality to test their hypotheses.

And, Scrum encourages teams to demo their products to customers, and to capture those learnings. Those learnings then feed back into OKRs. When customers provide live feedback on live functionality, teams can iterate more quickly and have a more clear-eyed view into whether their chosen key results still make sense to pursue over the course of the quarter.

Using OKRs for product decision-making

Every product decision is a tradeoff between initiatives that yield different returns on investment (ROI) across different time horizons and different company objectives.

Therefore, OKRs help guide us and our teams to select the right tradeoffs given our current priorities as an organization. OKRs provide us with value at every level of product-decision making, whether for product strategy, product execution, or sequencing of product initiatives.

At the feature level e.g. enhancements or improvements to existing products, we can use the RICE prioritization framework to break out the ROI case for each initiative. The RICE framework identifies the reach (# of customers impacted), the impact (depth of value created), the confidence (level of understanding of customer pain), and the effort (implementation costs) of any given initiative.

Crucially, “impact” is calculated based on the OKRs that we seek to achieve this quarter. If a given proposal would unlock some value, but that value doesn’t align with the objective for the quarter, then its impact should be set to zero. That way, we focus solely on the initiatives that will truly drive progress towards the objective.

At a strategy level, we should encourage our teams to create product strategy one-pagers when they seek to convince us to prioritize objective X over objective Y, as this exercise drives clarity of thought.

In these proposals, teams should base their arguments on the learnings from key results that they’ve found in prior quarters. In other words, OKRs give teams space to learn, and their learnings then drive compelling strategic changes.

OKR traps to avoid

In our experience working with leaders from dozens of organizations, we’ve seen the following pitfalls come up frequently when using OKRs:

• Too many objectives or key results
• Conflicting objectives across teams
• Implementation is too rigorous
• Forcing OKRs onto binary situations

Too many objectives or key results

A common anti-pattern for OKR implementation is that a given team has too many objectives or key results at the same time. While leaders should demonstrate drive and ambition, we need to remember that multitasking leads to worse outcomes.

Ensure that each team has only one active objective for the quarter, and ask teams to decide on 3-5 key results to support the objective.

If you or your teams find that there truly are multiple objectives or key results that must be tackled at the same time, spin up a new dedicated team to handle those objectives, rather than spreading a single team too thin.

Conflicting objectives across teams

Even if we ensure that each team has only a single active objective, one issue that can arise is when different teams have conflicting objectives. In essence, this phenomenon is a symptom of a problem with strategy.

A strategy requires us to state tradeoffs up front, so that all teams have synergistic objectives. As an example, rather than attempting to pursue both high-end customers and mass-market customers, leadership teams must decide which customer segment matters the most right now.

Teams that run into conflicts tend to have senior leaders who aren’t operating with the OKR framework in mind. To help reduce the likelihood of conflicting objectives, we can implement OKRs for senior leadership.

After all, as leaders, we should not fear process changes, but should instead embrace them. As a reminder, Intel and Google achieved massive success through ruthless prioritization; we can do the same as leaders.

Implementation is too rigorous

While OKRs are valuable, some organizations misuse the OKR framework as “the ultimate objective of the company,” rather than a means for driving learning and improvement.

This instinct is understandable. Organizations seek certainty, and using OKRs to drive performance reviews and promotions feels data-driven.

However, by placing OKRs on a pedestal within the organization, we start to drift away from our customers’ needs, and we lose agility. Teams focus too much on setting targets that will make them look good, and fail to spend sufficient time learning about customer needs and experimenting with ways to better meet those needs.

Teams should be encouraged to revisit their key results as they learn more in the market. The insights that they receive from their execution must be reincorporated bottoms-up into our strategies at the leadership level.

If we solely use top-down directives without granting teams the flexibility to experiment and propose new targets, we revert back to a waterfall-style way of working, which runs counter to the practices that enabled Andy Grove to unlock dozens of billions of dollars in incremental annual revenue at Intel.

Forcing OKRs onto binary situations

OKRs tend not to work well in binary situations, where the team can only achieve one of two outcomes: success or failure.

One binary situation would be “launch this specific feature.” Another binary situation would be “capture this specific customer.”

When we force OKRs onto binary situations, teams have no way of seeing and measuring the progress they made towards the outcome over the quarter. This loss of transparency creates frustration and loss of motivation.

Yet, binary situations are occasionally appropriate to track, especially for enterprise products. In cases like these, leaders would do well to explicitly state “this key result is binary” and to ask the team to provide an estimated “chance for success” for the key result.

The goal for the team is then no longer to deliver the binary result, but rather to increase the chance for success. By doing so, the team focuses on their processes and builds up long-term strength, rather than focusing on an immediate deliverable that might cause long-term harm when rushed to an arbitrary finish line.

Closing thoughts

Executive leaders should consider implementing an OKR learning engine to empower their teams to create business value at all levels.

By combining qualitative business objectives with measurable outcomes, you motivate your teams and your direct reports to improve over time.

OKRs should not be rigidly implemented—instead, different organizations will have different best practices around OKRs. Consider which kinds of processes make the most sense for you, whether those are formal executive readouts or lightweight syncs.