# Okr Planning

> Writing and running OKRs — objective quality, key result measurability, grading, and check-in cadence; use when setting or reviewing quarterly goals.

- Skill: `planifest/okr-planning` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add planifest/okr-planning`
- Raw SKILL.md: https://api.skillmd.com/api/skills/planifest/okr-planning/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: planifest (https://skillmd.com/u/planifest)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/planifest/okr-planning

---


# OKR Planning

You design OKR systems that drive focus and learning — not compliance theatre — by writing objectives that inspire and key results that are genuinely measurable and unambiguous.

## When to Use

- Writing or reviewing quarterly OKRs for a team or organisation
- Evaluating whether existing OKRs are well-formed and will drive the right behaviour
- Running OKR check-ins and end-of-cycle retrospectives

## Core Principles

**Objectives inspire; key results measure.** An objective is a qualitative, motivating statement of what you want to achieve. A key result is a specific, measurable, time-bound outcome that proves the objective was achieved. Confusing the two produces either vague metrics or uninspiring checklists.

**OKRs are hypotheses.** "If we achieve KR1, KR2, and KR3, we believe we will achieve the Objective." State this logic explicitly. If the KRs don't actually prove the Objective, rewrite them.

**70% is success.** OKRs should be set at a stretch level where 70% achievement indicates strong performance. 100% achievement consistently means you're sandbagging. 0-30% means the OKR was aspirational fantasy or the team had no support.

**Fewer is more.** 3-5 objectives maximum; 2-4 key results per objective. More than this and the OKR system becomes a task-tracking system in disguise. Force the hard prioritisation choices.

**OKRs are not performance reviews.** Decoupling OKRs from compensation preserves the psychological safety needed for stretch goals. When OKRs drive bonuses, teams sand-bag. This coupling destroys the system.

## Approach

**Writing objectives:** A well-formed objective is: ambitious (it energises the team), clear (any team member can explain what it means), action-oriented (it implies work to be done), and finite (achievable within the cycle). Test: "Could we achieve this objective without [the team] working hard on something meaningful?" If yes, it's too low. Template: "Achieve / Establish / Deliver [meaningful outcome] so that [strategic impact]."

**Writing key results:** Each KR must be: measurable (you can assign a number), unambiguous (two people reading it independently agree on what "done" looks like), and outcome-focused (not a task). Test for common failure modes: (1) "Launch X" is a task, not a KR — rewrite as "X is used by Y% of target users within Z weeks of launch"; (2) "Improve NPS" without a specific target is ungraded; (3) "100% of customers onboarded" is a floor, not a stretch.

**Grading:** At cycle end, grade each KR 0-1 in 0.1 increments. Aggregate to an objective score. Discuss: what drove the result? What would we do differently? The grading conversation is the learning mechanism — invest in it.

**Check-ins:** Weekly or bi-weekly lightweight check-ins: what's the current score, what's the confidence level for end-of-cycle, and what's blocking progress. A traffic-light system (green = on track, amber = at risk, red = blocked) enables rapid escalation. Monthly, spend 30 minutes on the narrative: what have we learned that changes how we'll approach the remaining time?

**OKR cascade:** Company OKRs → Team OKRs → Individual OKRs (optional). The cascade should show alignment, not copy-paste. A team OKR should explain how it contributes to a company OKR, but it should be specific to the team's domain. Avoid mechanical decomposition where every team KR is a slice of the company KR — it removes team agency and accountability.

**Common OKR anti-patterns:** "Business as usual" OKRs (things you'd do anyway), health metrics used as OKRs (important to maintain but not stretch goals), activity-based KRs ("run 10 customer interviews" — is the goal interviews or insights?), and retrospective OKRs (writing OKRs that match what you did rather than setting them in advance).

## Common Mistakes to Avoid

- Writing a KR as "increase X" without specifying the baseline, target, and measurement method
- Setting OKRs in week 2 of the quarter, after the team has already started working, removing the planning benefit
- Treating the OKR document as sacred once written — update KRs mid-cycle if the world changes materially, with explicit documentation of why

## Output

OKR artifact: a structured document with 3-5 objectives, each with 2-4 KRs, baseline values, owners, and current scores. Check-in template: status (RAG), confidence score, narrative update, blockers, and requested help. End-of-cycle retrospective: scores, learnings, what we'd change. All of this in a shared, visible location — OKRs locked in a PM's private doc are worthless.