Skip to content
Product Lifecycle Templates

OKRs

beta  ·  Family strategy-docs  ·  Phase undefined  ·  Sizes lean, full  ·  ~2,400 tokens

The document that states what measurable change a team expects in this period and whether it got it. One qualitative Objective plus a small set of Key Results that are outcomes rather than activities. It is judged by a single test: could you finish every piece of work on the list and still have failed?

An operator card. Read it before you fill the template and again before you agree the set. The reasoning behind every rule here lives in okrs_companion.md.

Before you start: is this the right document at all?

Section titled “Before you start: is this the right document at all?”

An OKR set answers what measurable change do we expect this period, and did we get it. If your actual question is something else, write something else.

If the real question is Write this instead
Where are we trying to get to, over years? product-vision
Which problems will we solve, and which will we not? product-strategy
In what order will we work on them? product-roadmap
What is the standing health of the system, watched continuously? kpi-dashboard. A KPI is a steady-state metric; a Key Result is a metric you are deliberately trying to move. A KPI can become a Key Result for one cycle and then revert
Who does what by when? A project plan. OKRs are the compass, the plan is the turn-by-turn
What are we building, in detail? prd

Write nothing at all if the team has no autonomy to change the number, or if the answer to “what would we do differently if this went red” is “nothing.” A goal nobody can act on is a report.

The one test that outranks the rest

Section titled “The one test that outranks the rest”

Could you complete every piece of work on this list and still have failed?

If the answer is no, you have written a task list with a scoring rubric attached. The fastest check is Google’s own word list: a Key Result containing consult, help, analyze, or participate is describing an activity. Rewrite it as the change you would see in the world.

The second test is about honesty rather than form: is there a number in here that nobody has actually read this month? A baseline nobody can source is a target nobody can miss.

Picking a variant

Section titled “Picking a variant”

lean is the Objective, the Key Results, the parent it serves, and what you are deliberately not doing. That is the whole artifact, and it is enough for a team that shares context and reviews it together.

full adds Initiatives, Confidence and check-in, and Scoring and close-out. Reach for it when the set will be read by people who were not in the room, when more than one team’s work feeds the same measure, or when this is the first cycle and the operating rules genuinely need writing down.

One format ships, and that is a finding rather than an omission. Six candidates were examined individually and five rejected, including V2MOM, which is genuinely structurally distinct but which Salesforce does not present as an OKR variant; nine further named goal-setting frameworks were checked for a counterexample and none qualified. If someone brings you an “OKR canvas,” it is a layout, not a different document.

The rubric

Section titled “The rubric”

Score each 0, 1 or 2. Under 12 out of 18 and this set will be scored on whether the work happened rather than on whether anything changed, which is the exact failure OKRs exist to prevent.

# Criterion 0 1 2
1 Serves a named parent No parent named Names a document, but you cannot say which part of it this advances Names the parent, and you can point at the specific policy or goal this Objective moves
2 Objective is qualitative Contains a number Qualitative, but names the mechanism, so it forecloses other routes Someone could achieve it by a route you had not considered and you would be pleased
3 Key Results are outcomes They describe work Mixed, or a milestone Key Result with no stated reason for the exception You could finish every initiative and still score badly, and the team knows that
4 Baselines are readable No baseline A baseline is stated but nobody has read it this month Someone can name where each number comes from and when it last updated
5 Each measure is owned Team names or blanks A person per Objective, but not per Key Result A named person per Key Result, and each of them knows it
6 Exclusions with a cost Nothing excluded Excludes things nobody asked for You can point at the sentence, name who asked, and say who told them no
7 Work serves a measure (full) No initiatives, or initiatives that serve “all of them” Each initiative names a Key Result, but some Key Results have no work behind them Every initiative serves exactly one Key Result, and any Key Result with no work is deliberate and says so
8 Confidence moves (full) No confidence recorded Recorded once and unchanged since At least one has moved, and someone can say what moved it
9 Pay question answered (full) Silent on it Mentioned, but not in a form anyone could quote back States in writing whether scores touch reviews or pay, and the team has been told

Which rows apply to what. Every threshold is two thirds of the available points, rounded down.

Document Rows Maximum Score against
full all 9 18 12
lean 1-6 12 8

Rows 7 to 9 are scored only against full. The lean variant ships no Initiatives, Confidence or Scoring section, so grading it on them would penalise the choice of size rather than the quality of the document.

Failure signals to look for in the draft

Section titled “Failure signals to look for in the draft”

Key Results that are tasks in disguise. The one the word test catches in seconds. A vendor’s analysis of its own platform put it at roughly half of all Key Results, which is that vendor’s own data rather than a measurement of the world. Nothing ranks the signals in this list against each other, so read it as a list rather than an order.

Sandbagging. A target the team already knows it will hit. Treat it as a predictable response to the incentive rather than a description of the people: the named practitioners who write about it all tie it to scores touching something that matters to someone’s career. If you find it, look at your Scoring section before you look at the team.

