If you read enough real OKR documents, and I have read a great many, you start to notice that most key results are not key results at all. They are tasks wearing the costume of a measurable outcome. “Launch the new onboarding flow.” “Hire three engineers.” “Publish twelve blog posts.” These look like key results because they are specific and they can be ticked off, but they describe activity rather than result, and that difference is the whole game.
The tell is that you can complete it without anything improving
Here is the test I use. Imagine you fully completed the key result, and then imagine that nothing about the business actually got better. If both of those things can be true at the same time, you have written a task.
You can launch the new onboarding flow and have activation stay exactly where it was. You can hire three engineers and ship no faster. You can publish twelve blog posts that nobody reads. In every case the item is done, the box is ticked, and the outcome you presumably cared about has not moved an inch. A real key result does not allow this. If you hit it, something that matters has, by definition, changed.
That is why the strongest key results are almost always about a number moving from one value to another. “Increase activation rate from 40 percent to 55 percent” cannot be completed without activation actually improving. The work, the onboarding flow, is how you might get there, but the key result is the result, not the work.
Why teams default to tasks anyway
People do not write task-shaped key results because they are lazy or confused. They write them because tasks are safe and outcomes are frightening. A task is fully within your control. You decide to launch the onboarding flow, and you launch it. Whether it works is a separate question, and a task lets you avoid that question entirely.
An outcome-based key result puts you on the hook for something you only partly control. You can do excellent work on activation and still miss the target because of factors outside your influence. That exposure is exactly why outcome key results are valuable, and exactly why people instinctively avoid them. The discomfort is the point. If a key result does not make you slightly nervous about whether you will hit it, it is probably not measuring anything that matters.
The “from X to Y” structure forces honesty
The single most useful discipline I can recommend is to write every key result in the form “increase, reduce, or maintain some metric from a starting value to a target value.” It sounds mechanical, and it is, but the structure does something important. It forces you to know your baseline.
A surprising number of teams cannot write the “from X” part because they do not actually know where the metric stands today. That is itself a finding worth having early, before you have committed a quarter to moving a number you were not measuring. The “to Y” part forces a second honest conversation, which is how much change is realistic and ambitious at the same time. If you cannot fill in both ends of that sentence, you do not yet understand the key result well enough to commit to it.
Tasks still matter, they just are not key results
The pushback I always get is that some of these tasks are genuinely necessary, and that is true. Sometimes the entire point of the quarter is to ship a specific thing, and the shipping itself is the deliverable. Fair enough. But that work belongs in your project plan, your roadmap, your task tracker, sitting underneath the key results as the means of achieving them. It does not belong in the key result line itself.
The healthy structure is an objective that states what you want to be true, two to four key results that measure whether it became true, and beneath those, the tasks and projects that are your bets on how to move the numbers. When you keep tasks in their proper place, you preserve the ability to change tactics mid-quarter. If the onboarding flow ships and activation does not move, an outcome-based key result tells you to try something else. A task-shaped key result just tells you that you are done, which is the worst possible message when the outcome has not arrived.
Make the structure unavoidable
In practice, the reason task-shaped key results survive is that nothing in the process stops them. They get written, they get approved, and three months later everyone is surprised that hitting all the key results did not move the business. The fix is to make the outcome discipline part of how key results are entered and reviewed in the first place, which is one of the quieter benefits of running OKRs in dedicated OKR software rather than a spreadsheet, because the structure prompts for a baseline and a target every time and makes the task-shaped shortcut harder to take without noticing.
When you write key results properly, the quarterly review changes character entirely. Instead of a status update where people report what they finished, it becomes a real conversation about what moved, what did not, and why. That conversation is the entire reason to run OKRs in the first place, and you only get to have it if your key results were measuring outcomes all along.
