OKR Setting Workshop: From Company Goals to Team Objectives in 2 Hours

Overview

OKRs fail for one reason more than any other: the team sets them in isolation. A PM writes objectives on a Friday afternoon, shares them in a Monday meeting, and everyone nods. Three weeks later, nobody can remember what the OKRs are. They were never the team's goals. They were the PM's document.

This workshop fixes that by making OKR creation a team activity. When engineers, designers, and PMs build objectives together, three things happen: the objectives are more realistic (because the people doing the work shaped them), the key results are more measurable (because the people closest to the data picked the metrics), and the commitment is stronger (because people own what they build).

Who this is for: Product managers or engineering managers facilitating quarterly OKR setting with their team. The workshop assumes company-level or org-level OKRs already exist. This session translates them into team-level objectives.

Time required: 120 minutes (with two 5-minute breaks)

What participants will walk away with:

• 3-5 team-level objectives linked to company strategy
• 2-4 measurable key results per objective with baseline and target numbers
• A dependency map showing where the team needs support from other teams
• Explicit "not doing" list to protect focus

Pre-requisites:

• Company or org-level OKRs must be finalized and shared with participants at least 48 hours before
• The team's north star metric (or the closest thing to it) should be defined. If it is not, run the North Star Finder exercise before this workshop.

Materials Needed

Before the workshop:

• Company/org OKRs printed or displayed on one page (one copy per participant)
• Last quarter's team OKRs with final scores (for the retrospective in Part 1)
• Whiteboard or Miro/FigJam board with four zones: Strategy Context, Objectives, Key Results, Dependencies
• Sticky notes in three colors: blue (objectives), yellow (key results), red (dependencies)
• Timer visible to the room

Facilitator prep (20 minutes before):

• Write the company OKRs on the board where everyone can see them for the full session
• Prepare a "translation prompt" card for each company OKR (see Part 2)
• Set up the dependency mapping template (see Part 4)

Part 1: Last Quarter Retrospective (20 minutes)

What this accomplishes

You cannot set good OKRs for the future if you have not honestly assessed the past. This retrospective grounds the team in reality. What they actually accomplished versus what they planned. Before the optimism of new goal-setting takes over.

Facilitator instructions

Review last quarter's scores (10 minutes):

Display last quarter's OKRs. For each key result, share the final score (0.0 to 1.0 scale, where 0.7 is the target).

Go objective by objective:

"Objective 1 was [read it]. Our key results scored [X], [Y], and [Z]. That gives us an overall score of [average]. Let's spend 2 minutes on this: what drove the score? If it was high, what did we do right? If it was low, what got in the way?"

Key facilitation tip: Resist the urge to explain or defend low scores. Let the team diagnose. If the PM starts justifying. "well, we had that reorg in the middle of the quarter". Gently redirect: "That context is useful. What should we learn from it for this quarter's OKRs?"

Identify carryover items (5 minutes):

"Are there any key results from last quarter that we need to continue this quarter? Some things take more than one quarter to move. That is normal. But we need to be intentional about it rather than having stale OKRs that roll over by default."

List any carryover items on the board. These will be inputs to Part 2.

Capture meta-lessons (5 minutes):

"Setting aside the specific objectives. What did we learn about how we set OKRs? Were they too ambitious? Too vague? Did we miss dependencies? I want 2-3 sticky notes from anyone with a process improvement."

Post these next to the board. Refer back to them during Part 3 to avoid repeating the same mistakes.

Part 2: Strategy Translation (25 minutes)

What this accomplishes

This is the most critical section. "Cascading" OKRs does not mean copying the company objective and adding your team name. It means understanding the company's strategic intent and asking: "What must our team specifically achieve for this company objective to succeed?"

Facilitator instructions

Present the company OKRs (5 minutes):

Read each company-level objective and its key results aloud. For each one, provide brief context:

"Company Objective 2 is 'Expand into the mid-market segment.' The key results are: [read them]. For context, this came out of the board meeting where the CEO shared that enterprise growth is slowing and mid-market represents a $X opportunity. Questions on what this means?"

Answer questions of clarification only. Do not let this become a debate about company strategy. That conversation belongs in a strategy alignment session, not an OKR workshop.

Translation exercise (15 minutes):

For each company objective (typically 3-5), use this prompt:

"Given that the company wants to [company objective], what must our team specifically deliver or achieve to contribute? Think about outcomes, not outputs. 'Ship the enterprise dashboard' is an output. 'Enable enterprise buyers to self-evaluate the product without talking to sales' is an outcome."

Silent brainstorming (5 minutes): Each participant writes potential team objectives on blue sticky notes. One objective per note. Aim for 2-3 per company objective.

Share and cluster (5 minutes): Place all blue stickies on the board, organized under the company objective they support. Read them aloud. Cluster similar ideas. You will likely see 10-20 candidate objectives.

