How to Run OKR Confidence Check-Ins

TL;DR. Run an OKR confidence check-in by reviewing each key result's latest progress, asking whether the current plan can still reach the target, and choosing a specific next action. Support confidence with evidence, name blockers clearly, and assign an owner and review point to each decision. Treat confidence as a forecast about the plan, never as a performance grade for the person reporting it.

What should an OKR confidence check-in decide?

Use the check-in to answer one practical question: What needs to change before the next review?

An update such as “the campaign launched” describes completed work. It does not explain whether that work is moving the key result, whether the target remains reachable, or what help is needed.

For each key result, leave with one decision:

• Continue the current plan.
• Change an action or test an assumption.
• Resolve or escalate a blocker.
• Propose a revision to the key result because its underlying assumptions changed.

“Continue” is a valid decision when the evidence supports it. Record what would make you reconsider.

Start with a measurable outcome and a clear owner. If those are missing, use OKRs for SaaS Teams to structure the objective and key results before adding a confidence review.

How should you separate progress from confidence?

Progress describes the measured result so far. Confidence describes your judgment about reaching the target within the agreed period.

Report both. A key result can show movement while its remaining path becomes harder. Another can show little movement while an important dependency has just been resolved.

Use a simple scale with shared definitions:

Confidence	Working definition	Question to ask
High	Current evidence supports reaching the target with the agreed plan and resources.	Which assumption could change that view?
Medium	Reaching the target is plausible, but an important uncertainty remains.	What would resolve the uncertainty?
Low	Current evidence does not support reaching the target with the present plan.	What decision or change is needed?

These are suggested definitions, not universal scoring rules. Agree them before asking people to report confidence.

Ask the owner to complete this sentence:

“My confidence is ___ because ___; the next evidence I need is ___.”

Do not turn the labels into probabilities unless your team has a defined method for estimating them. “High” should mean something people can explain, not a number that merely looks precise.

What should owners prepare before the check-in?

Ask each owner to update a short record:

• Key result: the outcome, baseline, target and agreed period.
• Progress: the latest value, measurement source and when it was checked.
• Confidence: the rating and the evidence behind it.
• Blocker or uncertainty: what prevents progress or makes the forecast unclear.
• Proposed next action: what should happen, who should do it and when it should be reviewed.

Keep activity updates brief. Include them when they explain a result, test an assumption or establish a dependency.

If the measurement is missing or unreliable, say so. Record confidence as “unknown” and decide how to obtain usable evidence. Do not substitute completed tasks for an unavailable outcome measure.

For help distinguishing an outcome from an ongoing health measure, see OKRs vs KPIs.

How do you run the conversation?

Choose a recurring cadence that leaves time to act on decisions. Weekly is one starting option; adjust it to how quickly the work and its evidence can change.

Work through each key result in this order:

1. Check the evidence. What is the latest result? Is it measured on the same basis as the baseline?
2. Compare with the previous review. What changed in progress, confidence or assumptions?
3. Examine the path ahead. Does the remaining plan still support the target?
4. Identify the constraint. Is the issue execution, a dependency, missing evidence or an ineffective approach?
5. Choose the next action. Name an owner, review point and expected evidence.

Discuss exceptions first: falling confidence, stalled progress, new dependencies and decisions needing help.

When a detailed problem needs a separate working session, arrange it and return to the review. The check-in should still record who will resolve the issue and when the team will hear the outcome.

Close by reading back decisions. Avoid endings such as “keep pushing” or “monitor closely” unless they specify what happens next.

How do you surface blockers without creating a blame session?

Ask about the conditions preventing the outcome.

Replace “Why are you behind?” with “What is preventing the next step, and who can help change it?”

Distinguish a blocker from an uncertainty:

• Blocker: the team cannot proceed with a necessary action.
• Uncertainty: the team can act, but does not yet know whether an assumption is sound.

A blocked data export may need a decision from another owner. Uncertainty about whether onboarding guidance helps customers may need a test.

Write each request concretely: “The onboarding owner needs access to the account-level activation report before deciding which step to change.”

If help requires a trade-off, name it. “Needs more capacity” is incomplete. Specify the work, the capacity required and what would be delayed to provide it. Give any escalation an owner and a point for checking whether it worked.

What does a useful check-in look like?

Illustrative example: a product team has a key result to increase weekly active customer teams from 20 to 40 within its agreed OKR period.

Check-in field	Owner's update
Progress	The latest count is 30, up from 28 at the previous review.
Confidence	Low.
Evidence	Assisted onboarding has brought teams into use, but the remaining plan relies on self-serve onboarding that has not been tested.
Uncertainty	The team does not know whether the revised setup guide enables customers to finish without help.
Next action	The product manager will observe setup with consenting customer teams and record where assistance is needed.
Review point	At the next check-in, decide whether to revise setup or continue testing the guide.

The count increased, but that alone does not justify higher confidence. The proposed action tests the assumption behind the remaining plan.

Compare this with “onboarding work is progressing.” The useful version exposes the decision and the evidence needed to make it.

When should you change the plan or revise the key result?

Change the plan when the outcome still matters but the current approach lacks support. Stop an ineffective activity, change the sequence of work, test another approach or resolve a dependency.

Consider revising the key result when its basis has materially changed: the customer segment changed, the measurement proved invalid, or a deliberate business decision removed the resources assumed in the plan.

Record:

• The original key result.
• The assumption that changed and the evidence.
• The proposed revision and who agreed it.
• The effect on dependent work.

Do not quietly lower a target to make the review look healthier. Keep the original visible so the change remains understandable.

When a plan change affects priorities, Now, Next, Later Roadmaps offers a structure for discussing what moves.

What common mistakes should you avoid?

• Grading people through confidence. Define the rating as a forecast about the result. Discuss individual performance separately.
• Demanding optimism. Ask what supports a rating, including a high one. Accept low confidence as a reason to examine the plan.
• Treating activity as progress. A launch or completed task belongs in the explanation; measure the key result itself.
• Averaging away a dependency. Review any low-confidence result that could prevent the objective from being achieved.
• Assigning actions without capacity. Agree what the owner can deliver and what must move.
• Reopening settled decisions without evidence. State what changed before revisiting the plan.

If an issue needs immediate action, act immediately. Do not wait for the next scheduled check-in.

Related reading

• OKRs for SaaS Teams — structure objectives and measurable key results.
• OKRs vs KPIs — distinguish change goals from ongoing health measures.
• OKR Examples for B2B Marketing — explore outcome-focused marketing goals.
• Now, Next, Later Roadmaps — make priority changes explicit.