Rewrite the OKR 'Launch saved cards' as an outcome-based OKR.

Objective: customers pay quickly and reliably on mobile. KRs: mobile checkout conversion 61% to 65%; payment success at or above 99.9% weekly; p95 latency 900 to 600 ms. Saved cards becomes one initiative (a bet) toward those KRs.

How do you make sure technical investment happens?

Reserve explicit, visible capacity on the roadmap (often 20–30%) with its own measurable outcomes, agreed jointly with product and adjusted from data.

Why use a now / next / later roadmap?

It communicates priorities without false precision; detailed dates are given only for near-term committed work, using forecasts.

Roadmaps and OKRs With Product — The Engineering Manager Handbook (Development Manager)

Scenario

Example organisation: product publishes a roadmap of features with dates. Engineering's reliability and platform work isn't on it, so it's done "in spare time" — or not at all. OKRs list projects ("launch saved cards") rather than outcomes, and nobody checks whether they mattered.

What you see on the team

Roadmaps of features and dates, with no space for technical work.
OKRs that are task lists.
Engineering surprised by commitments made without them.
No review of whether shipped work achieved anything.

The common mistake

Treating the roadmap as product's feature list and OKRs as project checklists, instead of a joint plan of outcomes that includes technical investment.

Why it happens

Features are concrete and easy to promise; outcomes and technical investments are harder to express. OKRs are meant to be ambitious goals with measurable results — "Objectives and Key Results", a goal-setting method built around measurable outcomes (What Matters) — but they're often reduced to deliverables.

The playbook

Plan jointly: the engineering manager, product manager and tech lead build the quarter's plan together.

Write outcome-based OKRs:

Objective: Customers pay quickly and reliably on mobile
 KR1: Mobile checkout conversion 61% -> 65%
 KR2: Payment success rate >= 99.9% every week (SLO)
 KR3: p95 checkout latency 900 ms -> 600 ms

Initiatives (bets, not KRs): saved cards; one-tap wallet payments; payment-provider failover

Reserve explicit capacity for technical investment and operations (e.g. 20–30%), visible on the roadmap with its own outcomes (deploy time, incident rate, cost).

Use now / next / later roadmaps instead of precise dates for everything beyond the current quarter.

Review outcomes: at mid-quarter and quarter end, check KRs — and kill or change initiatives that aren't moving them.

What to say

To your product counterpart:

"Could we plan the quarter together and write KRs as outcomes — conversion, success rate, latency — with features as bets underneath? I'd also like 25% visibly reserved for platform and reliability, with its own outcomes, so it stops competing invisibly with features."

Trade-offs

Outcome OKRs are harder to control than task lists; that's the point — they keep teams focused on impact.
Fixed technical allocation is blunt; adjust it based on incidents, debt and delivery data.
Now/next/later frustrates stakeholders who want dates; give forecasts for committed items.

Signals it's working

OKRs measure outcomes; initiatives are treated as bets.
Technical investment is visible on the roadmap and protected.
Initiatives get changed or stopped based on KR progress.
Engineering is part of commitments before they're made.

Key points

Build roadmaps and OKRs jointly: engineering manager, product manager, tech lead.
Key results measure outcomes; features are bets towards them.
Reserve visible capacity for technical investment, with its own outcomes.
Review KRs mid-quarter and change course when bets don't work.