5 Ways Your Company May Be Misusing OKRs

Since their invention at Intel in the late 1970s, Objectives and Key Results have amassed a huge following. It certainly helps that Google, Amazon, Dropbox and other tech super-companies attribute so much of their success to them. John Doerr’s book Measure What Matters is further fueling this fire. Many companies are either implementing or have already implemented OKRs. It’s the tool I get asked about the most.

But here’s the thing — OKRs are just containers for goals. They serve bad goals just as well as they do good goals. In fact, of all the management tools, OKRs are the easiest to misuse, overuse and abuse — many companies fall into this trap. This is a major problem because bad OKRs can amplify the issues the org is troubled with rather than fix them.

In this article I’ll go over some of the most common issues I see with OKRs and ways to address them.

1. Using OKRs to express a plan (Output OKRs)

This is the most fundamental and most common mistake I see (I’m certainly guilty of doing it in the past). Our natural inclination is to use OKRs to express a plan of action.

For example:

O: Become a leader in the enterprise

  • KR: Launch v2.2 of the mobile app
  • KR: Integrate with SalesForce
  • KR: Switch to new onboarding flow
  • KR: Run 10 paid campaigns

Here’s why this is wrong. Objectives and Key Results are designed to convey goals — what we’re trying to achieve, by when and how we’ll measure success. Building, launching and promoting features and products are not the goals. The goals are the benefits we expect to gain from these actions.

Goals that communicate a plan (known as Output Goals) commit this fundamental logical error:

  1. We want to achieve X (the real goal)
  2. The best way to achieve X is to do Y (a solution)
  3. Therefore doing Y is equivalent to achieving X

In tech steps 2 and 3 represent huge leaps of faith:

  • Doing Y will indeed accomplish X
  • Y is the best way to achieve X
  • Y will not have big negative side-effects
  • Y is feasible with our current technology and resources.
  • Y will not cost x2-x4 more than we think
  • Etc.

Virtually every project I worked on or observed invalidated some or all of these assumptions — especially the first — the assumption that the project will have the expected effect. We may launch v2.2 of the mobile app and users will hate it and usage will plummet. The new onboarding flow may drive no measurable change in user behavior — that’s actually the case with most product changes. Running 10 campaigns may help us acquire the wrong right type of users, etc.

Doing stuff isn’t the point. Achieving stuff is.

So the right sequence is: 1) Define what you wish to achieve in the form of Objectives and Key results 2) Plan what you’ll do to achieve it (for more details see the GIST framework)

If you find that you keep creating output goals, this simple trick to get to the real outcome/impact goal behind them: ask “why?”

  • KR: Launch v2.2 of the mobile app → why? → Grow Mobile WAUs >= 300K
  • KR: Integrate with SalesForce → why? → Reduce churn to < 2.5%/month
  • KR: Switch to new onboarding flow → why? → Reduce avg. onboarding time < 2hrs
  • KR: Run 10 paid campaigns → why? → Acquire 2500 leads per month

Upcoming Workshops — Lean Product Management

In this workshop I will walk you through the principles and tools of lean product management — how modern-day PMs drive business results and optimize for high impact. Early-bird tickets are available now.


2. Using Non-SMART OKRs

Management guru Peter Drucker defined SMART goals in the 1950s, but it’s still a very valid guideline today. Goals should be:

  • Specific — paint a clear picture of the desired end result; not ambiguous.
  • Measurable — all key results should have clear metrics.
  • Ambitious — pushing the team somewhat out of their comfort zone (Google founder Larry Page calls this feeling “uncomfortably excited”, and you do experience this feeling quite a bit in Google)
  • Realistic — Achievable, Not pure fantasy.
  • Time-bound — each OKR should have a clear ETA — typically end of quarter or end of year.

The main anti-patterns I see:

  • High level and vague key results — MBA-speak simply doesn’t work here: “deliver engaging experiences” or “drive customer satisfaction” are neither specific nor measurable.
  • Non-realistic key results — some managers believe that they’re job is to ask for pies in the sky as a way to drive people to deliver more. This tactic always backfires — people will seemingly commit, but quietly reject a goal they perceive to be non-feasible. It’s much better to have the people doing the work help you find what’s ambitious-but-realistic.
