OKR → Feature
Mapping.

The translation gap

OKRs are outcomes; the backlog is outputs. Most teams skip the bridge between them, then wonder why six weeks of shipping didn’t move the metric. The mapping is the bridge — an explicit table that says: this feature, against this KR, with this confidence. Without it, OKRs are a wall poster and the backlog is a popularity contest.

The 7-column mapping table

One row per feature. Columns are non-negotiable.

• Objective — the qualitative outcome statement.
• Key Result — the measurable target with a number and a deadline.
• Target Metric — the specific dashboard line: starting value → target value.
• Owning Team — the squad accountable for the KR (not for the feature).
• Linked Features — backlog items hypothesized to move the metric.
• Confidence (0–100%) — per feature, how confident are we it moves the KR? Use the rubric below.
• Cumulative Confidence — per KR, the combined confidence (minimum, not sum — see math).

Worked example — Growth team

Q3 · Growth Squad · 4 PMs / 8 engineers / 2 designers

Objective: Activate 30% of new signups in their first week so trials convert at our model rate.

Key Result / Target	Linked Feature	Status	Confidence	Why this score
KR1 — D7 activation rate 18% → 30%
	Onboarding redesign (3-step)	In build	50%	In build, no measurement yet
	First-value moment trigger	Shipped + measured	90%	+4pp lift in test
	Empty-state nudges	In spec	30%	Spec only, hypothesis untested
Cumulative confidence (min)			30%	Lowest-confidence input drags KR
KR2 — Time-to-first-value 11min → 5min
	Sample data on signup	Shipped, no correlation	70%	Shipped but TTFV not yet correlated
	Skip-the-tutorial path	In build	50%	In build
Cumulative confidence (min)			50%
KR3 — Trial → Paid 9% → 14%
	In-app upgrade prompt	Shipped + measured	90%	+1.6pp in last test
Cumulative confidence (min)			90%	Single high-confidence feature

What we do about 30% / 50% / 90%. KR1 is the weak link. The 30% feature (empty-state nudges) is dragging the whole KR. Decision: either fast-track it into spec-complete by week 4 to lift confidence, or accept the risk and re-state KR1 as “activation 18% → 24%” with an honest discount. We picked the first — the empty-state work moved into the next sprint, confidence rose to 60%, KR1 cumulative landed at 50% by mid-quarter.

Worked example — Retention team

Q3 · Retention Squad · 3 PMs / 6 engineers

Objective: Reduce involuntary churn so net revenue retention crosses 110%.

Key Result / Target	Linked Feature	Status	Confidence	Why this score
KR1 — Failed-payment recovery 32% → 55%
	Smart retry logic (Stripe)	Shipped + measured	90%	Industry benchmark + early data
	Pre-expiry email cascade	Shipped, no correlation	70%	Live but baseline still settling
Cumulative confidence (min)			70%
KR2 — Seat-utilization rate 41% → 60%
	Admin invite flow	In build	50%
	Inactive-seat reminder	In spec	30%	Hypothesis untested
Cumulative confidence (min)			30%	Spec drag

The decision this exposed. KR2 has no high-confidence feature. The team had assumed seat-utilization would “just rise” from invite-flow work. The mapping forced a confession: we don’t actually have a confident plan to move this metric. Outcome: we cut a separate side-project to free a designer for invite-flow work, raised confidence to 70%, and accepted KR2 would land at 50% rather than 60%.

The confidence math

Score each feature using a simple rubric:

Combining feature confidences into a KR confidence: take the minimum, not the sum. Three features at 50%, 70%, 90% give a KR confidence of 50% — because the lowest-confidence dependency is the binding constraint. Sum or average gives a falsely cheerful picture. The minimum is the truth: until the weakest link rises, the KR doesn’t.

Optional refinement: if multiple features independently move the KR (true substitutes, not complements), use the maximum instead. This is rare. When in doubt, take the minimum — it’s the conservative call and it’s usually right.

The orphan check

Every quarter, run the inverse query: list every active feature not mapped to any KR. These are orphans. Some are legitimate — tech debt, security, table-stakes maintenance. Many are not.

Rule of thumb: if a team is shipping more than 20% of capacity into orphans, that’s a strategy problem, not a process problem. Either the OKRs don’t reflect what the business actually values (rewrite OKRs), or the team is shipping discretionary work outside the OKR frame (kill the work or reassign capacity). Both are leadership conversations, not PM conversations.

The unmappable KR

Sometimes a KR has no features behind it. The mapping table reveals an empty row. This is the most useful moment in the entire ritual — you’ve found a KR you committed to without a plan.

Three options, in order of honesty:

• Change the KR — if you don’t have features and can’t commission them this quarter, the KR was wishful thinking. Rewrite or drop.
• Accept the risk — mark the KR as a “stretch” and don’t allocate engineering capacity. Reports must reflect that you’re hoping, not building.
• Commission discovery — spin up a 2-week discovery sprint to find what feature would move the KR. The discovery itself becomes the linked “feature” for the quarter.

Mid-quarter recalibration

At week 4, the mapping gets a one-hour rework. Three questions only.

• What dropped in confidence? — A feature that was supposed to ship but didn’t. A correlation that didn’t hold up. A team blocked on a dependency.
• What rose in confidence? — Anything moved from spec to build, or shipped with positive correlation? Update the row.
• What changed in the world? — Competitor launch, segment shift, regulatory change. Does any KR now belong on the kill list?

If the cumulative for any KR is below 50% at week 4, escalate to the leadership team. There is no virtue in waiting until end-of-quarter to confess a miss.

How to run the mapping meeting

90 minutes. PM leads + EM leads + design lead. All seven columns filled live, decisions made in the room.

• 0–15 min — OKR review. The PM lead reads each Objective and KR aloud. Anyone who doesn’t understand them stops the meeting. Clarity is a precondition.
• 15–55 min — Per-KR mapping. List every candidate feature. Strike out anything not started this quarter. Score remaining features on the rubric. EM lead vetoes scope-impossible items live.
• 55–75 min — Cumulative + decisions. Compute KR confidence (minimum). For any KR below 60%, decide: fast-track, downscope KR, or commission discovery. Decision-by-name in the doc.
• 75–85 min — Orphan review. List unmapped active features. Each gets one of: keep (with justification), defer, kill.
• 85–90 min — Commit. The mapping doc is the source of truth for the quarter. PM lead emails it to leadership the same day.

Common OKR-mapping failures

• Feature-led OKRs — the KR is “ship feature X.” That’s an output dressed as an outcome. Rewrite as the metric the feature is supposed to move, or drop the OKR.
• Sandbagged confidence — everyone scores their own work at 90%. Calibration ritual: a peer EM scores your team’s confidence; you score theirs.
• No orphan tracking — the orphan list is the audit trail. Without it, mapping is performative; people just keep shipping whatever was already on the backlog.
• Mapping stale — the table gets built in week 1 and never touched. Mid-quarter recalibration is non-optional.
• No kill criteria — if a KR is at 30% confidence at week 8, what triggers the kill? Decide that in week 1, write it down, honor it.