First filter (5 minutes): Eliminate duplicates and merge similar objectives. Then apply this test to each remaining candidate:

"If our team achieved this objective but no key result moved, would we still be proud of the work? If the answer is no, it might be a task disguised as an objective."

You should be down to 6-10 candidates after filtering.

Take a 5-minute break.

Part 3: Objective Selection and Key Result Definition (35 minutes)

What this accomplishes

This section narrows the candidate objectives to the final 3-5 and defines measurable key results for each. The measurability check is the most important quality gate in the OKR process. Vague key results are worse than no key results because they create an illusion of alignment.

Facilitator instructions

Dot voting on objectives (5 minutes):

Each participant gets 5 dots. Place them on the candidate objectives you believe would have the highest impact on company OKRs. Dots can be stacked.

Rank by dot count. Take the top 3-5. If there is a near-tie, include both and decide after key results are defined (sometimes an objective that sounds great has no measurable key result, which resolves the tie).

Key result brainstorming (15 minutes):

Split into pairs or small groups. Assign each group 1-2 objectives. Each group defines 2-4 key results per objective.

Give them this quality checklist:

A good key result must pass all four tests:

1. Measurable: Can you put a number on it? "Improve onboarding" fails. "Increase day-7 activation rate from 32% to 45%" passes.
2. Has a baseline: Do you know the current number? If you do not, the first key result should be "establish a baseline for [metric] by [date]."
3. Outcome-oriented: Does it describe an end state, not an activity? "Run 20 user interviews" is an activity. "Identify and validate the top 3 onboarding friction points" is an outcome.
4. Influenceable: Can the team meaningfully move this number through their own work, or does it depend on external factors they cannot control?

Share and stress-test (15 minutes):

Each group presents their key results. For each one, the room applies the four tests:

"Is this measurable? What is the baseline? Is this an outcome or an activity? Can we actually influence this?"

Expect 30-40% of initial key results to fail at least one test. That is normal. Rewrite them on the spot.

Common rewrites:

• "Improve customer satisfaction" → "Increase NPS from 42 to 55 for the onboarding cohort"
• "Launch new pricing page" → "Increase trial-to-paid conversion from 8% to 12%"
• "Reduce tech debt" → "Decrease p95 API response time from 800ms to 200ms"
• "Better collaboration with sales" → "Reduce average sales-to-PM escalation response time from 48 hours to 4 hours"

Target-setting guidance:

For each key result, set two numbers:

• Target (1.0): Aspirational but possible. The team has a 30% chance of hitting this.
• Expected (0.7): Realistic with strong execution. The team has a 70% chance of hitting this.

If the team's expected score equals the target, the OKR is too easy. If the team cannot articulate what 0.7 looks like, the key result is too vague.

Part 4: Dependency Mapping and "Not Doing" List (20 minutes)

What this accomplishes

OKRs that require another team's cooperation but do not account for that dependency will fail in week 3 when the other team has different priorities. This section makes dependencies explicit and creates the "not doing" list that protects the team's focus.

Facilitator instructions

Dependency identification (10 minutes):

For each objective and key result, ask:

"Can our team achieve this entirely on our own? If not, who do we need, and what do we need from them?"

Write dependencies on red sticky notes in this format: "We need [team] to [specific deliverable] by [date] for [our objective] to succeed."

Place red stickies on a dependency map:

For each dependency, assign an owner from your team who will reach out to the dependent team within 48 hours of the workshop. Do not leave the workshop hoping dependencies will sort themselves out.

"Not Doing" list (10 minutes):

This is the most protective output of the workshop. With 3-5 objectives and 8-15 key results, the team's quarter is full. Everything else is a "not doing" item.

"We have defined what we will focus on. Now I need us to be explicit about what we will not do. What requests, projects, or ideas have come up recently that are not covered by our OKRs? Let's write them down. Not to kill them, but to be honest that they are not this quarter's focus."

Have each participant write 1-2 "not doing" items. Place them on the board.

"For each of these: is there a stakeholder who expects us to do this? If yes, who will communicate the decision, and when?"

Assign communication owners. The "not doing" list is only useful if the people expecting that work actually hear that it is deprioritized.

Take a 5-minute break.

Part 5: Final Review and Commitment (20 minutes)

What this accomplishes

The final section pressure-tests the complete OKR set and secures team commitment. It is the difference between "OKRs we wrote" and "OKRs we believe in."

Facilitator instructions

Full OKR read-through (5 minutes):

Display the complete set of OKRs. Read each objective and its key results aloud, including baseline numbers, targets, and owners.

Sanity checks (10 minutes):

Run through these quality gates with the team:

