Templates
OKR Template
Copy the objective-plus-three-key-results structure below directly: one qualitative objective stated in plain language, and three measurable key results that move from a starting number to a target number by a stated date. The framework traces back to Andy Grove at Intel in the 1970s, and its own origin story is a useful check on what a real key result looks like versus a task wearing a number.
An objective is the direction; key results are the proof you got there. Copy the structure below, and swap in a real objective and three real numbers.
Andy Grove built the discipline behind that structure, not as an abstract framework but as the actual management method he used to run Intel through its shift from memory chips to microprocessors. As What Matters, the platform built around John Doerr's own writing on OKRs, tells it, "Under Grove, Intel increased revenues from $1.9 billion to $26 billion," and Grove himself put the underlying philosophy plainly: "It almost doesn't matter what you know. It's what you can do with whatever you know." That is the same standard a key result should meet: not what you know or intend, but a number that proves you did something with it.
What does a filled-in OKR actually look like?
| Field | Example |
|---|---|
| Objective | Make activation the first thing a new user experiences, not a maze they have to survive |
| Key Result 1 | Lift week-one activation rate from 40 percent to 55 percent |
| Key Result 2 | Cut time-to-first-value from 12 minutes to 5 minutes |
| Key Result 3 | Reduce onboarding drop-off at step 2 from 30 percent to 15 percent |
Notice what is missing from that objective: a feature name, a launch date, or a task. Those belong on the roadmap that supports this OKR, not inside the OKR itself.
How do you tell a real key result from a task with a number attached?
A task states an activity: "ship the new onboarding flow." A key result states a measured change: "lift week-one activation from 40 percent to 55 percent." The test is whether the number could move without the specific activity you had in mind, or whether the activity could complete without the number moving at all; if either is true, you have written a task, not a key result, and the fix is to ask what the activity was actually supposed to change and measure that instead.
Why does mixing stretch and confident key results matter?
Three stretch key results in one objective produces a predictable pattern: the team either misses all three and stops trusting the framework, or quietly lowers ambition until the numbers become safe, which defeats the purpose just as thoroughly. A workable mix pairs one or two key results the team is genuinely confident it can hit under normal execution with at most one real stretch, so the end-of-quarter score reflects actual performance instead of a habit of sandbagging the targets or a habit of setting numbers nobody expected to hit.
How does this trace back to where OKRs actually came from?
Grove developed the method at Intel after concluding that valuing expertise without execution produced mediocre outcomes, building on Peter Drucker's earlier Management by Objectives work from the 1950s. What Matters records that Intel's shift under Grove, from memory chips to microprocessors, helped put personal computers in "95 percent of American households by 2024." John Doerr, who studied under Grove and later introduced the framework to Google's founders in 1999, carried the same method forward into "Measure What Matters," the book most teams now cite when adopting OKRs. The through-line from Intel's revenue growth to a template you fill in this quarter is the same idea Grove insisted on from the start: execution, measured, matters more than the plan on paper.
When should OKRs get reviewed, and how does that connect to the rest of the quarter?
Weekly, briefly, at the team level, with a formal check at the midpoint and a real close-out at the end of the quarter. A key result that is quietly off track in week 3 is a small correction; the same drift discovered in week 11 is a missed quarter with no time left to fix it. Pair this OKR template with the product roadmap template for the work itself and the PRD template for any single initiative that needs more detail than an objective and three numbers can carry.
Builders Camp's How to Design OKRs bootcamp covers writing objectives that hold up under scrutiny, choosing key results that are actually outcomes, and running the review cadence that keeps OKRs from quietly becoming a task list with extra formatting.
Bootcamps referred in this Guide
Frequently asked questions
How many key results should one objective have?
Three is the practical target: enough to check an objective from more than one angle, not so many that the team loses track of which one actually matters most this quarter. Two can work for a narrow objective; five or more usually means the objective itself is too broad and should split into two.
What is the actual difference between an objective and a key result?
An objective is the qualitative direction, what you are trying to achieve and why it matters, stated in plain language a new hire could understand without context. A key result is the quantitative proof: a specific, measurable number that moves from a starting value to a target value by a stated date. If a key result has no number in it, it is actually a task disguised as a key result.
Should every key result be a stretch goal?
Not automatically, and treating every key result as an aggressive stretch is a common way OKRs lose credibility. A mix works better: at least one key result the team is confident it can hit if things go normally, and at most one genuine stretch, so the score at quarter's end reflects real performance instead of habitual sandbagging or habitual overreach.
What is a common mistake that turns OKRs into a disguised task list?
Writing key results as completed activities ("launch the new onboarding flow") instead of outcomes ("lift week-one activation from 40 percent to 55 percent"). A shipped feature is not automatically a result; the key result should measure what changed for the user or the business because of it, not whether the work got done.
How often should OKRs be reviewed once they are set?
Weekly at the team level, even briefly, and formally at the midpoint and end of the quarter. A quarterly-only cadence lets a key result drift for months before anyone notices it is off track; a short weekly check-in catches that early enough to actually adjust the work, not just the retrospective.
Do OKRs replace a product roadmap?
No, they answer a different question. A roadmap states what ships and roughly when; OKRs state what outcome that work is supposed to produce and how you will know it worked. Use both together: the [product roadmap template](/guides/templates/product-roadmap-template) for sequencing the work, this OKR template for stating why it matters and what success looks like.
Sources

Andre Albuquerque
CEO of Builders Camp, SuperOperator, and other companies. Building products.
CEO of Builders Camp, SuperOperator, and other companies. Building products.
LinkedInMore guides by Andre AlbuquerqueLast updated 2026-10-05
Researched from Builders Camp's bootcamp, track and masterclass material and the sources listed on this page, drafted with AI, and fact-checked against every source cited.
Related guides
How to grade OKRs: check-ins, scoring and retros without status theatre
Grade OKRs once, at the end of the quarter: score each key result from 0.0 to 1.0 by how far it moved from baseline...
Paulo TavaresProduct Roadmap Template
A product roadmap template organized by outcome and time horizon (Now, Next, Later) rather than by fixed date, with a...
Andre AlbuquerquePRD Template
A working PRD template has eight sections: problem, goals, non-goals, users, requirements, success metrics, open...
Andre AlbuquerqueNorth Star Metric Examples
A North Star Metric is the single number a company treats as the clearest signal that its product is delivering real...
Andre Albuquerque