Watermelon reporting. Green on the outside, red inside. It is the same mechanism as sandbagging arriving one step later, and the tell is a confidence column that has not moved since week one.

OKR theatre. A complete cycle of writing, scoring and reviewing that changed nobody’s priorities. The diagnostic question: name one thing the team stopped doing because of this document. If nothing, the set is decorative and the cycle cost you real hours.

Cascading as copy-paste. Key Results copied downward to become the next level’s Objectives. Every named practitioner rejects this, though note that almost all of them still want leadership to set direction first, so the useful rule is narrower than “never cascade”: direction flows down, objectives get negotiated locally.

Too many Objectives. Focus is the mechanism this document has and no other document in the family has. Three Objectives with four Key Results each is twelve numbers nobody will look at twice.

An unanswered compensation question. Silence is read as yes. If the team suspects the score feeds a review, you will get sandbagging next cycle and you will not be told why.

Before you agree the set

Section titled “Before you agree the set”
  • Every Key Result has a baseline someone has read in the last month.
  • Every Key Result has one named person, not a team.
  • Someone outside the team has read the Objective and said it back correctly.
  • You have written down whether the score touches pay or reviews.
  • You can name one thing this set means the team will stop doing.

The artifacts

Section titled “The artifacts”

okrs_template-lean.md · ~2,400 tokens

---
title: "{{team_or_company_name}} OKRs, {{period}}"
owner: "{{who_is_accountable_for_this_whole_set}}"
period: "{{the_cycle_this_covers}}"
parent: "{{the_strategy_or_roadmap_this_serves}}"
audience: "{{who_reads_this}}"
status: "{{draft_or_agreed}}"
last_updated: "{{date}}"
doc_type: okrs
size: lean
source_template: okrs
source_template_version: 0.1.0
---


<!--
HOW TO FILL THIS IN


1. Read each section's comment: what it is, why it exists, the questions to ASK, a GOOD and a WEAK example,
   and the TRAP to avoid.
2. Work top to bottom. The Objective is the easy part and the Key Results are the whole job: if you find
   yourself writing a list of things you will do, stop, because those are Initiatives and they belong in the
   full variant, not here.
3. If a section does not apply, write "N/A" and one line of why, rather than deleting it.
4. Before you share it: self-grade against okrs_guide.md, then DELETE every comment block. They are
   guidance, not content.


ONE OBJECTIVE PER DOCUMENT. This template holds a single Objective at both sizes. If a team genuinely has
two, write two documents; a second Objective sharing one Key Result table is how a set stops being readable.


THE ONE TEST THAT OUTRANKS EVERY OTHER. Read each Key Result and ask: could we do all of this and still
have failed? If yes, you have written activities. Google's own check is a word list: if a Key Result
contains "consult," "help," "analyze," or "participate," it describes an activity rather than an outcome.
Rewrite it as the change you would see in the world.


WHAT THE EVIDENCE ACTUALLY SAYS, SO YOU ARE NOT MISLED. Goal-setting science is real and well replicated:
specific difficult goals outperform "do your best." But NO study measures whether the OKR format itself,
the quarterly cycle, the 0.0 to 1.0 scoring, or public visibility improves product or business outcomes.
The transfer from one to the other is assumed by vendor content and demonstrated by nobody. Use this
document because it makes a team say out loud what would count as success, not because it is proven.
See okrs_companion.md section 1.


A NOTE ON WHOSE METHOD THIS IS. Unlike a vision, a strategy or a roadmap, this artifact IS a method. Filling
it in adopts commitments that are contested rather than settled: the cadence is convention, the scoring
scale is convention, and the visibility default is a choice. okrs_companion.md section 6 argues each one.
-->


# {{team_or_company_name}} OKRs, {{period}}


## The Period and What This Serves


<!-- WHAT  One short paragraph: which cycle this covers, and which parent document it serves. Name the
           parent by title and link it.
     WHY   An OKR set with no parent is a wish list with arithmetic. The point of naming the parent is that
           it makes the next question answerable: if this Objective is met, does the strategy move? OKRs are
           "a complement to strategy, not a substitute for strategy," and a set of objectives with no
           where-to-play choice behind it is not one. Deep dive: okrs_companion.md section 8.
     ASK   Which document decided this was worth doing? If we hit every Key Result, what does the parent get?
           Is anyone else's OKR set counting on ours?
     GOOD  "Covers FY27 Q1 (January to March). Serves the hiring-platform strategy's second guiding policy,
           that a hiring manager should trust the shortlist without re-screening it themselves."
           (a period, a named parent, and the specific part of it this serves)
     WEAK  "Q1 OKRs for the platform team." (a date and a team; nothing above it, so nothing can be traded
           off against anything)
     TRAP  Naming a parent nobody has read. If the strategy is stale or contested, this section inherits the
           problem rather than fixing it, and the OKR set will be argued about as though it were the
           strategy. -->


{{the_period_and_what_this_serves}}


## Objective