1. Coverage check: "Do our objectives collectively cover the company OKRs we are expected to contribute to? Is there a company objective we have not addressed?"
2. Capacity check: "Look at everything we have committed to. Given our team size, current projects, and the dependency map. Is this achievable in one quarter? If we are at 120% capacity, what gets cut?"
3. Conflict check: "Do any of our key results conflict with each other? Could pursuing Key Result A make Key Result B harder?"
4. Measurability check: "For every key result, do we have access to the data today? If not, who sets up the tracking, and by when?"

Commitment round (5 minutes):

Go around the room. Each person answers:

"On a scale of 1 to 5, how confident are you that these are the right OKRs for this quarter?"

If anyone is below a 3, stop and ask why. Unresolved concerns at this stage become silent resistance later.

"And one more: is there anything we discussed today that you disagree with but are willing to commit to? Disagree-and-commit is fine. Disagree-and-silently-sabotage is not."

Document any noted disagreements. Review them at the mid-quarter check-in.

Next Steps for the Facilitator

Within 24 hours of the workshop:

1. Publish the final OKRs in the team's shared space (wiki, Notion, Google Doc). Include: objectives, key results with baselines and targets, owners, dependencies, and the "not doing" list.
2. Send dependency requests to all dependent teams. Each request should include: what you need, by when, and why (link to the specific OKR).
3. Set up tracking dashboards for every key result. If you cannot measure it within the first two weeks of the quarter, the key result needs to be revised.
4. Schedule a mid-quarter OKR review (45 minutes, 6 weeks into the quarter). The agenda: score each key result at the midpoint, identify any that are off-track, adjust plans.
5. Communicate the "not doing" list to stakeholders who expected that work. Do this proactively. Do not wait for them to ask.

For teams whose north star metric is not well-defined, the North Star Finder tool helps identify the single metric that best captures your product's core value delivery.

Facilitator Tips

On the relationship between OKRs and product strategy:

• OKRs are not strategy. They are the quarterly expression of strategy. If the team cannot connect their objectives to a clear product strategy, no amount of OKR craft will help. Run a strategy alignment workshop first.
• Each objective should answer the question: "Why this quarter?" If the answer is "because it is always important," it is probably a health metric to monitor, not a quarterly objective.

On key result quality:

• The most common failure is key results that are actually tasks in disguise. "Launch feature X" is a task. "Achieve outcome Y through feature X or any other means" is a key result. The distinction matters because it gives the team freedom to find the best solution.
• If a key result does not have a baseline, make establishing the baseline the first key result. "Go from ? to 50%" is not an OKR. It is a hope.
• Binary key results (shipped/not shipped) are acceptable for infrastructure or platform work where the outcome is "this capability exists." But limit them to 1-2 per quarter.

On timing:

• Run this workshop in the first week of the quarter, not the last week of the previous one. OKRs set too early become stale by the time the quarter starts.
• The 2-hour investment pays for itself in the first week, when someone asks "should we work on X?" and the team can answer by checking the OKRs rather than debating from scratch.
• Part 2 (Strategy Translation) is where time pressure hits hardest. If you are running long, shorten Part 1 (the retro) rather than rushing the translation exercise. Bad translation produces bad OKRs.

On common dysfunctions:

• Sandbagging: Teams set easy OKRs to guarantee a 1.0 score. Counter this by asking: "If you achieved this objective, would leadership be impressed or just say 'that is what we expected'?"
• Kitchen-sink OKRs: Teams include every possible workstream to avoid saying no to anything. Counter by enforcing the 3-5 objective limit. If it does not fit, it goes on the "not doing" list.
• Vanity key results: Metrics that look good but do not matter (page views instead of activation, sign-ups instead of retention). For each key result, ask: "If this number went up but revenue or retention stayed flat, would we still celebrate?"
• Set-and-forget: OKRs written in week 1, ignored until week 12. The mid-quarter review prevents this, but only if it is actually on the calendar with a clear owner.

On remote facilitation:

• Use a shared Miro or FigJam board as the single workspace. Pre-populate it with the template: company OKRs at the top, team objective slots below, key result slots under each objective, dependency map on the right.
• The silent brainstorming in Part 2 works well remotely. People write on digital stickies without seeing others. But the stress-testing in Part 3 needs active video discussion. Do not try to do it asynchronously.
• Assign a note-taker who is not the facilitator. Remote workshops produce more artifacts, and the facilitator cannot manage the board and the discussion simultaneously.

On connecting OKRs to daily work:

• The gap between quarterly OKRs and daily tasks is where most OKR implementations break down. Bridge it by asking teams to identify their "weekly bets". The 1-2 things they will do this week that directly move a key result. Review weekly bets in standup every Monday.
• Make OKRs visible. Put them in the team's Slack channel topic, on the sprint board header, or on a dashboard that the team sees daily. Out of sight means out of mind.
• When someone proposes work that does not map to an OKR, do not automatically reject it. Ask: "Which key result does this move? If none, should we update our OKRs, add this to the 'not doing' list, or make a case for why it is more important than what is on our plate?"