Good OKRs vs bad OKRs

Good OKRs make review easier

A good OKR is not the one with the most impressive wording. It is the one your team can review without asking, "What did we mean by this?" Good OKRs make direction, measurement, and work visible in separate places.

Bad OKRs usually fail in predictable ways. The Objective is vague. The Key Result is really a task. The Initiative repeats the metric instead of holding the work. Check-ins become status theatre because no one knows what number should move.

Use this article before a planning meeting, after importing OKRs, or whenever a Session looks busy but still feels hard to review.

Availability

The short version

If you can keep only one rule in your head, use this one: Objectives give direction, Key Results measure outcomes, and Initiatives are the connected canvases for the work.

Good versus bad examples

Write Objectives that give direction

An Objective should be qualitative, memorable, and specific enough that people can decide whether the work still belongs under it.

Good Objective patterns:

• Make something easier, clearer, faster, safer, more reliable, or more useful.
• Name the customer, team, or workflow that should improve.
• Avoid stuffing the measurement into the title.
• Avoid listing every task that might happen.

The better Objective should still be understandable after the planning meeting ends. If the title needs a paragraph of explanation before it makes sense, rewrite the title.

Avoid Objectives that are only tasks

Task-shaped Objectives create weak reviews because they can be "done" even if nothing improved.

If the phrase starts with create, publish, migrate, rewrite, audit, interview, or roll out, it is often Initiative work. If the phrase starts with increase, reduce, raise, lower, reach, or shorten, it may be a Key Result.

Write Key Results that can be checked

A Key Result needs a clear unit, current state, and target state where possible. The unit can be a number, percentage, milestone, time, money, custom count, or quality threshold.

The target does not need to be perfect, but it must be reviewable. If no one can update the value during the Session, the Key Result will turn into a guess.

Pick the right unit

Custom units are fine when the team understands them. Write customer interviews, reviewed canvases, or business days instead of vague units like items.

Use Initiatives for work

In Goals/OKRs, an Initiative is the OKR-connected canvas where the work happens. It should be concrete enough that a reviewer can open it and see the plan, context, decisions, files, tasks, subtasks where available, and review material.

Do not use an Initiative as a second metric. The Key Result says whether the outcome moved. The Initiative holds the work expected to move it.

A complete good OKR

Session: 2026 Q3 Support Quality

Objective: Make account and permission problems easier for customers to solve without waiting for support.

Key Result 1: Reduce access-related support conversations by 30%.

Key Result 2: Publish reviewed Help Center coverage for workspace roles, sharing, deactivated access, invites, and billing ownership.

Initiative: Rewrite workspace access docs in a connected canvas with support examples and reviewer notes.

Check-in: Key Result 1 is at 18% reduction. Workspace roles and sharing docs are published. Invite troubleshooting is in review, and deactivated-access recovery is still missing screenshots.

This works because the Objective explains direction, the Key Results make review possible, the Initiative gives the work a canvas, and the Check-in tells the latest story.

Common bad OKR patterns

Clean up imported OKRs

Import OKRs with AI can turn planning notes into draft Sessions, Objectives, Key Results, and Initiatives, but you still need to review the structure before saving.

Check imported content for:

• tasks that were placed as Key Results
• broad statements that should become Objectives
• Initiative titles that only repeat the Key Result
• missing units
• duplicated Objectives from messy source notes
• owner notes or meeting comments that should not become row titles

If the draft is mostly right, edit the lines before saving. If it is structurally wrong, cancel and clean the source text first.

Use Tree view to check structure

Tree view is useful when the Session has cascading OKRs. It shows hierarchy like a map, so you can see whether Objectives and Key Results roll up in a way people will understand.

Use Tree view to answer:

• Does this child Objective really support the parent Objective?
• Is this Key Result under the Objective it measures?
• Did a dragged item land in the right place?
• Does the hierarchy help review, or did it become decoration?

Do not use hierarchy to hide work. If the item is execution detail, use an Initiative canvas instead.

Check-ins should preserve the story

Good Check-ins do more than update a number. They explain what changed since the last review, what is blocked, and what should happen next.

Snapshots are only as useful as the Check-ins behind them. If every Check-in is vague, the Snapshot preserves vagueness.

What can go wrong

If every Key Result sounds like a task, move the task-shaped items into Initiatives and rewrite the Key Results as measurable outcomes.

If the team cannot agree whether an Objective is complete, the Objective is probably too vague or the Key Results do not prove the right outcome.

If a Key Result cannot be updated, change the unit or assign a clear owner for the data source before the next Check-in.

If the Session has too many rows, use Tree view to identify duplicate hierarchy and merge or archive stale work according to your team's policy.

If people keep asking where the work lives, add or rename Initiatives so each important body of work has a clear connected canvas.