OKR Tracker vs Roadmap: Outcomes Are Not a Sequence of Work

Every planning season the same argument shows up in a new costume: "Do we plan around OKRs or around the roadmap? Aren't they the same thing?" Teams treat the two as rivals, pick one, and then quietly rebuild the other inside it. The OKR tracker sprouts a list of initiatives under every key result. The roadmap sprouts a swimlane called "Improve retention." Both artifacts end up doing half of two jobs and all of neither.

A few years ago I sat in a quarterly review where a VP stopped the presenter on slide four. The slide was the roadmap: fourteen items, three swimlanes, quarters across the top, everything green. She asked one question: "Which of these improves retention?" The room went quiet. Retention was a company objective. The roadmap was one we were proud of. Nobody could draw a single line between them. I owned that roadmap, so the silence was mine to explain.

That meeting is the whole argument for keeping two artifacts. An OKR tracker tells you whether the outcome is improving. A roadmap tells you what work you are doing, in what order, and what you refused to do. Merge them and you lose both answers. Here is how I run the split.

The short version

• An OKR tracker measures outcomes. Three to five objectives, each with measurable key results scored 0.0 to 1.0 at quarter end, with a weekly confidence read in between. The question it answers: is the metric moving.
• A roadmap sequences work. Workstreams down, quarters across, dependencies marked, and a named list of what you are not doing. The question it answers: is the order still right, and what did we refuse.

One measures. One sequences. The link between them is a single discipline: every roadmap item names the key result it claims to move. An item that traces to nothing is the first candidate for the cut list.

What an OKR tracker is for

An OKR has two parts, and most teams get the second one wrong. The objective is the outcome you want, stated so the team remembers it. The key result is the measurable consequence of getting there. "Reduce checkout abandonment from 38% to 28% by end of Q3" is a key result. "Launch the new platform" is not. That is an initiative wearing an objective's badge, and it belongs on the roadmap, where sequence and dependencies live.

The OKR tracker exists to enforce two kinds of honesty. Weekly honesty: a confidence read on every key result, 1 to 5, so a KR drifting in week four gets seen in week four instead of week twelve. And end-of-quarter honesty: a score from 0.0 to 1.0 per key result, where a 0.7 on a stretch goal is a win and a polite 0.9 teaches you less than a truthful 0.4. The whole thing fits on one Excel tab. If your OKR template needs a second file, it has started doing someone else's job.

Who reviews the OKR tracker

The team that owns the outcomes, with leadership reading over their shoulder. The weekly review is fifteen minutes and it is about confidence, not activity. Nobody presents what they shipped. The metric either moved or it did not, and the only interesting conversation is why. The moment the meeting drifts into "here's everything we delivered," you are in the wrong meeting. That agenda belongs to the roadmap review.

What a roadmap is for

The roadmap answers a different question from a different room: what are we building, in what order, and what did we push out to make the order possible. I have written before that the roadmap is what you are not doing. Most roadmaps document commitments. The strongest ones document refusals: what got cut, what got deferred, and what would have to change for a deferred item to come back. The doing is just what's left.

A roadmap is a forecast, not a contract, and it decays. Quarter one is firm, quarter three is a sketch, and pretending otherwise is how programs end up defending eighteen-month-old commitments in a reorg. This is also why the format matters: a table-driven Excel roadmap gets updated in five minutes when a status changes, where a PowerPoint roadmap gets updated once a quarter and is wrong for the other eleven weeks. (If you run live planning sessions, there is a $49 interactive web-app version; the $29 Excel template covers everything else.)

Who reviews the roadmap

The program team monthly, executives at the QBR. The review asks two questions: is the sequence still right, and what came in that forced something out. If nothing has been cut in two quarters, the roadmap is not being reviewed. It is being recited.

The honest comparison table

How they feed each other

OKRs feed the roadmap. The objectives get written first, at the top of the quarter. The roadmap is then the current hypothesis for how the key results get hit. The discipline is the trace pass: walk the roadmap item by item and make each one name the key result it claims to move. Some items will trace to nothing. That is not an administrative gap. That is the cut-list conversation starting itself, and it is the conversation my VP started for us on slide four.

The roadmap feeds the OKRs back. When the weekly confidence read on a key result drops from 4 to 2, the tracker has done its job: it detected the drift. The response lives in the roadmap. Resequence, cut something to make room, or accept the miss out loud. A confidence drop with no roadmap change is a team watching a number fall.

The tracker detects. The roadmap responds.

When you can get away with just one

Some teams genuinely need only a roadmap:

• Operational and platform teams where the metric is uptime or cycle time, watched continuously, not scored quarterly. A quarterly target on a number you defend daily is ceremony.
• Fixed-scope delivery work. If the contract defines done, the interesting questions are sequence and dependency. That is roadmap territory.
• Programs in their first 90 days. The right first artifact is the charter, then the roadmap. OKRs before you understand the baseline produce made-up numbers.

And some teams need only the OKR tracker: teams under about five people, where the backlog is the roadmap and adding a second planning artifact is weight without benefit. Everyone else, meaning any program with more demand than capacity and an executive who asks why, needs both. The demand is why you need the refusal list. The executive is why you need the metric.

The most common failure mode

The failure mode is not choosing wrong. It is merging.

It starts innocently. Someone adds an "initiatives" column to the OKR tracker so the team can see what work supports each key result. Reasonable. Then the initiatives get status colors. Then dates. Then dependencies. By month three the OKR review is a delivery review: every row gets scored on whether the initiative shipped, everything scores 1.0, and the metric did not budge. You shipped everything and improved nothing, and the artifact can no longer tell you why. An OKR tracker with initiatives nested under each key result is a roadmap wearing an OKR costume.

The mirror image is just as common. A swimlane appears on the roadmap called "Improve retention," with no deliverables in it, floating across three quarters. That is an OKR wearing a roadmap costume, and it fails the other way: it occupies a lane, it has no sequence, and nobody can say what refusing it would free up.

The fix is not a cleverer combined template. The fix is two small artifacts with one traced link between them.

Practical setup for the quarter

1. Week 0: write the OKRs first. Three to five objectives, two to four key results each, every key result a number with a date. If you cannot put a number on it, it is an aspiration, not a key result.
2. Week 0-1: reset the roadmap against them. Sequence the work, then run the trace pass. Every item names its key result. Items that trace to nothing go to the cut list, or they expose a missing objective. Both findings are worth the hour.
3. During the quarter: run the two reviews separately. Fifteen minutes weekly on OKR confidence. One monthly session on roadmap sequence. Different questions, different meetings. Combining them is how both jobs get done badly.
4. Quarter end: score, then reset. Score every key result 0.0 to 1.0, honestly, in one sitting. Reset the roadmap the same week, while the scores are still embarrassing enough to change the sequence.

The first quarter is rough. The trace pass will orphan a third of your roadmap, and the first honest scoring session will produce numbers nobody wants on a slide. Run it anyway. By the second quarter the orphans stop getting proposed, because everyone knows the first question they will face.

The bottom line

The OKR tracker measures outcomes: quarterly targets, weekly confidence, scores you can defend. The roadmap sequences work: what you are doing, in what order, and what you refused. They are not rivals, and they are not the same artifact. They are two answers to two questions asked in two different rooms, joined by one traced line.

If you are forced to start with one, start with the OKRs. A roadmap without a target is just a queue, and a queue defends nothing. But build the roadmap the same week, because an outcome with no sequence of work behind it is a wish with a number attached. The pair is the point.