// anti-pattern

"Launch the feature" is not a Key Result.

It is the most common mistake in every draft OKR set we review, and the most forgivable. A task feels like commitment. But a Key Result that reads "launch the feature" measures whether you were busy, not whether anything changed.

Here is the test. It is three months from now and your team has done everything on the list. The feature shipped, on time, well built. Now answer honestly: is the business any different? If the Key Result was "launch the new onboarding flow by end of Q3", you can score it 100% and have changed nothing. No new customer behaviour, no moved metric, no evidence the quarter mattered. You measured motion and called it progress.

Why good teams write task-based Key Results

Not carelessness. Comfort. A task is controllable: you can plan it, resource it, and promise it. An outcome is a bet, and writing "increase Day-7 activation from 31% to 45%" means admitting in public that the launch might not work. Task-based Key Results are what an organisation writes when it wants the appearance of goals without the exposure of them. That is why we treat this as a cultural tell, not a formatting error: teams that will not commit to outcomes usually have a leader who grades effort instead of results.

The fix: four questions

Converting a task into an outcome takes about ten minutes of honest conversation. Ask, of the task you were about to write down:

  • What would be different if we succeed?
  • How would we know we have made an impact?
  • What problem are we really solving?
  • Or run the time machine: "It is three months from now and this worked. What changed? What metrics moved?"

Applied to our example: the onboarding flow exists to fix the fact that only 31% of new users are still active a week after signing up. So the Key Result is the number: increase Day-7 activation from 31% to 45%. The launch has not disappeared, it has moved to where tasks belong, and if 45% is a bet rather than a banker, say so when you set it.

How this connects

In our methodology this anti-pattern sits at a junction, and the connections carry most of the reasoning.

The failure it produces is the Activity Trap: the comfortable state where everyone is busy and nothing compounds. The discipline that prevents it is Outcome Thinking, which works in the opposite direction to task-writing: start from the measurable value you want to exist, walk back through the behaviour that would produce it, and only then decide the actions. Tasks are the last step of the thinking, never the first.

The tasks themselves are not demoted, they are relocated. They live in Initiatives, Process Commitments and Experiments, listed under the OKR and discussed every week in check-ins. This separation is the point: when the work and the outcome are written separately, you can see when the work is happening and the outcome is not moving, which is precisely the signal a task-based Key Result is built to hide.

And the deepest argument comes from strategy, not process. Roger Martin's second law, The Customer Is the Only Judge, says internal measures of success are proxies at best and theatre at worst. "Initiative completion" is the purest internal theatre there is. Until customer behaviour changes, nothing has happened, however hard you launched.

The tell, in practice

You rarely catch this at quarter-end, because by then the scoring conversation is a negotiation. You catch it at the start, in the draft. Read each Key Result and ask one question: could we achieve this and have nothing change? If the answer is yes, it is a task wearing a Key Result's clothes. Our AI OKR Coach runs exactly this check, because it is the first of the ten we apply to every draft we are shown.

From the ZOKRI OKR Handbook, the methodology we install and maintain.

// connected concepts
Outcome Thinking → The Customer Is the Only Judge → Explore all 141 notes →
// put it to work

Reading about method is not the same as running it. We install this system and build the capability that stays.

Have AI stress-test your draft OKRs, free →
// proven in practiceA 1,500-person SaaS wrote activity-based OKRs and reported motion, not value.Read the case study →