FAQ: OKR Not Working in My Company

Objectives and Key Results (OKR) is one of the most common processes in the industry, and yet, despite 50 years of history, it’s the one companies struggle with the most. This problem is most evident when talking with product people and product leaders — the same challenges and frustrations come up again and again. 

So below I summarized the most common OKR questions I get, and how I tend to answer.

We’re working on delivering according to the roadmap. What OKRs should we create? 

If that’s your situation, you are working as a feature factory and your OKRs have to be about output — building stuff and launching it. The roadmap assumes the ideas it contains are the best ones, they’re all valuable, feasible, usable, and viable, and there’s nothing to research or to discover. You’re likely falling into a classic trap.

Output roadmaps are at best an educated guess and can create massive waste. They’re also brittle in the face of uncertainty, running into inevitable delays and priority changes. 
It may not be your decision, but I highly recommend switching to an outcomes roadmap, which goes hand-in-hand with creating good, outcomes-based OKRs.

An outcomes roadmap (free template)

We don’t have a fixed roadmap. Every quarter we publish a list of product ideas we want to work on, but we’re free to change it. What OKRs should we create? 

You’ve created a half-way solution between output roadmaps and outcomes roadmaps. While it’s a more flexible plan that leaves room for discovery, you’re getting none of the benefits of OKRs: on one hand you’re not really committing to achieving outcomes — measurable changes in user behavior, business results, or system behavior — and on the other, the organization doesn’t know what it’ll get. While publishing your top candidate ideas (without commitment) is fine, I would take the extra step and define clear outcomes, then make the OKRs about those. 

We’re committed to an outcome, but the project we chose will take more than a quarter to complete. What do I put in this quarter’s OKRs?

This situation is only valid if you’ve thoroughly validated the assumptions underlying the idea, and have high-confidence that it will do what you expect. Even then, spending months and quarters without getting any customer feedback is typically a red flag. 

If you haven’t validated the assumptions in the idea then you’ve likely fallen into the big project syndrome, which rarely ends well. 
In either case I recommend disconnecting the goal from the project. An outcomes-based goal may be achieved by one massive project or by five smaller ideas, it doesn’t matter. If the goal that spans more than one quarter consider its lifecycle, and start by setting OKRs for research and discovery first.

In the example above the key results in Q1 can be about Research and Discovery outcomes 

We’re committed to an outcome, but we can’t change it within one quarter 

This happens because you’ve picked a metric that is slow to move, or a target that’s out of reach. In this case you can do one of the following:

  • Pick a less ambitious target that you can achieve in one quarter
  • Go down the metrics tree and pick faster-moving submetrics

Wrong answers in my experience:

  • Extend the goal cycle to 6 months. The objective can definitely span multiple goal cycles, but to be effective, the key results must improve within three months, and ideally more frequently. 
  • Make the KRs about output (project progress) — again, unless fully validated, developing a project is not an indication that we’re making progress on the goal. 

We do research and discovery slowly or sporadically. Should we still rely on them in the OKRs?

This is often yet another symptom of output-focus. Companies underinvest in research and discovery or pressure product teams to cut them short and switch to delivery early. Often this is because leaders think they have nothing to learn or because they’re afraid of “wasting time”. 

I would strongly recommend setting a meta-goal to boost learning:

  • Set a goal to do more research and discovery faster and more often. The outcomes can be about obtaining new learnings, and about releasing with higher levels of confidence
  • Create monthly targets (e.g. last month we’ve ran 1 experiment, let’s try to run 3 this month), and do retrospectives to facilitate continuous improvement.

To help motivate your leaders. see this example that shows how investment in product discovery can create a 10x improvement in business results. 

We don’t know which metrics to use / All our metrics are about revenue/profit/market-share

Without metrics you’re flying in the dark. You don’t know if what you’re doing is working or not. Top-level business metrics like revenue, costs, and active customers are influenced by many factors and teams, and so are rarely useful to guide product OKRs. 

My suggestion:

  • Define your North Star Metric and Top Business Metric 
  • Develop your metrics trees starting with the north star metric and top business metric
  • Measure where you’re underperforming
  • Pick the most pertinent / most underperforming metric to put into the goal 
A metrics tree

We currently don’t measure all the metrics

That again indicates that you’re flying in the dark, which puts you at a stark disadvantage compared to more data-driven competitors. I would create this meta goal: 

  • Objective: achieve high data-proficiency
    • KR: have accurate measurement for key metrics X, Y, W, Z… 
    • KR: anyone in the company can access the metric via… 

This meta-goal can persist for a long time, with the KRs updated quarter by quarter. Start by measuring the most important metrics, then add others. First offer rudimentary data access methods, later refine and add more analytics. Ideally there should be a data team in charge of this goal. 

For more background about the last two questions see this article: 4 Levels of Data Proficiency

At the company level we only set goals for business metrics — revenue, profit, number of paying customers. How can we derive product goals from these? 

This is not an uncommon situation, especially in so-called Sales-driven or revenue-focused companies. I feel it’s OK for the product org to start independently introducing the concept of the North-star-metric, metric trees, and customer-focused goals. Product leaders should communicate clearly why these goals are helping the business (tip: use the metrics tree). More broadly, it’s important to introduce the notion of value-for-user as a key business goal, as it is in Amazon, Google, Netflix and practically any successful tech company. This change goes beyond the mechanics of OKRs and into the culture of the company.

