Most OKR failures get diagnosed as format problems. The objectives aren't specific enough. The key results are outputs rather than outcomes. The team wrote five KRs when they should have written three. These are real issues, but they're downstream of the actual problem. The actual problem is that nobody knows the current number.
The Format Is Fine
The OKR format has been reliably described, debated, and refined for decades. At this point the format is not the failure point. Teams that fail with OKRs almost always fail for the same reason: they set targets without baselines. They decide where they want to go without knowing where they are.
"Improve onboarding completion" is not a key result. Neither is "increase retention" or "reduce churn" or "grow engagement." These are directions, not destinations. A direction is not a commitment. You can always claim you moved in a direction. A destination requires you to know where you started.
The failure mode is predictable: a team sets an objective around retention, writes key results that sound like outcomes, and at the end of the quarter discovers that nobody measured retention before the work started. They can see the current number. They cannot see the delta. They cannot say whether the work moved anything. They write a retrospective that calls the results "inconclusive" and move on to the next quarter's planning cycle. Repeat.
Who Does What by How Much?
The question that a well-formed key result must answer is: who does what by how much? That's the whole test. If you cannot fill in all three blanks with specific, observable answers, the key result isn't ready.
Who — which user segment, customer cohort, or behavioral group is the actor in this key result? "Users" is not a who. "First-time subscribers who completed onboarding in the last 30 days" is a who. The specificity of the who determines whether you can measure the result cleanly or whether you'll end up averaging across populations that behave very differently.
Does what — which specific, measurable behavior changes? Not "feels better about onboarding" or "has a good experience." The behavior must be observable and countable. Renews. Completes. Returns. Invites. Purchases. The verb should be something you can count in your event log.
By how much — this is where the baseline lives. Not "increases" or "improves" — a number. And behind that number is another number: the current one. "Active subscribers renew at 78%" requires knowing that the current renewal rate is 71%, or 65%, or 82%. Without the current number, 78% is a wish, not a target.
The Baseline Is Where OKRs Actually Break
Most product teams don't have their baselines readily available. This is not a failure of discipline — it's a symptom of how most product organizations are instrumented. Analytics gets wired up after features ship. Dashboards measure what was easy to measure, not what was important to measure. Key business metrics live in a data warehouse that requires a data analyst request and a two-day turnaround. The PM who needs a baseline for next quarter's planning session doesn't have a clear path to get it by Thursday.
So the team writes the OKR anyway, with a target but no baseline, intending to pull the baseline "before the quarter starts." Sometimes they do. More often, the quarter starts, the work begins, and the baseline never gets established. By the time the work is done, the window for meaningful before/after comparison has closed. The team reports a current number, which tells them where they are — not how far they traveled.
This is the baseline problem. It is not about laziness or bad intentions. It is about a structural gap between when planning happens and when measurement infrastructure gets built. The gap is small but the consequence is large: a quarter of product work that cannot be evaluated on its own terms.
The Bypass Is Not the Failure
Here is the contrarian position: not every piece of product work needs an OKR. Some work is clearly necessary and not meaningfully measurable in the relevant timeframe. Some work is so small that the cost of defining and tracking a key result exceeds the value of the insight. Some work is maintenance, compliance, or debt reduction — categories where the right success metric is "this problem no longer exists," which doesn't fit the format well.
The failure is not skipping the OKR. The failure is skipping the OKR silently, without noting that you did, without stating a reason, and without creating any accountability for what it would take to eventually make the work measurable. A silent bypass looks identical to a measured decision. Over time, silent bypasses accumulate into a planning culture where OKRs are optional in practice even if they're mandatory in policy.
The ProductHarness approach is to make the OKR field required-but-bypassable in the PM spec. The bypass is not a failure state — it is a legitimate choice that must be explicitly declared with a stated reason. "We don't have instrumentation in place for this cohort yet" is a valid reason. "This is a compliance requirement with no user behavior outcome" is a valid reason. "We're not sure what the right metric is" is a valid reason that should trigger a follow-up. What's not valid is leaving the field blank and moving on.
When bypasses are explicit and logged, they become visible. A team can look at its sprint history and see what fraction of work shipped with a completed OKR versus a documented bypass. That ratio, tracked over time, is a more honest indicator of measurement culture than any OKR score or achievement rate.
The Instrumentation Problem Is Earlier Than You Think
Getting serious about OKRs eventually surfaces a harder problem: the measurement infrastructure doesn't exist when the planning happens. The team wants to set a key result around activation rates, but activation isn't being measured at the right granularity. They want to track a cohort behavior, but the event schema doesn't support cohort analysis. They want to know the current number, but the current number requires a data pull that doesn't exist as a standing query.
This is an instrumentation problem masquerading as an OKR problem. The OKR process exposed it, but the fix is upstream: at requirements time, not planning time. A PM who defines what they intend to measure in the spec — before the feature is built, while the implementation is still flexible — creates the conditions for a baseline to exist when the next planning cycle starts. The instrumentation gets wired in with the feature, not retrofitted afterward. The event fires, the data accumulates, and by the time the team wants to set a target, there's a number to target from.
This is why ProductHarness includes a required analytics field in the PM spec alongside the OKR field. The question "how will this be measured?" belongs at requirements time, not retrospective time. A feature that ships without instrumentation cannot be the basis of a future OKR. A feature that ships with instrumentation, even a simple one, gives the team a baseline they didn't have before.
The Right Pressure in the Right Place
The failure mode of most OKR implementations is pressure at the wrong point. Teams feel pressure at the end of the quarter to report results they can't cleanly substantiate. They feel pressure at the start of the quarter to set targets that sound ambitious. They feel very little pressure, in the middle of sprint planning, to answer the question: and how exactly will we know if this worked?
The baseline problem is solved by moving that pressure earlier. Not by adding process overhead — the spec field is one line — but by making "we don't have a baseline for this" a visible, auditable statement rather than a silent assumption. When the absence of a baseline is logged as a bypass reason rather than omitted entirely, the team can see it. Stakeholders can see it. Leadership can see it. The structural gap between planning and measurement becomes a named, trackable condition rather than an invisible one.
Most OKRs don't fail because the team didn't try. They fail because the measurement infrastructure wasn't in place to make success legible. That's a solvable problem — but only if it gets named at the right moment in the process, not discovered at the wrong end of the quarter.