How to Write OKRs That Are Not Just a Task List

Every autumn, teams sit down to draft next year’s OKRs and produce something that looks like this: “Objective: Improve the website. KR1: Launch the new homepage. KR2: Write 20 blog posts. KR3: Migrate to the new CMS.” It reads like a plan. It is actually a task list, and it tells you nothing about whether any of the work mattered.

The fix is mostly a writing problem. OKRs fail when the language describes activity instead of change, and you can usually repair a draft in an hour by rewriting sentence by sentence.

Objectives Describe A Change, Not A Project

An objective should say what will be different for someone when you succeed. “Improve the website” is a direction. “Launch the new homepage” is a project. Neither tells a reader why it matters.

Before:

Objective: Revamp the onboarding experience.

After:

Objective: New customers reach their first successful report without needing to contact support.

The second version names who benefits, what success looks like for them, and implies how you will measure it. It also leaves room for the team to choose the work, which is the point of the format. The What Matters site, run by John Doerr’s team, has a large collection of examples if you want to see how other organizations phrase objectives.

Key Results Are Measurements, Not Deliverables

The most common mistake is writing key results as tasks: “Launch X”, “Hire Y”, “Write Z”. A task can be completed while achieving nothing. A key result should be a number that moves only if the work actually helped.

Before:

KR1: Launch an in-app onboarding checklist.

KR2: Publish 10 new help articles.

KR3: Run 3 customer interviews.

After:

KR1: 60% of new accounts create their first report within 7 days, up from 35%.

KR2: Onboarding-related support tickets fall from 140 a month to under 60.

KR3: Median time from sign up to first report drops from 4 days to 1.

The checklist, the help articles, and the interviews are still good ideas. They now live in the plan for hitting the key results, where they belong.

Every Key Result Needs A Baseline

“Increase activation to 60%” is meaningless if nobody knows whether activation is currently 20% or 55%. Write the starting point into the key result. If you do not have a baseline, the honest first key result is often “measure it”: establish the number in the first month, then set the target.

Watch the verbs while you are at it. “Improve”, “enhance”, “optimize”, and “drive” usually hide the absence of a number. If a key result still makes sense with the verb deleted and a figure added, rewrite it that way.

Fewer Is Better

Three objectives with three key results each is plenty for most teams. A list of seven objectives is a sign that nothing was prioritized, and it guarantees a messy end of quarter review. If you are struggling to cut, the decision request email format is a useful way to ask your manager to choose between two candidates explicitly.

Keep Tasks Visible, Just Not In The OKR

Teams resist removing tasks from OKRs because tasks are what they actually manage day to day. Keep them, in a linked project plan or board, and tag each one with the key result it serves. That way the OKR stays short and outcome-based, and the work is still tracked. A task that does not map to any key result is worth questioning. For a team that needs to agree what it owns before it sets goals at all, a one-page team charter is the better starting point.

A Context For Rewriting OKR Drafts

This is a task a rewriter is genuinely good at, as long as you constrain it.

A Wrivio Context for OKR drafts could say:

Rewrite these OKRs. Each objective should describe a change for a specific person or group, not a project. Each key result should be a measurable outcome with a baseline and a target. Where a key result is a task, rewrite it as the outcome that task is meant to produce and list the task separately under “Supporting work”. Keep every number, date, and team name exactly as written. Do not invent baselines or targets; write “baseline needed” where none is given.

Press Ctrl+Shift+Space, paste the draft, and review the diff. The “baseline needed” markers are the useful output: they show you exactly which numbers your team still has to find before the plan is real.

Common Questions

What is the difference between a key result and a task?

A task is something you do, such as launching a feature. A key result is a measurable change that shows the task worked, such as a rise in the share of customers who use the feature. Tasks belong in the project plan that supports the key result.

How many OKRs should a team have?

Most teams do well with two or three objectives and three key results each. More than that usually means priorities have not been chosen.

Can a key result be binary, like “ship the new pricing page”?

Occasionally, for a genuine milestone, but it should be the exception. Binary key results can be completed without improving anything, so pair them with a measurable outcome where you can.

What if we do not have data for a baseline?

Make establishing the baseline the first key result for the quarter, then set the target once you have the number. Writing a target without a baseline is guessing.

Download Wrivio for Windows to turn a task-list draft into outcome-based OKRs in a few passes.