OKR Planner

What this tool does

CM8-233 is a working OKR planner. You set a handful of objectives for the cycle, attach measurable key results to each, and then run the framework the way it is meant to be run: a short check-in every week that updates the current value and the confidence, a flag when a key result has gone quiet, and a printed review at the end of the cycle that separates the goals you committed to from the ones you stretched for.

Each row in the register is one key result. The objective it serves is a text field you repeat on every key result under it — the board table, the objective chart and the tiles group them back together. That keeps the model simple and the export honest: one row, one measurable outcome, one owner.

Everything runs inside this single file. There is no account, no upload and no network request of any kind, so your plans — the clearest possible statement of where your organisation intends to go — never leave the computer you are using.

What OKRs are

OKR stands for Objectives and Key Results, a goal-setting method developed at Intel under Andy Grove and carried by John Doerr to a young Google, from where it spread through most of the technology industry and well beyond it. The idea survives translation to any organisation because it is small: say what you want to achieve, define how you will know, and check in often enough that the answer can still change your behaviour.

• An objective is qualitative, significant and motivating — a destination worth the quarter. "Win larger manufacturing accounts." "Cut quote turnaround." It should survive being read aloud to the whole team without anyone asking why it matters.
• A key result is a measurable outcome that tells you the objective is being reached — a number moving from X to Y, or a milestone that is unambiguously done or not done. Three per objective is plenty. If all the key results hit 100% and the objective still does not feel achieved, the key results measured the wrong things — which is worth knowing for next cycle.

Outcomes, not activities

The single most common way OKRs fail is that the key results are tasks wearing a costume. "Launch the new website" is a task: you can complete it perfectly and change nothing that matters. "Cut quote turnaround from 6 days to 2" is a key result: it names the change in the world you are paying for, and it stays honest no matter which tasks you attempt on the way. The test is simple — could you complete the sentence "we did the work, and yet the number did not move"? If yes, you have written an outcome; the work is now negotiable and the result is not. If the sentence makes no sense — the work is the result — you have written an activity, and it belongs on a task list, not here.

Activities are not banned. Some outcomes genuinely arrive as a single event, which is what the milestone type is for — "quote template library covering the top ten configurations" is done or it is not. But a plan whose key results are mostly milestones is usually a project plan in disguise. Ask of every milestone: what number would move if this mattered? If you can name it, track the number instead.

How progress is scored

The formula measures the distance travelled as a share of the distance planned, so it works from any starting point: 15% to 60% and 8,200 to 12,000 both start at zero and finish at a hundred. For a lower-is-better key result — turnaround days, onboarding weeks — the same logic runs in reverse, so cutting 6 days to 4 on the way to 2 reads as 50%, exactly as far along as it feels.

Two honest edges. A metric key result whose target equals its start cannot be scored — there is nothing to move — and the tool refuses to save it. And progress above 100% is shown up to a cap of 120%: overshooting is worth seeing, but a 300% bar usually means the target was wrong, not that the quarter was glorious.

Progress is coloured in three bands — 70% and above, 40–70%, and below 40% — and a key result whose last check-in is more than three weeks old (adjustable in Settings) is flagged stale. The flag is deliberately blunt, because an OKR nobody has updated is not a goal, it is a memory.

Committed vs stretch — the 70% rule

The framework distinguishes two kinds of promise, and the distinction is where most of its cultural value lives:

• Committed key results are expected to reach 100%. They are the things the business has promised itself or others — a delivery date, a compliance deadline, a hiring plan the budget assumes. Missing one triggers a real conversation about what went wrong.
• Aspirational (stretch) key results are set beyond what anyone knows how to achieve. Here, landing around 70% is a success — the target existed to pull effort somewhere ambitious, not to be hit. Consistently scoring 100% on stretch goals does not mean the team is excellent; it means the targets are timid.

The tool keeps the two averages separate on the tiles for exactly this reason. If stretch results are judged by committed standards — bonuses docked, names read out — people respond rationally: next cycle every target is one they can already hit, the register turns green, and the framework is dead while appearing to work perfectly. If you take one sentence from this page into your review meeting, take that one.

The weekly check-in