<!-- WHAT  One qualitative sentence: what you are trying to achieve this period. Not a number. One Objective
           per document, at both sizes; if you genuinely have two, write two documents.
     WHY   The Objective is the part people repeat from memory a month later, which is its entire job. It
           carries the meaning; the Key Results carry the measurement. Published guidance is to "Pick just
           three to five objectives..." across a whole organisation, so one for a team is normal rather than
           thin. Deep dive: okrs_companion.md section 3 (Objective).
     ASK   Could someone on the team say this back without reading it? Does it describe a change in the world
           rather than a change in our backlog? Would we be pleased if it happened by a route we have not
           thought of?
     GOOD  "Hiring managers trust the shortlist enough to stop re-screening it."
           (qualitative, memorable, and it names whose behaviour changes)
     WEAK  "Improve the candidate matching algorithm by 15 percent." (a Key Result wearing an Objective's
           clothes; it names a mechanism and a number, so it forecloses every other route)
     TRAP  Writing an Objective that is really a project. If the Objective names the thing you are building
           rather than the change you expect, the Key Results underneath it will only ever measure whether
           you built it. -->


{{objective}}


## Key Results


<!-- WHAT  Two to four measurable outcomes that would tell you the Objective happened. Each with a baseline,
           a target, and one named person. A table.
     WHY   This is where the document lives or dies, and the commonest way this section goes wrong is a Key
           Result that describes work rather than a result. Google's own instruction is that Key Results "must describe
           outcomes, not activities," with a rewrite example, "publish average and tail latency measurements
           from six Colossus cells by March 7," rather than "assess Colossus latency." The rule is dominant
           but not unanimous: milestone Key Results are defended for work with genuine phases, such as a
           release, and one named coach argues that work whose outcome cannot yet be measured, like
           compliance, belongs on due dates instead of in an OKR. Deep dive: okrs_companion.md section 3
           (Key Results).
     ASK   Could we hit all of these and still have failed the Objective? What is the number today, and do we
           actually have a way to read it? Who reads it, and how often? Is any of these really a task?
     PRIORITY  A baseline is not optional. Without one, the target is unfalsifiable and the close-out
           conversation becomes an argument about what the number used to be.
     ROW HINT  GOOD  | 1 | Share of shortlists a hiring manager accepts without re-screening | 34% | 60% | Priya (PM) |
               WEAK  | 1 | Ship the new matching model | n/a | Done | Eng |
               (the first names a change in behaviour with a number you can read today; the second is an
               initiative with a checkbox, and a team rather than a person)
     GOOD  "Median days from role opening to a shortlist the manager accepts: 9 today, 5 by the end of the
           quarter."
           (a real number, a real target, and it moves only if something actually changed)
     WEAK  "Improve shortlist quality." (nothing to read, nothing to disagree with, nothing to close out)
     TRAP  Writing Key Results you already know you will hit. That is sandbagging, and it is the predictable
           consequence of scoring being attached to anything that matters to someone's career. Google names
           it as a trap in its own playbook. -->


| # | Key Result (a measurable outcome) | Baseline today | Target by end of period | Owner |
|---|---|---|---|---|
| 1 | {{key_result_1}} | {{baseline_1}} | {{target_1}} | {{owner_1}} |
| 2 | {{key_result_2}} | {{baseline_2}} | {{target_2}} | {{owner_2}} |
| 3 | {{key_result_3}} | {{baseline_3}} | {{target_3}} | {{owner_3}} |


## What This Set Is Not Committing To


<!-- WHAT  Two to four things that were asked for, considered, and deliberately left out of this cycle, each
           with one line on why. Name real requests.
     WHY   This is the section that makes the Objective usable, and the one most often left out. An OKR set
           without exclusions cannot be used to refuse anything, which means it settles no arguments and
           changes nobody's week. It is also the honest place to put the work that is genuinely happening
           but is not what this cycle is about. Deep dive: okrs_companion.md section 3 (What This Set Is Not
           Committing To) and section 7.
     ASK   What has been asked for repeatedly that we are not doing this cycle? Who will be disappointed, and
           have they been told by a person rather than by this document? Is anything here actually a refusal
           we have not made yet?
     GOOD  "Agency-recruiter access. Asked for by two of our largest accounts. Not this cycle, because it
           competes for the same review capacity the shortlist work needs. Both accounts have been told by
           their account manager, and it is the first candidate for next cycle."
           (a real request, a reason, who was told, and what would change)
     WEAK  "Anything not aligned to the objective." (refuses nothing in particular, so it protects nothing)
     TRAP  Listing only things nobody wanted. If every exclusion is uncontroversial, the hard refusals are
           still hiding, and they will arrive mid-cycle as an interruption nobody agreed to. -->


{{what_this_set_is_not_committing_to}}

Provenance

Section titled “Provenance”

The reasoning, the history and every source, in the repository:

  • Companion - the long-form argument: why these sections, where the sources disagree, and what the bundle refuses to claim
  • History - what changed in this bundle, and when
  • Research log - every source consulted, with what each one actually supports
  • Catalog metadata - the machine-readable record this page is generated from

Catalog record: 7 sections across 1 format(s), methodology OKR-driven, typically owned by Exec / PM.