In this essay
A knowledge-search team proposes an objective: make it easier for staff to find current procedures. The key results are to ship a filter, migrate the document index and run three training sessions.
Those commitments may be useful. None establishes whether people can now find the right procedure.
The team needs an outcome measure before it can choose a defensible target. This article works through a fictional search product, with illustrative numbers, to show how a baseline, a defined population and a quality check make an OKR review more informative.

Describe the change someone should experience
A useful objective for the example is that staff can locate an applicable, current procedure during their work. “Applicable” matters: a result for another jurisdiction or customer type may be easy to find and still be the wrong answer. “Current” matters because an obsolete procedure can create work for everyone downstream.
Google's re:Work guide, preserved from 2016, distinguishes outcome-oriented key results from activity lists and calls for credible, discoverable evidence of completion. Its historical scoring conventions are not universal rules for another organization. Use the outcome and evidence distinction without borrowing a standard percentage for success. Google re:Work OKR guidance
The feature work remains in the delivery plan. A filter might help users narrow results; an index migration might remove outdated records. Each is a hypothesis about improving the outcome. The OKR review should test that connection rather than treating feature release as proof of benefit.
Establish a baseline that can be repeated
For the proposed study, recruit staff from the roles that use the procedures and give them a defined set of representative retrieval tasks. Preserve the task wording, expected applicable document and version, participant eligibility and completion rule. Use appropriate consent and access controls for any observation.
Suppose 18 of 30 eligible baseline tasks end with the correct current procedure being found without help. The observed success rate is 60%. That is a small illustrative sample, not a company benchmark or a statistically established population estimate.
A target might propose 24 successful tasks out of the same 30-task design, equivalent to 80%. The target expresses an intended improvement; it does not prove that the planned feature can deliver it. The team should discuss why the change is plausible, what evidence supports the assumption and whether the sample is adequate for the decision being made.
If later testing uses different tasks or a different mix of staff, report that change. A higher percentage among experienced employees is not directly comparable with a baseline drawn mainly from new joiners. Reusing exactly the same participants and tasks can introduce learning effects, so a repeatable design must also consider familiarity rather than mistake memorization for product improvement.
Write the measurement agreement before the target
| Field | Example for the search product | Why it matters |
|---|---|---|
| Intended outcome | Find the applicable current procedure | Defines useful success |
| Eligible population | Staff performing the selected work in the covered service | Prevents an unexplained change in who counts |
| Unit | One preselected retrieval task | Prevents splitting easy work into extra successes |
| Numerator | Tasks meeting the correct-document and version rule | Prevents counting any click as success |
| Denominator | All eligible observed tasks, including unsuccessful ones | Keeps abandonment visible |
| Baseline | 18 of 30 tasks in the illustrative first study | Gives the proposed target a starting point |
| Target | 24 of 30 under the agreed follow-up design | States the ambition without claiming achievement |
| Guardrail | No unauthorized document exposure in the assessed paths | Keeps a harmful shortcut visible |
| Review evidence | Dated observations, task results and known limitations | Allows someone else to assess the claim |
GOV.UK's guidance on performance metrics emphasizes defining what success means and using measures to test hypotheses. Its public-service context differs from this fictional internal product, but it supports the practice of agreeing the measure before interpreting the result. Setting performance metrics
Decide what would make the result misleading
The search team could hit 80% by excluding the hardest tasks, broadening permissions or labeling several obsolete documents as acceptable. A useful review anticipates those shortcuts.
Keep the acceptance rule for each task independent of the product's ranking output. If the search engine chooses the answer and the evaluator accepts whatever ranks first, the test is circular. A knowledgeable reviewer should establish the expected current procedure and any valid alternatives before assessing the results.
Some outcomes need more than one observation. Finding the right document in a study does not establish that staff can apply it under real workload. The team might follow with a smaller contextual study or examine support questions. Describe that as additional evidence, not as a reason to silently change what the original metric claimed.
The related metric integrity article examines these shortcuts in more detail. The OKR adds a time-bound intent and a review decision to that measurement design.
State the correct task result, eligible participants and quality boundary.
Check task selection, denominator, document versions and learning or cohort effects.
Repair the study design or disclose the gap. Do not invent a starting value to grade the goal.
Reassess the corrected baseline designKeep feature delivery separate from measured outcome evidence.
Record achieved, missed or inconclusive outcomes honestly; preserve definition changes and unresolved harms.
Set the baseline before grading the outcome. A shipped feature, a target percentage and a measured result are three different records.
Review progress without confusing delivery and outcome
Midway through the period, the filter may be released while the follow-up study has not happened. Report the feature as delivered and the outcome as unmeasured. That is a useful status because it tells the team what evidence remains to be collected.
If the study later observes 22 successful tasks out of 30, the measured rate is approximately 73.3%. It is an improvement over the illustrative 60% baseline under the stated design, but it falls short of the proposed 80% target. The review should also disclose cohort changes, learning effects and measurement uncertainty. A before-and-after comparison alone does not isolate the feature's causal effect.
Avoid turning a missed target into a failure narrative before inspecting the cases. The remaining tasks may share a document-ownership problem that a filter cannot fix. Conversely, a met target may reveal a permission problem that needs immediate attention. The evidence should shape the next decision, not merely provide a grade.
Keep the target connected to a decision
Before the period begins, agree how different results will influence the next step. A useful outcome with acceptable guardrails might support broader rollout. Inconclusive evidence may justify another study. A harmful permission result requires correction even if retrieval success is high.
Give the evidence an owner and a review date. Preserve the task results and definitions so a later team can distinguish an achieved outcome from an attractive slide. When the definition changes, begin a clearly identified series or explain the bridge between versions.
The finished OKR should leave the team able to explain what improved for users, how it was measured and what they will do next. The filter, migration and training sessions remain part of the work. Their value becomes clearer when the outcome can be assessed separately.
Closing thought and further reading
Shipping a search filter proves delivery. An outcome goal asks whether people can find the right current document, with evidence the team can inspect.
Need help applying this to your business?
Explore practical support for payment operations, product decisions, program delivery and AI automation, grounded in the challenges behind this essay.