We don’t know what targets to set in the Key Results 

You should aim for values that are ambitious yet achievable. If you’ve been working on the goal for a while you should have a decent sense — look at current trends, consider seasonality, then estimate what might be an ambitious-yet-achievable increment. It’s better that you aim a bit higher and accomplish 80%, than going for an overly conservative number which you’ll surely nail. 

If you’re working on a goal that is new to you, it’s normal that you won’t know what you can achieve. I suggest the following

  • Set in the OKR best-guess targets (AKA “line in the sand”) with a clear understanding that these will need to update
  • In the early part of the quarter attempt to come up with a better estimate — typically because you had a chance to perform research and product discovery. 

My manager is giving me output goals (do this) instead of outcome goals (achieve this)

I’ve dedicated a whole article explaining how to deal with this phenomenon. I recommend reading the whole thing, but here’s the starting point:

Your first mission is to: a) discover the real outcome your manager is after, and b) make the goal about that outcome 

Let’s say your manager says something like “We should redesign the payment flow to be more like Stripe’s”. 

Asking “Why?” may come across as argumentative. Instead qualify, with a statement like “Understood. There are multiple differences, though, so just so we focus on the right things…”, then you can ask question like: 

“What specifically do we see Stripe doing better?” 

“What caused this idea to come about?”

“What should change in the metrics if we’re successful?”

Once you understand what the true desired outcomes are, you can add them to the OKR, then try to come up with some alternative ideas, and do quick assumption validations on these as well as your manager’s idea. If you come back with evidence you may be able to have more constructive discussion and a green light to follow the idea(s) that the evidence favors, rather than the ones that your managers do. 

Be careful not to assume that your manager is clueless or over-controlling. There may be good reasons to focus on this particular idea, so make sure you understand the motivation in full. 

My team doesn’t seem to care about the OKRs

That’s typically the case when the team is:

  • Measured on output — Whether or not the product achieves any user/business outcomes is not their responsibility
  • Skeptical of the goals — They weren’t consulted and are not bought-in
  • Skeptical of the process — Typically because the company itself doesn’t take the OKR process very seriously — setting impossible targets, too many, and keep changing (see my article about 5 common OKR antipatterns). 

In all cases the solution is to up the OKR game across the company (the topic of this article and other resources I list below), AND to change the incentives of the engineers and designers from pushing code into production to achieving a small set of outcomes (I explain how in this article). 

We miss our goals / underdeliver every quarter

You’re either setting overly ambitious goals — too many, too big — or you’re running into some chronic performance problem, for example due to many dependencies, legacy code, code debt… It’s important to diagnose the problem and fix it.

I suggest the following:

  • Do checkpoints every two weeks to measure progress on the goals. Scoring the OKRs can help. 
  • Do monthly retrospectives specifically to discuss progress on the goals (different from Agile retrospectives that are often about delivery). 

Do a final checkpoint + retrospective at the end of goal cycle (typically end of quarter). Discuss:

  • Are we being overly ambitious?
  • What’s holding us back from delivering more (consider 5-whys or other root-cause analysis)?
  • Take action to improve for the next quarter.

It’s important to understand that setting and achieving OKRs is hard. It’s normal to take a number of quarters before you get good at it. 

My company uses SAFe

You’re playing the game in Hard Mode because SAFe (Scaled Agile Framework)  is very much about delivery according to a plan, with cross-team planning, hard release dates, and central project management. 

However, all is not necessarily lost. If your leaders understand the need for research and discovery before committing to delivery, your mission is to carve out space for these vital activities outside the main SAFe model. This is somewhat akin to the idea of dual-track agile — in the early parts of the goals cycle we will use the Lean/Discovery playbook (for example by using the GIST framework), and once we’ve found validated ideas, we can use something like SAFeto optimize for delivery. These methods are complementary and necessary. Keeping your product teams in a state of all-delivery-all-the-time is not simply not viable. 

Final Thoughts

As you can see, a struggle to create OKRs is often a symptom of deeper issues. I realize many of the solutions I’ve given you are not easy to implement; they require changes to mindset, adapting new development processes, and investment in metrics and data infrastructure. Your company may resist due to culture, perceived costs, and inertia.

A good first step is to raise the issues (for example by sharing this article) and discuss the question: should we keep holding to counterproductive practices like goals that aim to deliver on (risk-filled) output roadmaps, or should we try to modernize? 

If the decision is the latter, setting meta-OKRs that measure the changes, and practicing continuous-improvement can help get you to a better place. Be patient and forgiving as it may be a slow progression. Along the way you should start feeling an improvement, and ultimately you’ll find yourself in a place where OKRs are easier and far more helpful — a symptom of an overall improvement in the company.

A couple of resources to help:

  • My ebook OKRs Done Right (subscription to my newsletter required if you’re not already a member) 

My book Evidence-Guided covers goals and OKRs as part of a broader discovery framework called GIST, with many real-world examples.

(Image by Isabel Nobrega)

Join my newsletter to get articles like this 
plus exclusive eBooks and templates

Share with a friend or colleague