OKRs are not a zero-sum game — they’re meant to drive collaboration, not hard negotiation.

3. Too Many OKRs

I see this a lot — companies and teams get excited about OKRs and put every conceivable thing they may wish to work on into them. Teams of 4 people try to commit to 6 OKR clusters each with 4–5 key results. Managers expect to see every possible metric captured in the OKRs, and request weekly progress check-ins.

Naturally this falls under that non-realistic goals category, but it’s even worse:

  • No focus — Having too many goals robs teams of focus. When everything is important it’s very hard to know what to work on and there’s less progress.
  • Low completion rate — even if the team did very well, at the end of the cycle only a small % of the goals were completed. This may lead to disappointment, mistrust in the process, treating OKRs as wish lists or rejecting OKRs outright.
  • Too much process — OKRs are a tool to capture and communicate goal. They’re not meant to serve as dashboards and weekly tracking is too frequent. There are better tools for this (and even there being picky about the metrics is important).
When it comes to goals less is truly more.

One way to get out of this hole is to score the OKRs at the end of the cycle and see what % we completed. This will help calibrate us if we trying to do too much or too little. You can calculate completion rate for each of the key-results (should be easy, because they’re measurable, right?) and then average across all OKRs.

What’s a good completion rate? At Google 70% is considered normal — indicating the right ratio of ambition and realism. For many companies that’s too forgiving — they set the target higher. However 100% completion rate is just as bad as 50% — it means that people are not being ambitious enough, only going for safe goals.

Another tip I give first-time OKR teams is to start small and try hard to only include the most important things. On a team level start with 3x3 (3 Objectives each with maximum three key results) and over time try see if you can reduce to 2x2. At org-level you should try to stay within 6x5 OKRs. Smaller companies can often do with fewer top-level OKRs.

4. Top-Down OKRs

Here are some other anti-patterns I commonly encounter:

  • Managers create the OKRs for the employees
  • Product managers create the OKRs for the team
  • The finance team defines the expected results for everyone

The problem is this — goals that are created by “planners” and handed down to “implementers” are usually bad goals. They’re lacking the perspective, knowledge and insight of the person doing the work. These folks can contribute not just to their goals, but also to their higher-ups’ — missing goals, unrealistic or over-cautious goals, better ways to measure, etc. Top-down goals are also less likely to get buy-in. If we didn’t hit the targets it’ll always be the fault of the plan.

The best people to help you define the goals are the ones that will make them happen.

You want to have people take part in defining their own goals (at least). In a development team, the leads — PM, dev, UX, should create the draft and then share with the team for review. Similarly managers should create skeleton OKRs and ask their reports to start filling-in the gaps and propose missing objectives and key results. The process should be as much bottom-up as it is top down.

5. Using OKRs for performance evaluation

Some managers think that OKRs are a way to get people to commit more, work harder and be more accountable. A smart way to increase performance, productivity and output. Some even try to tie performance evaluation, compensation and promotion to OKRs.

This is absolutely the wrong way to think about OKRs.

It’s true that good goals can help people and teams stretch themselves and achieve more, but it’s never because there’s a carrot or a stick attached. The improvement comes from the clarity, focus, consistency and sense of impact that the goal brings.

Tying performance evaluation to OKRs is a major no-no. It motivates people to game the system — push for non-ambitious goals, low-ball outcomes, blow-up effort estimations. You’ll definitely never get anyone to be ambitious with their goals anymore.

OKRs are not contracts between managers and employees.

If anything, OKRs are a tool to get managers to perform better — communicate clearly and transparently what they wish to achieve and how they would like to measure success; Be more collaborative in defining goals and more conscious of what’s possible; stay consistent and not pivot on a dime. Once we invite everyone to take part in OKR creation, these benefits extend to the rank-and-file as well. We can all become better managers of ourselves, our teams and our organizations.


Itamar Gilad (itamargilad.com) is a product consultant and speaker helping companies build high-impact products. Over the past 15 years he held senior product management roles at Google, Microsoft and a number of startups.


To receive posts like these by email sign up to my newsletter.

If found this article useful consider sharing it.


Upcoming Workshops — Lean Product Management

In this workshop I will walk you through the principles and tools of lean product management — how modern-day PMs drive business results and optimize for high impact. Early-bird tickets are available now.