Writing good OKRs

OKRs (Objectives and Key Results) is a goal setting system that was popularised by Google. To summarise, the objective defines what you want to achieve and the key result defines how you will measure progress towards achieving the objective.

In this blog post, I share my thoughts on how to write good OKRs. I focus on the content of the OKRs themselves rather than what they are or the wider process of creating them. Check the links at the bottom if you want more info about OKRs in general.

Most of these learnings come from my time with the Government Digital Service, BBC and Cazoo, so this will probably be more relevant to people in larger organisations with a focus on digital.

Writing Objectives

The objective defines what we want to achieve. Examples of good objectives include:

Speed up X process
Sell product Y faster with increased margin
Ensure compliance with regulation Z

Objectives should be:

Inspirational
Short, memorable & easy to understand – aim for 10 words or less!
Outcomes, rather than outputs or solutions
Qualitative (or at least they don’t have to be quantitative)
Achievable

Inspirational

Achieving the objective should be something that will get the team out of bed in the morning.

What counts as ‘inspirational’ varies by team. Just make sure this is something the team cares about.

Short, memorable & easy to understand – aim for 10 words or less!

Objectives are meant to quickly communicate what the team want to achieve, so less words is better

Don’t worry if 10 words isn’t achievable. Just make it as short and easy to read as you can

Outcomes over outputs

Focus on the outcome you want to achieve, rather than the outputs you’ll do to achieve the outcome.

Good example: “More efficient planning process across all markets”

Bad example: “Enable new planning features in system”

Why? The new features won’t matter if they don’t deliver the outcome of making planning more efficient.

If you must include an output in an objective be sure that:

The team is confident the output is the right thing for them to do to achieve the outcome
Explain what the outcome is in the objective title (eg. do OUTPUT to achieve OUTCOME)

Qualitative (or at least they don’t have to be quantitative)

Describe the outcome you want to achieve in a qualitative way. Or at least, don’t think that you have to make your objectives quantitative! Remember that key results define what will be measured, not objectives, so unless quantifying an objective makes sense for other reasons it is not worth doing.

It can make sense to include lagging metrics in objectives, where the team assume that achieving all the key results will achieve the lagging metric. For example, if the key result includes some changes in product metrics that together should impact a business metric (eg. profit) by a specific amount, it might make sense to mention the expected profit change in the objective.

Can be achievable within the quarter or longer term

Objectives (eg. “Speed up X process”) might be repeated over multiple quarters (or over whatever other planning cycle you might use in your organisation). That is ok. The important thing is that the key results are achievable within 3 months. That is what tells you whether the objective is met.

Ideally, teams should break objectives up into bitesize chunks. But if that makes the OKR less understandable or inspirational, then I would advise against it.

Writing Key Results

The key result defines how we will measure progress towards achieving the objective. It should be a quantifiable metric that is achievable within a quarter. Examples of good key results include:

DAU/MAU up from X% to Y%
Average value of secondary products bought by customers up from £X to £Y

Questions to ask about each key result

Baselined? If we don’t have actual data, can we estimate?

Target? What specific target or change are the team aiming for?

Measurable? Do we have a data source to measure this?

Observable? Can we see the metric move in response to the team’s actions?

Impactable? Can the team impact this metric on their own? If not, which teams do they need to work with? And are those teams signed up to working with you on this?

A leading indicator? What is the lag between team’s actions and observing a change in this metric? If it’s more than a week or two, it will be difficult for the team to iterate towards the right solution as the feedback loop will be too slow. Are there any metrics the team can use that have less of a lag?

How do you know the key result will deliver the objective?

What key results are missing that might be needed to achieve the objective?

Key results should usually be product metrics

Teresa Torres has written some excellent content on business metrics, product metrics & traction metrics. To summarise:

Business metric = metric that moves the business forward (eg. increased GPU from retail sales)
Product metric = metric that helps us understand if the product is moving the business forward (eg. customers spend more on secondary products when they buy our product)
Traction metric = measures usage of product feature or workflow (eg. % of customers who add secondary product from “Add an accessory” widget on product page)

Key results should usually be product metrics because they are:

leading indicators
within the team’s control to directly influence
focussed on outcome that matters to the user, not an output

It is ok to use a business metric as a key result if these conditions are met.

It is ok to use a traction metric as a key result if the team is confident that increasing the usage of a feature will drive the outcomes they want to see. This can often be the case for a mature product team where the product is well understood.

If no product outcome can be achieved within a quarter

Questions to ask…

How will you know if you delivered the right thing? How will you measure success of the output?
What milestone can the team achieve within the quarter? Can that milestone be articulated as an outcome?
What outcome could we see once this output is delivered?

Examples:

Users can solve X problem using our service
- This defines the problem the product solves for our users, rather than the features we are planning to build
Do enough discovery work on problem to make a build/buy decision
- Rather than just saying “complete a discovery in X” we are being clear about the decision that completing the discovery will enable
4 of 6 teams using new system rather than legacy one
- Ideally OKRs should focus on the value created for users. But in cases where the team is confident that the thing they have built will deliver value once it is adopted, it can make more sense to use a traction metric like this one.

Align OKRs, don’t cascade them

Cascading OKRs (where all OKRs link to parent OKRs so that they link like a tree map) should generally be avoided. This excellent Tability post gives three reasons why:

If one of the top level OKRs are changed, it means everything below it needs to be re-written too
If teams at level N can only write their OKRs if OKRs at the level N-1 are written, then that means a lot of waiting around
Enabling teams struggle to use key results as objectives without shoehorning their goals in questionable ways, or adding extra OKRs for them to connect into. That means losing clarity or focus

Instead of cascading OKRs, teams should align to the intent of the levels above them

Teams should set OKRs that enable them to best contribute to the OKRs of all the levels above them – especially the company OKRs
Some OKRs will link to higher level OKRS directly, others indirectly
When aligning, teams will challenge each other to ensure OKRs at all levels work together well as part of a cohesive strategy.

Credit for this Image

When it is ok to cascade OKRs

I have seen some teams and teams of teams work well with cascaded OKRs. This has worked for them because they work in a well understood domain, with a good set of business/product/traction metrics, that are leading metrics, that are within their control to influence autonomously. If you can cascade OKRs like this then that is fine, but don’t feel like you need all OKRs to cascade perfectly.

More info

I hope you found this post useful! If you are interesting in learning more about OKRs I recommend these books / blog posts: