OKR Examples for Small Teams, With the Tasks Behind Them

A good OKR is one objective, a sentence saying what you want to be true, with three or so key results underneath that prove it happened. “Make support something customers stop complaining about” is an objective. “Median first response under 4 business hours, from 9” is a key result. “Write ten reply templates” is neither: it is a task, and it belongs on the board under that key result. Below: the rules, twelve examples by team, and how to keep each key result tied to its tasks.

Objectives, key results and tasks

The definitions are short. According to What Matters, John Doerr’s OKR site↗ (opens in a new tab), an objective is “simply what is to be achieved, no more and no less” and should be significant, concrete, action oriented and ideally inspirational, while key results “benchmark and monitor how we get to the Objective” and should be specific, time-bound, and aggressive yet realistic.

• Objective: qualitative, a direction someone would be glad to reach. No number needed.
• Key result: a number with a starting value and a target, read from somewhere real. If you cannot say where the number comes from, it is not yet a key result.
• Task: something a person or an AI assistant can start on Monday. Tasks move key results; they are not key results.

If you already write SMART goals, each key result can be written as one. The difference in shape between a single SMART goal and an OKR is covered in SMART goal examples; this post assumes you have picked OKRs.

Outputs vs outcomes

The most common mistake is a key result that counts work done instead of the change the work was meant to cause. An output is something you produce: articles published, calls made, features shipped. An outcome is what changes because of it: fewer tickets, more trials that convert, faster builds. Google’s guide to setting goals with OKRs↗ (opens in a new tab) puts it plainly: “Key results should describe outcomes, not activities,” and if a key result uses words like “consult,” “help,” “analyze” or “participate,” it is describing an activity.

• Output: “Publish 20 help articles.” Outcome: “Tickets on the 20 most common topics fall from 300 a month to 180.”
• Output: “Ship the new onboarding flow.” Outcome: “Share of new sign-ups who create a first project within a day rises from 35 percent to 55 percent.”
• Output: “Run 40 discovery calls.” Outcome: “Qualified pipeline from outbound grows from 6 opportunities a month to 10.”

Outputs are not useless. They are the tasks. Keep them on the board and let the key result measure whether they worked. A useful test from What Matters’ list of common mistakes: is it reasonable to score 1.0 on every key result and still miss the intent of the objective? If yes, the key results are necessary but not sufficient, and one is missing.

Committed vs aspirational OKRs

What Matters describes two kinds, and asks you to label each one at the start of the cycle. On its page on committed and aspirational OKRs↗ (opens in a new tab), a committed OKR is graded pass or fail, and resources and schedules should be adjusted to make sure it gets done. An aspirational OKR is set beyond what the team can do in one cycle, may take several cycles, and stays on the list until it is completed; the site notes Google expects an average of about 70 percent on these.

For a small team the practical rule is: most OKRs committed, one aspirational at most. Mark them “C” and “A” as the examples below do. Mixing them without labels is how a team ends a quarter unsure whether 60 percent was a success or a failure.

OKR examples by team

The companies and numbers below are invented, so each example can show the parts clearly. Use your own baselines. None uses money, because revenue targets depend on your prices and your market; swap in your own if revenue is the point.

Engineering

1. (C) Objective: Releases stop being an event. KR1: median build time from 14 minutes to 7. KR2: deploys per week from 2 to 10. KR3: rollbacks per month stay at 1 or fewer while deploys rise.
2. (A) Objective: Customers never find a billing bug before we do. KR1: customer-reported billing bugs from 12 a month to 2. KR2: billing bugs that reappear after a fix from 3 a quarter to 0. KR3: time from bug report to fix in production from 6 days to 2.

Product

1. (C) Objective: New users reach their first win on day one. KR1: sign-ups who create a first project within 24 hours from 35 percent to 55 percent. KR2: onboarding support tickets from 80 a month to 40. KR3: new users still active after 30 days from 40 percent to 50 percent.
2. (C) Objective: We build what customers ask for most. KR1: every feature request tagged to a customer segment within two days of arriving. KR2: three of the five most requested features shipped. KR3: churned-customer survey citing a missing feature from 40 percent to 25 percent.

Customer support

1. (C) Objective: Support feels fast. KR1: median first response from 9 business hours to 4. KR2: tickets reopened after being closed from 15 percent to 8 percent. KR3: satisfaction score on closed tickets from 82 percent to 90 percent.
2. (A) Objective: Customers answer their own questions. KR1: tickets on the 20 most common topics from 300 a month to 180. KR2: help-center searches that end in a ticket from 30 percent to 15 percent.

Sales

1. (C) Objective: Every trial gets a real conversation. KR1: trials contacted by a person within three days from 40 percent to 90 percent. KR2: trial-to-paid conversion from 14 percent to 18 percent. KR3: qualified demos per account executive from 8 a month to 12.

Marketing

1. (C) Objective: Search brings us people who are ready to try the product. KR1: organic sign-ups from 150 a month to 250. KR2: 10 guides reach page one of Google for their target phrase. KR3: newsletter subscribers from 3,000 to 4,500, with unsubscribes under 1 percent per send.

Operations

1. (C) Objective: New hires are productive in their first week. KR1: days from start date to first completed task from 9 to 3. KR2: new-hire survey “I knew what to do on day one” from 50 percent to 85 percent. KR3: questions a new hire has to ask in week one from about 30 to 10.
2. (C) Objective: Nobody waits on paperwork. KR1: average invoice approval time from 6 business days to 2. KR2: vendor questions about payment status from 25 a month to 5.

Solo founder

1. (C) Objective: I know exactly who the product is for. KR1: 15 customer interviews completed. KR2: one customer segment accounts for at least 60 percent of active accounts. KR3: the home page rewritten for that segment, and its sign-up rate from 2 percent to 3.5 percent.
2. (A) Objective: The business runs for a week without me. KR1: support tickets I personally answer from 90 percent to 30 percent. KR2: recurring tasks that only I can do from 20 to 5. KR3: one full week away with no customer-facing incident.

OKRs and KPIs

People searching for OKR and KPI examples usually want to know where one ends. What Matters’ page on the difference between KPIs and OKRs↗ (opens in a new tab) says KPIs most often monitor the steady state, while OKRs describe outcomes, and that a KPI can become a key result “if it’s a measurement that you want to significantly change.” So first-response time is a KPI you watch every week; it becomes a key result in the quarter you decide to halve it. Once it is where you want it, it goes back to being a KPI.

Linking each key result to the tasks behind it

An OKR set that lives only in a slide is forgotten by week three. The fix is to make every task traceable to one key result, and every key result traceable to the tasks moving it. Take the support example:

Objective (C): Support feels fast.
KR1: Median first response from 9 business hours to 4.

Tasks:
- Add a second morning shift, 7 to 11 a.m. Eastern
- Draft 10 reply templates for the most common ticket types
- Auto-tag tickets by topic so the right person sees them first
- Weekly: read the median from the help desk report, note it here

Three habits keep the link honest. Name the key result in each task, so anyone reading the task knows why it exists. When a task is finished, ask whether the number moved, not just whether the task is done. And if a key result has no tasks by week two, it is either already on track or quietly abandoned; find out which.

Mid-quarter check-ins

Google’s guide recommends a mid-quarter check-in on OKRs at every level before the final grade. The same rhythm is used well beyond tech: the federal government’s performance framework↗ (opens in a new tab) has agency leaders set a few priority goals and review performance quarterly to identify barriers to progress. For a small team, a monthly half hour is enough:

1. Read each key result’s current number from its source, not from memory.
2. Score it 0.0 to 1.0 against where it should be by now.
3. For anything behind, look at its tasks: are they done, stuck or missing?
4. Decide one change per lagging key result: add a task, drop one, or, for a committed OKR, move people onto it.
5. Write down any decision that changes the plan, with who made it.

Where fenbs fits

fenbs does not track goals. There is no OKR screen, no progress bar and no due dates, so the objectives, key results and their numbers live in your planning document. What fenbs holds is the work. Make each objective a project, or each key result a category, and file its tasks there; Add many turns a pasted list into tasks in one step. Every task has a note for the problem, a plan for how it will be done, a priority from 1 to 10 where 1 is the most urgent, and an optional size from XS to XL. Filter by the project at the check-in, and Copy as Markdown gives you the tasks to paste beside the numbers.

If an OKR sets a standard the team should hold from now on, such as “first response within 4 business hours,” record it on the Decisions and rules page as a rule. Every connected AI assistant reads the rules first, so an assistant drafting replies works to the same target. The decider is always a person.