OKR Goal-Setting Rules

An OKR should describe a change in the world the team wants to cause, measured by results that would only be true if that change actually happened — not a list of things the team plans to be busy doing. Every rule below exists to keep OKRs from quietly degrading back into a task list with a fancier name.

Outcomes, not tasks

• Write the objective as a qualitative, ambitious statement of where the team wants to be, not an action ("Make onboarding the reason customers stay past month one," not "Improve onboarding flow"). The objective should be inspiring enough to remember without looking it up.
• Write each key result as a measurable outcome that would only be true if real progress happened, not as a completed task. "Ship the new onboarding flow" is done the moment it's shipped regardless of whether it worked; "Increase day-30 retention from 42% to 55%" can only be true if it actually worked.
• Use the test: could this key result be marked 100% complete while the underlying problem is completely unsolved? If yes, it's a task in disguise and needs to be rewritten as an outcome.

Measurable key results

• Every key result needs a number: a specific starting value and a specific target value, not a directional wish ("increase," "improve," "reduce churn") with no baseline or target attached.
• Make sure the number is genuinely measurable with data the team can actually access on a reasonable cadence — a technically precise metric that can only be measured once a quarter, after the fact, doesn't let the team course-correct mid-cycle.
• Prefer outcome metrics the team can significantly influence over metrics driven mostly by factors outside their control — a key result the team has little real leverage over produces frustration rather than focus.

The 3-5 cap

• Cap key results per objective at 3-5, and cap objectives per team at a similarly small number (commonly 1-3 per cycle) — more than that stops being a set of priorities and becomes a list of everything the team is doing, which defeats the purpose of prioritizing at all.
• When a new key result seems necessary mid-cycle, treat it as a forcing function to ask what existing one it should replace, not just to add — an ever-growing OKR set is a sign the organization hasn't actually made the prioritization trade-offs OKRs are meant to force.
• If a team genuinely can't narrow to a handful, that's usually a signal the objective itself is too broad and should be split into two more specific ones, or that not everything currently being tracked is actually strategic this cycle.

Ambition calibration

• Calibrate stretch objectives deliberately: if a team is scoring 100% on every key result every cycle, the targets are too safe to be doing their job as a forcing function for ambition.
• Distinguish committed OKRs (targets the team must hit, tied to operational reliability) from aspirational/stretch OKRs (ambitious targets where 70% is a genuinely good result) — scoring both against the same 100%-expected bar misrepresents what kind of goal each one is.
• Communicate explicitly, at the time OKRs are set, which category each one falls into — a stretch goal scored and reacted to as if it were a committed one undermines the psychological safety needed to set ambitious targets at all in future cycles.

Scoring discipline

• Score key results on the actual numeric progress against the stated target (e.g., 0.0-1.0 or 0-100%), not on subjective effort or how hard the team worked — the point of a number-based key result is that it removes ambiguity from scoring.
• Score at the cadence set at the start of the cycle, not only retrospectively at the end — a mid-cycle score, even an imperfect one, is what lets a team catch a stalled key result while there's still time to change course.
• Treat a low score on a stretch OKR as information, not as a verdict on the team — the follow-up conversation should be about what was learned and what to change next cycle, not about assigning blame for an ambitious target that wasn't fully hit.

Anti-patterns

• Sandbagging: setting deliberately conservative targets to guarantee a high score. This defeats the purpose of OKRs as a forcing function for ambition and is usually a symptom of OKR scores being tied too directly to performance ratings or compensation — fix the incentive, not just the behavior.
• Task lists as key results: key results phrased as completed activities ("Launch feature X," "Run 5 user interviews") rather than outcomes those activities were meant to produce. A task can be a supporting initiative underneath a key result, but it shouldn't be the key result itself.
• Too many objectives: treating OKRs as a comprehensive inventory of all team work rather than a short list of the highest-priority outcomes — if the OKR set tries to represent everything the team does, it's not actually prioritizing anything.
• Set-and-forget: writing OKRs at the start of a cycle and never revisiting them until the final score — without regular check-ins, OKRs stop functioning as a steering tool and become a retrospective grading exercise instead.
• Cascading rigidly top-down: forcing every team's key results to be a literal sub-metric of the objective above it, with no room for team-level judgment about how they contribute — this produces technically-aligned OKRs that no one on the team actually feels ownership over.

What to avoid

• Don't write an objective so broad it could apply to almost any initiative the team might undertake ("Delight our customers") without key results specific enough to make it falsifiable.
• Don't mix committed and aspirational key results under one objective without labeling which is which — a reader can't tell whether 70% on that objective is a success or a miss.
• Don't let OKRs and day-to-day task tracking merge into the same document — OKRs are the small set of outcomes that matter most this cycle; the task list is everything being done to try to get there, and collapsing the two erases the prioritization OKRs exist to provide.