OKRs live or die on cadence, not on the quality of the writing. The check-in is ten minutes per team, once a week: update the current value, set the confidence — on track, at risk, or off track — and write one line in the notes about the blocker if there is one. That is all. Confidence is the leading indicator and the whole point of the exercise: progress tells you where you are, confidence tells you where you will be, and an owner marking a key result "at risk" in week three has given the team six weeks to respond instead of an excuse in week twelve.

The Needs attention table is the standing agenda for that meeting: everything at risk, off track, stale or never checked in, with the blocker and the days since the last update. If the table is empty, the meeting takes two minutes. The stale flag exists because unupdated OKRs are dead OKRs — a plan nobody has touched in a month is not being missed, it is being ignored, and the register should say so.

Scoring at cycle end

At the end of the cycle, score every key result — the progress column is the score — and hold a short retrospective before writing the next cycle. Three questions per objective: did the key results measure the right things? Where a result missed, was it effort, obstacles or a bad target? What do we carry forward, rewrite or drop? Mark finished rows done and abandoned ones dropped rather than deleting them — a dropped key result with a note is a cheap lesson, a deleted one is a repeated mistake. Then start the new cycle with a fresh cycle label; the tiles and charts follow the latest cycle automatically, and the old one stays behind for comparison.

A committed key result marked done at 80% is allowed — real life includes targets that were overtaken by events — but the report will still show the 80%, because the honest number is the useful one.

How many OKRs

Fewer than you want. Three objectives with three key results each — nine rows — is a sensible ceiling for a team or a small company for one cycle, and many good cycles run on less. The arithmetic of focus is unforgiving: five objectives means nothing is the priority, and a register with thirty key results is a spreadsheet of wishes that no weekly check-in can survive. If everything is important, the OKR conversation has not happened yet — the framework's first gift is the argument about what to leave out.

OKRs vs KPIs

They are complements, not rivals. A KPI monitors the health of something you already run — on-time delivery, gross margin, uptime, complaint rate — and its job is to stay in range forever; the right response to a healthy KPI is nothing at all. An OKR exists to change something, has a deadline, and dies at cycle end whether it succeeded or not. A KPI that falls out of range often becomes next cycle's OKR ("get on-time delivery back above 95%"), and a finished OKR often leaves a new KPI behind as the thing to keep watch on. Track your KPIs somewhere permanent; use this planner for the handful of numbers you are actively trying to bend.

FAQ

Do OKRs have to be quarterly? No. The cycle field is free text — quarters are the common rhythm, but six-week product cycles and annual company objectives both work. Keep one label format so cycles sort correctly, and give every key result in the same cycle the same label.

Who should own a key result? One named person — the one who updates it at the check-in and answers "what changed?" A key result owned by a team is owned by nobody. The team field is for grouping, not for ownership.

Should OKRs drive pay and bonuses? The strong conventional answer is no, and the stretch logic above is the reason: pay linked to scores teaches target-lowering within one cycle. Use OKRs to focus effort and surface problems early; evaluate people on more than a percentage.

What if a key result becomes irrelevant mid-cycle? Drop it, note why, and move on. Editing targets mid-cycle to flatter the score is the habit to avoid; dropping a key result that events have overtaken is just honesty.

Can one key result serve two objectives? Pick the objective it serves most and put it there once. Duplicating a row double-counts its progress in every average.

Saving your work

Key results, settings and the report header are written to this browser's local storage as you type, and the toolbar shows the time of the last save. That storage belongs to one browser on one computer: another browser, a private window, a second machine or a clean-up tool that clears site data will not have it.

Treat Export .json as the real save — one file containing everything, which Import .json restores anywhere. Export CSV gives you the register for spreadsheet work. Reset asks twice, then erases everything this tool has stored. There is no undo.

Accuracy & disclaimer

The arithmetic here is deliberately simple — distance travelled over distance planned — and the tool does it faithfully. Everything that matters sits underneath it: whether the objectives are the right ones, whether the key results measure outcomes or activities, whether the current values entered at check-ins are honest, and whether stretch goals are treated as stretch when the scores are read. None of that can be computed.

This is a planning and record-keeping aid, not management advice, and a percentage on a page is not progress in the world. The plan is only as alive as its last check-in.