okr-design

# OKR Design

A senior product leader's playbook for OKR design as actually shipped, not as conference-talk theory. Outcome statements that drive decisions, key results that measure the right thing, scoring discipline, mid-quarter recalibration, and the practical disciplines that distinguish OKRs from quarterly to-do lists or impossible-fantasy goal-setting.

OKRs are accountability infrastructure. When designed well, they produce a quarterly rhythm of ambitious goal-setting, mid-quarter learning, end-of-quarter scoring, and adjustment for the next quarter. When designed badly, they become a tax on the team that produces no signal: sandbagged OKRs that always hit 100% (no ambition, no learning), aspirational fantasy OKRs that nobody can hit (demoralizing, ignored after week 2), or vague OKRs that the team scores generously regardless of outcome.

This skill is OKR design as practical methodology. The teams that benefit from OKRs are the ones that hold the discipline: outcomes over outputs, key results that actually measure the outcome, scoring honestly even when uncomfortable, recalibrating mid-quarter when warranted, and using the OKR review cadence to drive learning rather than performance theater.

The voice is the senior product leader who has run OKRs in healthy organizations and watched the practice decay in others. Concrete, opinionated about what actually works, willing to call out the failure modes that conference talks gloss over.

When to use this skill: designing OKRs for the next quarter, auditing why current OKRs are not driving decisions, recalibrating an OKR practice that has decayed, or onboarding a team to OKRs that has never used them.

---

## What this skill is for

This skill spans OKR design and the operational rhythm around them. The PM-skill distinction:

- **`okr-design` (this skill)** is outcomes (results to be achieved).
- `roadmap-planning` is outputs (features and initiatives sequenced).
- `feature-launch-playbook` is post-ship execution.
- `product-analytics-setup` is measurement infrastructure (the metrics that key results depend on).
- `experiment-design` is the discipline for testing whether specific initiatives produce outcomes.
- `discovery-research-synthesis` informs which outcomes to pursue.

The audience: senior PMs, product directors, engineering leaders, executives setting org-wide OKRs, in-house teams operating in OKR-driven cultures.

What is not in scope: the broader strategic planning that decides which outcomes matter (other strategy frameworks); the execution of specific initiatives toward OKRs (covered by roadmap-planning, pm-spec-writing, feature-launch-playbook); the analytics infrastructure (covered by product-analytics-setup, analytics-strategy).

---

## Sandbagged vs aspirational-fantasy vs stretch

The keystone framing.

**Sandbagged.** OKRs designed to hit 100%. The key results target outcomes the team is already on track to deliver. End of quarter: 100% scores across the board. The team celebrates; nobody learns anything. Output: an OKR practice that produces no signal. The team has the same OKRs every quarter dressed in different vocabulary because nothing pushes them past where they would have gone anyway.

**Aspirational-fantasy.** OKRs that nobody can hit. 1000% growth in 90 days. Demoralizing, performative, ignored after week 2. Teams that ship aspirational-fantasy OKRs typically discover by week 6 that no realistic effort path produces the targets; they disengage; the OKRs become decoration on the planning doc that nobody references.

**Stretch.** Genuine ambition with quarterly accountability. Designed to hit 60-70% on average. Hits and misses both teach something. The 60% case ("we hit 60% of our key results") is informative about what the team can deliver in a quarter; the 100% case is rare and usually signals sandbagging in retrospect; the 30% case signals either fantasy or the team encountered something unexpected (which is also informative).

The litmus test. Look at the team's last four quarters of OKRs. If the average score is 95%+, the OKRs are sandbagged. If the average is below 30%, they are fantasy. If the average is 50-75%, the design is in the stretch zone. Adjust upcoming OKRs to bring the practice into stretch territory.

---

## Objective design

Objectives are outcome statements. They name what the team is trying to achieve in the quarter.

**Strong objective characteristics.**

- Outcome-focused, not output-focused. "Improve activation for new sign-ups" is an outcome; "Ship the new onboarding flow" is an output.
- Specific to the quarter. Vague aspirations ("be more user-focused") do not focus quarterly work.
- Inspiring without being fantasy. The team should feel pulled toward the objective, not crushed by it.
- Few in number. Most teams should have 2-4 objectives per quarter; more than 5 dilutes focus.

**Worked examples.**

- "Improve activation for new sign-ups so that more reach the value-realization moment within the first week."
- "Make the support experience deflect predictable issues so the team can focus on harder cases."
- "Establish enterprise-readiness foundations so we can serve the segment we are targeting next year."

**Weak objective characteristics.**

- Output-disguised-as-outcome. "Ship the activation redesign" is an output; the objective should be the result the redesign is meant to produce.
- Too vague. "Improve user experience" is too broad to focus quarterly work.
- Too tactical. "Refactor the auth service" is a tactical decision, not a quarterly objective.
- Too many. 8 objectives produces no focus; the team works on too many things and excels at none.

Detail in [`references/objective-design-patterns.md`](references/objective-design-patterns.md).

---

## Key result design

Key results measure progress toward the objective. They are the quantitative or testable indicators that show whether the objective is being achieved.

**Strong key result characteristics.**

- Measurable. Ther