A strategic OKR is one you could not have written before deciding what your product will not pursue this quarter — it names a specific bet, ties to one strategic choice, and makes a real tradeoff visible. Most OKRs skip that step and just restate the roadmap as a goal with a due date.
Strategic OKRs trace back to one specific strategic choice and force a visible tradeoff — what you're doing instead of something else. Output OKRs just restate roadmap items with a percentage attached. If an OKR would fit unchanged inside three different strategies, it isn't actually one.
Why Most OKRs Are the Roadmap in Disguise
Most OKRs fail to encode strategy because teams write them backward: they take an already-decided roadmap item, phrase it as an objective, and attach a key result that just measures shipping it. The format looks strategic. The thinking behind it never left the backlog.
This is the specific failure mapped out in the gap between a strategy deck and daily execution — the offsite produces bold language about market position, and the mechanism that's supposed to translate it into quarterly goals defaults to whatever is already sitting in the backlog. Nobody decides this on purpose. It happens because writing an OKR from a roadmap item is fast, and writing one from a genuine strategic choice requires the choice to already exist.
A roadmap-in-disguise OKR usually shows a few recognizable tells:
- The key result is a ship date with a checkbox, not a change in customer or business behavior
- The objective restates a theme that was already committed to before the OKR-writing session started
- Nothing in the OKR implies a segment, geography, or use case the team is deliberately not serving this quarter
- Every team in the company could hit its OKRs and the company's competitive position would look exactly the same
- The same key result would appear on the scorecard almost regardless of which strategy leadership had picked
Christina Wodtke's Radical Focus pushes the same point from a different angle: a goal already sitting on the roadmap is a task, not an OKR — the format should be reserved for choices that require an actual bet. For a deeper walkthrough of how strategic choices are supposed to cascade from position to action, the complete guide to advanced product strategy covers the layer above OKRs — the actual reasoning an objective should be compressing.
The difference shows up cleanly once you compare the two side by side:
| Dimension | Roadmap-in-Disguise OKR | Strategic OKR |
|---|---|---|
| Origin | An already-committed backlog item | A specific strategic choice or bet |
| Key result shape | "Ship feature X by Q3" | A measurable shift in customer or business behavior |
| What it reveals | Nothing about what's not being done | An explicit tradeoff — what's deliberately deprioritized |
| Risk if hit | Feature shipped; strategy unchanged | Directional evidence the strategic bet is working |
| Portable across strategies? | Yes — would fit almost any roadmap | No — only makes sense under this specific strategy |
Every row in the right column requires someone to have made a strategic choice before the OKR was drafted — that's the actual work most OKR-setting sessions skip.
There's a reason vague, roadmap-shaped objectives feel safer to write. Decades of organizational psychology research from Edwin Locke and Gary Latham on goal-setting theory found that specific, challenging goals reliably outperform vague or "do your best" goals on actual performance — but specificity is exactly what forces a visible choice, and choices create friction a generic objective avoids. Writing "improve retention" costs a team nothing in a planning meeting; writing "grow week-4 retention for SMB self-serve, not enterprise" invites a debate that most teams would rather skip.
Output OKRs vs. Outcome OKRs: The Real Distinction
An output OKR measures what you built or shipped; an outcome OKR measures the change in customer or business behavior that shipping was supposed to cause. The distinction, sharpened by Marty Cagan's writing at the Silicon Valley Product Group, is the single biggest lever for making a goal strategic instead of operational.
Cagan's argument, developed across years of writing for product teams, is that a roadmap already tells engineering what to build — an OKR that just restates it is redundant with a project plan. The only thing an OKR should add is a hypothesis: if we do this, some measurable behavior will change. Strip the hypothesis out and you're left with a task list wearing a strategy costume.
Say a team ships a redesigned pricing page. "Launch new pricing page" is an output — true the moment the deploy finishes, regardless of what happens after. "Increase self-serve upgrade rate among trial users who hit a usage limit" is an outcome — it stays unresolved until real customers behave differently, which means the team is still on the hook after the release, not just before it.
Committed vs. Aspirational Is a Different Axis
John Doerr's Measure What Matters popularized a second useful distinction: committed OKRs (targets the team will hit, full stop) versus aspirational OKRs (stretch goals the team may only reach 60-70% of). That axis is orthogonal to output-versus-outcome — you can have a committed output OKR, an aspirational outcome OKR, or any other combination. Confusing the two axes is common; a team told to "be more aspirational" often just inflates an output number instead of making the underlying goal outcome-based.
Three questions separate an output key result from an outcome key result reliably:
- Would this key result still read as true if the shipped feature completely failed to change customer behavior?
- Does the key result describe an activity your team performed, or a state of the world that now exists?
- Could a customer, unprompted, describe the change this key result represents — or only an engineer reading a deploy log?
Outcome key results tend to read more naturally when they're anchored to a customer's actual job rather than a feature. A key result framed around progress on a core customer job — faster time to a specific outcome, fewer workarounds, less reliance on a spreadsheet — survives contact with reality better than one framed around a feature name, because the job doesn't disappear even if the specific feature turns out to be the wrong solution.
Teams that already track a North Star Metric — the single measure meant to proxy long-term value delivered, a concept popularized across the growth and product-led-growth community — often find their best outcome key results are just a segment or driver of that same metric, scoped to one quarter. If a proposed key result can't be connected to the North Star Metric even loosely, that's worth questioning before it ships.
The Tradeoff Test: What a Strategic OKR Should Make Obvious You're Not Doing
A strategic OKR passes the tradeoff test when a reader can infer, from the objective alone, at least one adjacent goal you're deliberately not pursuing this cycle. If every stakeholder could read your OKRs and assume the team is doing everything at once, the OKR hasn't encoded a choice — it's encoded ambition.
Ambition is easy to write and costs nothing politically — nobody objects to "delight customers" or "accelerate growth." A real tradeoff costs something: someone's pet feature doesn't make the cut, a segment goes unserved for two quarters, a channel gets deprioritized. If an OKR-setting session produces zero uncomfortable conversations, it produced zero tradeoffs.
Gallup's long-running engagement research has repeatedly found that only around half of employees strongly agree they know what's expected of them at work — a gap that an explicit, tradeoff-carrying objective is well positioned to close at the team level, since "what we're not doing" is often the missing half of that expectation.
Run each candidate objective through four questions before it ships to the scorecard:
- What are we explicitly choosing not to do because we're pursuing this instead?
- Which team, segment, or geography does this deliberately not serve this quarter?
- If a competitor made the opposite bet and both sides executed well, who's better positioned in 18 months?
- Could this exact objective be swapped into a rival's strategy and still make sense?
An objective that survives question four unscathed isn't strategic — it's generic.
Finding the real choice usually happens one layer up from OKR-writing, in the exercise of mapping which components of your value chain are commodity, which are genuinely differentiating, and which deserve investment versus outsourcing. Wardley Mapping is built for exactly this — it forces the build-versus-buy, invest-versus-commoditize decisions that a strategic OKR is supposed to compress into a single quarter's objective. Skip that mapping and OKR-writing has nothing real to trace back to.
This is close to how OKRs were originally used. Andy Grove's system at Intel was built to concentrate the whole company's attention on one strategic pivot at a time, not to track every workstream in parallel — a discipline that gets lost once OKRs are treated as a universal goal-tracking format rather than a tool for forcing focus on a specific bet.
The modern equivalent shows up in bets like PLG versus sales-led growth, or shipping AI-assisted features versus hardening core reliability. Either bet can be right. What makes the resulting OKR strategic is that the objective names the bet and, by implication, starves its alternative of investment for the cycle — not that the bet itself is objectively correct.
Rewriting a Roadmap OKR Into One That Carries Real Strategic Weight
Take an objective like "Improve onboarding" with a key result to "ship the new onboarding flow by Q3" — a roadmap item wearing an OKR costume. Rewritten around a real strategic tradeoff, the objective names which customer segment the company is betting on, and the key result measures a behavior change that only matters if that bet is correct.
The rewrite only works if a strategic choice already exists to draw from — say, leadership decided to win self-serve SMB customers away from spreadsheets rather than compete for enterprise deals this year. Here's what changes once that choice is made explicit inside the OKR itself:
| Element | Roadmap-in-Disguise Version | Strategic Rewrite |
|---|---|---|
| Objective | Improve onboarding | Win self-serve SMB customers away from spreadsheets, not enterprise buyers |
| Key result 1 | Ship new onboarding flow by end of Q3 | Cut time-to-first-value for SMB signups from 9 days to under 2 |
| Key result 2 | Reduce onboarding support tickets by 15% | Grow week-4 retention for the SMB self-serve cohort from 22% to 35% |
| Implicit tradeoff | None — could apply to any company | Enterprise onboarding, sales-assisted flows, and mid-market customization are explicitly not this quarter's bet |
| Would it survive a strategy change? | Yes | No — only makes sense if the company chose self-serve SMB over enterprise |
Notice what the rewrite cost: enterprise onboarding, sales-assisted flows, and mid-market customization all got implicitly deprioritized. That's not a side effect of good OKR writing — it's the point.
The strategic version also narrows to a specific point in the customer journey — activation, in this case — rather than a vague appeal to "better onboarding" that could mean anything from copy changes to a pricing page redesign. It only works because a strategic choice existed to draw the boundary in the first place; a team whose vision statement never named a segment has nothing concrete to rewrite the objective around, so it drifts back to the roadmap version by default.
Tracing OKRs Back to Strategy (and Catching the Ones That Don't Belong)
Every OKR should be traceable to one strategic artifact — a vision statement, a strategy deck decision, a named bet — that explains why this objective exists and not a different one. When an OKR can't be traced to anything, it's usually inherited from last quarter's plan, a stakeholder's pet request, or a team defending its own headcount.
Tracing sounds like paperwork until you try to do it under scrutiny. Pull up any live OKR set and ask, for each objective, "which specific strategic decision is this advancing, and where is that decision written down?" A surprising number of objectives fail this test — not because the work is bad, but because nobody can point to the choice it's supposed to serve.
Auditing an Existing OKR Set
A fast audit doesn't require new tooling, just discipline:
- List every current objective in one column.
- Next to each, write the specific strategic artifact it traces to — by name, not by vibe.
- Flag any objective where that cell stays blank for more than a minute of thinking.
- For flagged objectives, decide whether the objective should be cut, or whether the strategy itself has a gap it's exposing.
Objectives that survive this audit tend to be the ones worth defending in a planning review; the ones that don't are usually the first to quietly slip when a team gets busy.
A few patterns show up often enough to be worth naming on their own:
- The zombie objective — worded almost identically to last quarter's, minus the key results, because nobody revisited whether the underlying bet still holds
- The defensive objective — exists mainly to justify a team's headcount or continued existence, not to advance a stated strategy
- The borrowed objective — copied from a peer company's public OKR post because it sounded credible, with no check on whether it fits this company's actual bet
An OKR that can't point to a named strategic artifact is a placeholder wearing a goal's clothing.
This is as much a librarianship problem as a strategy problem. When a vision doc, a strategy deck, JTBD research, and last quarter's prioritization calls all live in six disconnected tools, nobody actually checks whether an OKR maps to a real decision — they just assume it does, and the assumption goes unquestioned for years.
Key Takeaways
- Output OKRs measure shipping; outcome OKRs measure a behavior change — only the second kind can carry a strategic hypothesis.
- A strategic OKR should make at least one deliberate non-goal legible. If a reader can't infer what you're not doing, the objective encodes ambition, not strategy.
- Portability is the tell. An objective that would fit unchanged into a rival's strategy was never encoding your own.
- Trace every OKR to a named strategic artifact — a vision line, a strategy deck decision, a specific bet — before it goes on a scorecard.
- Committed vs. aspirational (Doerr) and output vs. outcome (Cagan) are two separate axes. Don't try to solve one by adjusting the other.
- Rewriting a roadmap OKR into a strategic one usually requires the strategic choice to already exist. OKR-writing can't invent a tradeoff a strategy session skipped.
- Keeping strategy artifacts referenceable, not buried in a slide deck, is what makes tracing possible at scale rather than a one-time audit exercise.
Frequently Asked Questions
How many OKRs should a product team set per quarter?
Most OKR practitioners, including Doerr's own guidance in Measure What Matters, recommend no more than three to five objectives with two to four key results each — fewer if the objectives are genuinely strategic. A long OKR list is itself a signal that tradeoffs aren't being made; teams with real strategic constraints naturally converge on fewer, sharper bets.
What's the difference between an OKR and a KPI?
A KPI is an ongoing health metric you monitor indefinitely — churn rate, uptime, NPS — while an OKR is a time-boxed goal meant to move a specific metric during one cycle. KPIs tell you when something needs attention; OKRs are how you decide what to do about it this quarter, and a healthy KPI can sit outside every current OKR without being ignored.
Should every OKR carry an explicit strategic tradeoff, or is that too rigid for a fast-moving team?
Not every key result needs its own tradeoff, but every objective should. It's reasonable for supporting key results underneath a strategic objective to include operational or output-style measures, as long as the objective itself names the choice. Forcing tradeoff language onto every line just produces jargon — the discipline belongs at the objective level.
How often should OKRs change if the underlying strategy hasn't changed?
If strategy is genuinely stable, objectives should feel repetitive across a few cycles — that's evidence the team is compounding progress on the same bet rather than restarting each quarter. Key results should change quarter to quarter since they mark progress toward that same objective; an entirely new set of objectives every quarter often signals strategy is being rewritten too often, or wasn't real to begin with.
Can output-based key results ever be legitimate?
Yes, when the output is genuinely load-bearing for a larger outcome hypothesis and clearly time-boxed — for example, an output key result that gates a later outcome key result because a capability has to exist before behavior can change. The problem isn't outputs appearing in an OKR set at all; it's an entire objective built from nothing but outputs, with no outcome hypothesis anywhere above it.