How to write OKRs

Writing good OKRs is an art. But don't worry, it's something you can learn and practice and get good at over time.

In this article we'll talk about what makes an OKR "good", and how you can tell and good OKR from a badly written OKR, with some examples.

How to write good Objectives

Objectives are the outcomes you want to achieve.

If you're not sure whether your objective is describing an outcome, try reading it out loud and then asking "so that..." and fill in the blank. For example:

"Drive up successful account creation"

Sounds like a reasonable outcome? But... why should we increase sign-ups? What value does that bring?

Also it's written as an action, a verb. "Drive up" is what you're doing, but what is the result of driving it up?

Objectives should be qualitative and aspirational, but also specific and obvious. It should be clear to anyone in the business a) whether or not the outcome has been achieved, and b) why it's valuable.

If we ask ourselves "so that...", we might get to:

"Drive up successful account creation, so that new users stick around for longer"

Now we're getting somewhere! Let's try again: "so that..."

"Drive up successful account creation, so that new users stick around for longer, so that they see the value of our product and eventually pay to upgrade"

Almost always you'll eventually get to a commercial reason for doing something - more sales, more revenue. That's OK. But don't go too high level or all your objectives will end up being just "more sales!"

And watch out for being over-prescriptive of the solution when writing objectives. Sometimes you and your teams and your company may have already decided on a particular solution, but most of the time you want to give yourself flexibility to pivot and change tack if you learn something new.

In this case a more open-ended objective could be:

"Customers understand the value of our product and choose to stick around for longer"

In general you should know your business's data well enough that you know which are the key metrics and levers you can pull, and how big the value is of pulling each one. Then you choose the most impactful, and set objectives around that.

How to write good Key Results

You've probably heard of SMART:

• Specific: not general or vague, but precise and clear
• Measurable: able to be counted, or quantified in some way
• Achievable: must be doable within a reasonable amount of time
• Relevant: contributes directly to a goal we're working towards
• Time-bound: has an end point or a known amount of effort

As a good starting point, key results should always be SMART.

Usually a key result is a metric, with a goal: "move X measure from Y to Z". It might be written as "increase" or "decrease", whichever is the positive direction.

When using this kind of key result you can see gradual progress as you move through the quarter, and it is clear whether you succeeded or not because you hit the target.

The trick is picking the right metric. Does it really represent the outcome that you want? Can it be "gamed" to cheat? For example "app downloads" - could be a good metric because having lots of downloads means lots of people using your app, which is the goal.

But, what if the people who download the app don't end up using it? You could succeed with your key result but get zero positive impact. Probably something like "app installs with 3+ opens in first 30 days" would tell you that people are actually engaging with your product.

Metrics can be leading and lagging. Leading metrics are higher up the funnel and tend to be more volatile and easy to affect. Lagging metrics are at the end of the funnel or even much further down the customer lifecycle, and are harder to observe changes to.

Choose a mix of leading and lagging metrics when writing key results but make sure you can measure any lagging ones in-period. It's no good having something like "annual repeat orders" if you're in Q1 because you won't be able to see those repeat orders for another 9+ months!

Sometimes key results can be a date. This is if the thing you're building or trying to get done is pretty well known, and there are some constraints on exactly when it goes live. If the date is the most important thing, it's OK to call that out in the key result.

Sometimes key results can be a deliverable. Perhaps you have a role in supporting a wider intiative, or you have something that "just has to be done", or it's a complex or unknown challenge that has to be overcome and you're trying to prove a new capability, then having a key result that says "we did a thing" is OK too. But use this sparingly!

Well written key results should be positive in nature. While it's sensible to have guardrail metrics to avoid unintended side-effects of changes to your product, the goal you're going for will usually be positive. Positive framing is more motivational, and clearer for people to see the value.

Process for writing OKRs

In a word, iteratively! Start with a draft. Don't worry too much about specific wording, or metrics. Just a brain dump of what you think.

Get a few different people to do the same. In your team, the Product Manager, Engineering Lead, and Design Lead could all do it individually.

Then get together and compare and discuss your ideas. There's magic in the discussion! You'll find that you agree on some parts and not on others. You'll think of ways to improve each other's phrasing, and metrics. You'll spot issues with certain metrics, and can suggest ways to improve them.

The other way to ensure how you write good OKRs is to do it collaboratively.

Combine your ideas into a second draft, and then share it with others outside your team. Get their input, and refine again into a third draft. Then publish more widely and that's your "version 1". As you go through your quarter you can always iterate further.

More detail here on OKR planning process.

That's a wrap!

Hopefully these tips help you to write better OKRs. Using OKR software for recording all your OKRs can make them much easier to share and for stakeholders to engage with too.