How to Write Key Results That Are Specific and Measurable
This skill teaches you how to write specific, quantifiable key results with clear metrics and numeric targets that accurately measure progress toward an objective, turning aspirational goals into trackable outcomes.
Start with the metric you want to move, set a specific numeric target, and define a clear starting point. A strong key result follows the pattern: verb + metric + from X to Y (or achieve/maintain Z). Each key result should be independently verifiable, meaning anyone on the team can check the data source and confirm whether it was achieved without subjective interpretation.
Outcome: You produce 2-5 key results per objective, each with a named metric, a numeric baseline, a numeric target, and a defined data source, giving your team an unambiguous way to measure progress and score outcomes at end of cycle.
Prerequisites
- A drafted objective (qualitative goal statement) to attach key results to
- Access to current baseline metrics or the ability to establish them
- Basic understanding of the OKR framework structure (objectives vs. key results)
- Familiarity with your team's or product's core metrics and how they are tracked
Overview
Key results are the measurement backbone of the Objectives and Key Results (OKRs) framework. While objectives describe where you want to go in qualitative, inspirational language, key results answer a harder question: how will we know we got there? A well-written key result names a specific metric, states a starting value (the baseline), and declares a target value to reach by the end of the cycle. The result is a clear, binary-testable statement that removes ambiguity from goal tracking. Without this precision, OKR scoring becomes a subjective debate rather than a data-driven review.
The skill of writing measurable key results sits at the intersection of strategic thinking and analytical rigor. You need to understand the objective deeply enough to identify the two or three metrics whose movement would genuinely prove progress, and you need enough data literacy to set targets that are ambitious but grounded in reality. This is harder than it sounds. Teams routinely confuse outputs (ship a feature) with outcomes (increase adoption), or they pick metrics that are easy to measure but disconnected from the objective. The artifact you produce here, a set of 2-5 key results per objective, becomes the contract your team operates against for the entire quarter.
Mastering how to write key results pays dividends across the entire OKR cycle. During check-ins and progress reviews, well-defined key results make status updates factual rather than anecdotal. During scoring and grading, they eliminate arguments about whether the team "mostly" hit the goal. And during planning sessions, having a library of past key results with known baselines accelerates future OKR drafting. The investment you make in writing precise key results compounds across every downstream activity in the OKR framework.
The concrete artifact this skill produces is a structured set of key results, each containing five elements: the metric name, the baseline value, the target value, the data source, and the measurement frequency. When you finish the steps below, you will have a complete, reviewable set of key results that can be plugged directly into your OKR tracker, shared with stakeholders for alignment, and used as the basis for weekly or biweekly progress reviews.
How It Works
A key result works by converting a qualitative aspiration into a quantitative contract. The underlying mental model is simple: if you cannot measure it, you cannot manage it, and if two reasonable people would disagree about whether it was achieved, it is not specific enough. The formula most practitioners use is "Verb + Metric + from X to Y," where X is the current baseline and Y is the target. For example, "Increase 7-day retention from 32% to 45%." This formula forces three decisions: what to measure, where you are starting, and where you need to arrive.
The reason the baseline matters so much is that it anchors ambition in reality. A target of 45% retention sounds aggressive if your baseline is 42% and modest if your baseline is 20%. Without the baseline, you cannot set an appropriate stretch, and you cannot score the key result on the 0.0-1.0 scale that the OKR framework uses at end of cycle. Gathering the baseline is often the most time-consuming part of writing key results, but it is also the most valuable, because it forces you to confirm that the metric actually exists and is being tracked before you commit to moving it.
The distinction between output key results and outcome key results is where most teams trip up. An output is something you deliver: "Launch the new onboarding flow." An outcome is the change that delivery produces: "Increase new-user activation rate from 28% to 40%." Outputs are tasks masquerading as key results. They create a false sense of progress because you can complete the output without producing the desired change. The fix is to ask yourself: "If we did this perfectly, what number would move?" That number is your key result. The task itself belongs on your roadmap or sprint board, not in your OKR.
Another critical dimension is the difference between leading indicators and lagging indicators. Leading indicators measure behaviors or inputs that you believe will drive the outcome (e.g., number of sales calls made). Lagging indicators measure the outcome itself (e.g., revenue closed). A good set of key results usually includes at least one of each type. The leading indicator gives you early signal during the quarter so you can course-correct, while the lagging indicator confirms whether the strategy actually worked. If you only track lagging indicators, you will not know you are off track until it is too late to change course.
Finally, the number of key results per objective matters. The recommendation is 2-5. Fewer than two suggests the objective is too narrow or you are conflating the key result with the objective. More than five creates measurement overhead and dilutes focus. Each key result should represent a genuinely different dimension of success. If two key results move together perfectly (e.g., page views and sessions), one of them is redundant. If they sometimes move in opposite directions (e.g., signup rate and signup quality), both are valuable because they prevent you from gaming one at the expense of the other.
Step-by-Step
Step 1: Restate the Objective and Identify What Success Looks Like
" List every possible change you can think of, without filtering for measurability yet. Think about changes to user behavior, financial metrics, operational efficiency, product usage patterns, customer sentiment, and market position. Capture at least 6-10 possible signals of success. The goal is breadth at this stage.
You are building a candidate pool of potential key results, not committing to any of them. " This list becomes the raw material for the next step.
Tip: Involve 2-3 people who are close to the work when brainstorming signals. Solo brainstorming tends to anchor on the one or two metrics you already watch, missing dimensions that someone in a different role would catch immediately.
Step 2: Filter Candidates for Measurability and Data Availability
Take your list of 6-10 candidate signals and run each one through three filters. First, is this metric already tracked somewhere? Check your analytics tool, database, CRM, or spreadsheet. If the data does not exist yet, note what it would take to start collecting it.
Second, can the metric be expressed as a number (count, percentage, ratio, currency amount, time duration)? If it requires subjective judgment to score, it fails this filter. Third, can the metric be checked within the quarter? Some metrics, like annual revenue or yearly churn rate, move too slowly for a quarterly OKR cycle.
Eliminate candidates that fail two or more filters. For candidates that fail only the first filter (data not yet tracked), decide whether you can instrument the metric within the first week of the quarter. If yes, keep it. If no, drop it.
Tip: A surprisingly common failure mode is picking a metric you can track but cannot influence within the cycle. Before keeping a candidate, ask: "Do we have a plausible theory for how our planned work will move this number?" If not, it is a monitoring metric, not a key result.
Step 3: Establish Baselines for Each Surviving Candidate
For each metric that passed the filter, pull the current value. Be specific about the time window: "7-day retention as of March 1, calculated over the trailing 30-day cohort" is a baseline. "Retention is around 30%" is not. If the metric fluctuates, use a trailing average (typically 4-week or 90-day) as the baseline rather than a single data point.
Document the exact data source and query or report used to generate the baseline, because you will need to pull the same number at end of cycle for scoring. If the metric is new and has no history, your baseline is zero or the value from a manual count during the first week. Record baselines in a table: metric name, baseline value, date pulled, data source, measurement frequency.
Tip: Resist the urge to round baselines. If your activation rate is 28.3%, write 28.3%, not "about 28%." Rounding introduces ambiguity at scoring time and makes it harder to detect small but real improvements.
Step 4: Select 2-5 Key Results That Cover Different Dimensions
From your filtered, baselined candidates, select 2-5 that together represent a complete picture of the objective's success. Apply two tests. First, the independence test: if you achieved key result A but failed key result B, would that feel like a meaningful gap in the objective's success? If yes, both belong.
If achieving A automatically means achieving B, drop one. Second, the gaming test: could a team technically hit all key results through a strategy that violates the spirit of the objective? For example, if the objective is "Delight new customers" and both key results measure signup volume, the team could boost signups with aggressive discounting while delivering a terrible experience. Add a quality or satisfaction metric to close the loophole.
Aim for a mix of at least one leading indicator and one lagging indicator.
Tip: Three key results per objective is the sweet spot for most teams. Two works for narrow objectives. Five is the upper bound, and teams that use five often find that the fourth and fifth get neglected during check-ins.
Step 5: Set Ambitious but Achievable Targets
For each selected key result, set the target value. 7 (70% of the target) represents successful performance, which means targets should be set at a stretch level where hitting 100% would be exceptional. A common heuristic: if you are 90% confident you will hit the target, it is not ambitious enough. If you are less than 50% confident, it may be demoralizing.
Aim for 60-70% confidence. Use historical data to inform targets. If your activation rate improved by 3 percentage points last quarter with moderate effort, a 5-point improvement is a stretch and a 12-point improvement is likely unrealistic. " If the metric is binary (exists or does not), consider whether you can restructure it as a gradient.
"Launch feature X" is binary. "Achieve 500 weekly active users of feature X" is a gradient.
Tip: When setting targets for metrics you have never tracked before (baseline is zero), talk to peers at similar companies or use industry benchmarks to sanity-check your target. Without a reference point, teams either sandbag or set impossible numbers.
Step 6: Write Each Key Result in Standard Format
Draft each key result using a consistent sentence structure. The recommended format is: "Verb + metric + from [baseline] to [target]." Examples: "Increase 7-day retention from 32% to 45%." "Reduce average support response time from 4.2 hours to 1.5 hours." "Grow monthly active integrations from 1,200 to 3,000." For maintenance-style key results where you want to hold a level, use: "Maintain uptime above 99.9% (current: 99.7%)." Avoid vague verbs like "improve" without a direction, or modifiers like "significantly." Each key result should be one sentence. If you need two sentences to explain it, the metric is probably too complex or you are bundling two key results into one. After drafting, read each key result aloud and ask: "Could a new hire who joins next week look at this and know exactly what to check and whether it was hit?" If not, revise.
Tip: Keep a shared glossary of metric definitions. "Activation rate" might mean different things to product, marketing, and sales. Pin down the exact definition (e.g., "percentage of new signups in a cohort who complete onboarding and perform one core action within 7 days") and link to it from the key result.
Step 7: Assign a Data Source and Measurement Cadence to Each Key Result
, "Mixpanel funnel report: New User Activation"), the person or system responsible for pulling the number, and how often it will be checked (weekly, biweekly). This step is often skipped, and the consequence is that check-ins stall because nobody knows where to find the data. , counting items in a spreadsheet), assign an owner and a recurring calendar reminder. If the metric comes from an automated dashboard, link directly to the specific view.
If you are using a tool like a spreadsheet or OKR tracker, create the column or field now so the data has a place to live before the quarter starts. The output of this step is a measurement table appended to each key result: metric, data source, owner, and cadence.
Tip: Run a "day one drill" before the quarter starts: actually pull each metric from the stated data source. If the pull takes more than 5 minutes or requires special access, fix the tooling or simplify the metric. If check-in measurement is painful, it will not happen consistently.
Step 8: Pressure-Test with Stakeholders
Share your drafted key results with at least two audiences: the team that will execute against them and a peer or leader who sits outside the team. The executing team checks for feasibility: are these targets realistic given our planned work and capacity? Are there dependencies outside our control that could block progress regardless of effort? The outside reviewer checks for alignment: do these key results, if achieved, genuinely prove the objective was met?
Are there obvious gaps or gaming risks? Collect feedback in a structured format. " Revise based on feedback. Common revisions at this stage include swapping an output for an outcome, adjusting a target up or down by 10-20%, and adding a missing quality metric to prevent gaming.
Tip: Time-box the review to 30 minutes. If the conversation drags beyond that, it usually means the objective itself is unclear, not just the key results. Escalate to an objective rewrite rather than endlessly wordsmithing key results.
Step 9: Finalize and Lock Key Results for the Cycle
After incorporating feedback, finalize each key result and lock it in your OKR tracker, document, or spreadsheet. , a major pivot, a dependency that evaporates). Document the final set in a visible, shared location. Each entry should contain: the objective it belongs to, the key result statement, the baseline, the target, the data source, the measurement owner, and the check-in cadence.
Send the finalized OKRs to all stakeholders who reviewed them, confirming that the feedback loop is closed. This artifact is now the reference document for check-ins and end-of-cycle scoring.
Tip: Store finalized key results in a location that is not editable by the team without a visible change log. This prevents quiet mid-cycle target adjustments that undermine accountability. If a key result genuinely needs to change, do it explicitly in a check-in and document the reason.
Examples
Example: B2B SaaS Product Team, 12-Person Startup
A product team at an early-stage B2B SaaS company (Series A, 12 people) sets the quarterly objective: "Make our onboarding experience so good that new users succeed without hand-holding." The team has access to Mixpanel for product analytics, Intercom for support data, and a simple NPS survey. They need to write key results that prove onboarding is genuinely improving, not just that features were shipped.
The team brainstorms 8 possible signals of onboarding success: activation rate, time to first value, onboarding completion rate, support ticket volume from new users, trial-to-paid conversion, NPS for first-week users, feature adoption breadth, and number of onboarding flows shipped. They filter for measurability and influence. "Number of onboarding flows shipped" is an output, so it is dropped. "NPS for first-week users" requires a new survey mechanism that would take 3 weeks to build, so it is deferred.
7 days (median, Mixpanel), onboarding support tickets are 47 per week (Intercom tag). 0 days, (3) Reduce onboarding-related support tickets from 47/week to 20/week. KR1 is a lagging indicator of overall onboarding success. KR2 is a leading indicator that gives early signal.
KR3 is a quality check that prevents the team from "improving" activation by making the threshold easier while users are still confused. The team is about 65% confident on KR1 and KR2, and 70% confident on KR3. They document data sources and assign the product manager as measurement owner with weekly pulls every Monday.
Example: Enterprise Marketing Team, 200-Person Company
A marketing team at a mid-size enterprise software company (200 employees, $30M ARR) sets the quarterly objective: "Become the go-to thought leader in our category for mid-market buyers." The team has access to Google Analytics, HubSpot, SEMrush, and a brand tracking survey run quarterly. They have two content marketers, a demand gen manager, and a part-time designer. The challenge is translating "thought leadership" into numbers.
The team lists 10 possible signals: organic traffic, branded search volume, share of voice in SEMrush, number of articles published, social media followers, backlinks from industry publications, speaking invitations received, podcast guest appearances, email subscriber growth, and content-sourced pipeline. They filter ruthlessly. "Speaking invitations" is not trackable in a system. "Articles published" is an output.
"Social followers" is a vanity metric disconnected from the objective. They pull baselines: organic traffic to blog is 34,000 monthly sessions (GA4, trailing 3 months), branded search volume is 2,400/month (SEMrush), share of voice is 12% (SEMrush, category keyword set of 450 terms), content-sourced pipeline is $180K/quarter (HubSpot attribution). They select four key results: (1) Increase organic blog traffic from 34,000 to 55,000 monthly sessions, (2) Grow branded search volume from 2,400 to 4,000 monthly searches, (3) Increase share of voice from 12% to 20% across tracked keyword set, (4) Grow content-sourced pipeline from $180K to $350K per quarter. KR1 and KR3 are leading indicators of thought leadership reach.
KR2 measures whether more people are actively seeking the brand. KR4 ties thought leadership to business impact, preventing a scenario where the team produces admired content that generates no leads. Confidence ranges from 55% (KR2, hardest to influence directly) to 70% (KR1). The demand gen manager owns weekly measurement for KR1 and KR4, while a content marketer pulls KR2 and KR3 monthly from SEMrush.
Example: Platform Engineering Team, Large Organization
A platform engineering team at a 1,500-person company sets the quarterly objective: "Make our internal developer platform reliable and fast enough that product teams never wait on infrastructure." The team runs Kubernetes clusters, a CI/CD pipeline, and an internal API gateway. They have Datadog for monitoring, PagerDuty for incidents, and Jira for tracking internal service requests. Six engineers report to the platform team lead.
The team brainstorms signals: deployment frequency, deployment failure rate, mean time to recovery (MTTR), platform uptime, CI/CD pipeline duration, time to provision a new service, internal satisfaction score, number of infrastructure-related incidents, and P0 incident count. They filter: "internal satisfaction score" requires a new survey (deferred). "Number of incidents" is too broad (includes incidents caused by product team code, not platform issues). 1% (Datadog).
5 days. KR1 is a committed key result (non-negotiable reliability target) and is scored pass/fail. KR2 is a developer productivity metric that gives daily signal. 2 days of waiting is the biggest complaint from product teams.
The team is 50% confident on KR3 (requires significant automation work), 65% on KR2, and 55% on KR1 (requires infrastructure hardening). Datadog dashboards are the data source for KR1 and KR2, with automated weekly reports. KR3 is measured via a Jira filter the team lead runs weekly.
Example: Small B2C Mobile App Team, 4-Person Team
A four-person team building a consumer fitness app sets the quarterly objective: "Build a habit loop so strong that users come back every day without push notification reminders." The team has Firebase Analytics, a simple Postgres database, and App Store Connect data. No dedicated data analyst. The founder, one engineer, one designer, and one part-time marketer make up the team.
The team lists signals: DAU/MAU ratio, Day-1/Day-7/Day-30 retention, streak length (consecutive days of app use), organic vs. notification-driven sessions, app store rating, and workout completion rate. They filter: "app store rating" is influenced by many factors beyond habit formation. "Organic vs.
notification-driven sessions" requires event tagging they have not built yet, but the engineer estimates it can be added in 2 days, so they keep it. 4 days. 4 days to 5 days. They initially considered a fourth key result about organic session percentage but decided against it because the event tagging work would consume a full sprint and they only have one engineer.
They made a team decision to add that metric next quarter once instrumentation is in place. KR1 is a leading indicator that gives weekly signal. KR2 is the lagging indicator that confirms the habit loop is real. KR3 is a user-facing metric that directly maps to the language of the objective ("come back every day").
The founder owns weekly measurement, pulling numbers from a Firebase dashboard every Monday morning. Confidence is about 60% across all three key results. 35 DAU/MAU would put them in the top quartile for fitness apps, which is ambitious but achievable if their new social features land well.
Best Practices
Write key results as outcomes, not outputs. The test is simple: could you achieve the key result and still fail the objective? If an output like "ship feature X" could be completed without the desired user behavior changing, it is a task, not a key result. Reframe it as the behavioral or metric change the output is supposed to produce.
Teams that write output-based key results consistently report that OKRs feel like a redundant task list rather than a strategic tool.
Include at least one leading indicator per objective. Lagging indicators like revenue, retention, or NPS only move late in the quarter. A leading indicator such as activation rate, weekly engagement frequency, or pipeline generated gives you a signal within the first 2-3 weeks. Without leading indicators, your first meaningful check-in happens too late to course-correct, and the team experiences the quarter as a pass/fail exam rather than an iterative process.
Cap key results at 3-5 per objective and aim for 3. Every additional key result adds measurement overhead and splits the team's attention. Research from companies that have scaled OKRs (including Google and Intel heritage) consistently points to 3 as the most effective number. Teams with more than 5 key results per objective tend to abandon the lower-priority ones by mid-quarter, which means those key results were never real commitments.
Always state the baseline alongside the target. "Increase retention to 45%" is ambiguous because the reader does not know if this represents a 2-point improvement or a 20-point improvement. "Increase retention from 25% to 45%" communicates the magnitude of ambition immediately. At scoring time, the baseline also enables proportional scoring: if you reach 35% on a 25%-to-45% target, you know you achieved 50% of the intended improvement, which translates to a 0.5 score.
Use the gaming test before finalizing any set of key results. Ask: "Could a rational but misaligned team hit all these numbers through a strategy that violates the spirit of the objective?" If yes, you have a gap. The most common version is a set of key results that all measure quantity without a balancing quality metric. For example, "Increase demo bookings from 50 to 150 per month" without a complementary key result about demo-to-close rate invites the team to book low-quality demos just to hit the number.
Define every metric precisely and link to its definition. "Engagement" can mean DAU, session length, actions per session, or a dozen other things depending on who you ask. Pin down the exact formula, the exact data source, and the exact cohort or segment. Write this definition once in a shared glossary and reference it from the key result.
This prevents mid-quarter debates about whether a metric was "really" measured correctly.
Set targets at 60-70% confidence of achievement. If the team is 90% sure they will hit the number, the target is not ambitious enough and the OKR adds no strategic value. If the team is less than 50% confident, the target risks being demoralizing and will likely be abandoned by mid-cycle. The 60-70% band creates the productive tension that drives creative problem-solving without inducing despair.
You can calibrate confidence by asking each team member to independently estimate their confidence level and averaging the results.
Separate "committed" key results from "aspirational" ones when necessary. 9%), while others represent stretch goals. Label them explicitly. 0.
0 gradient. 7 on a committed key result is a success or a failure.
Common Mistakes
Writing tasks or milestones instead of measurable outcomes
Correction
This is the single most common key result mistake. " These are outputs, not outcomes. The team can ship a redesigned checkout flow that nobody uses and still check the box. " Then make that metric the key result.
" The task goes on your project plan. The metric goes in your OKR. You can catch this pattern early by checking whether the key result contains a number. If it does not, it is almost certainly a task.
Choosing metrics the team cannot influence
Correction
This happens when teams pick important-sounding metrics like total company revenue or market share without having a direct lever to pull. The team works hard all quarter, but the metric moves (or does not) based on factors outside their control: macroeconomics, another team's launch, seasonality. The signal is a key result where the team cannot articulate a specific set of actions that would move the number. Fix it by choosing a metric that is one level closer to the team's actual work.
5M" for a product team, try "Increase upsell conversion rate from 8% to 14%" which the team can directly affect through product changes.
Setting targets without knowing the baseline
Correction
This manifests as key results like "Achieve 90% customer satisfaction" where nobody has measured current satisfaction. The team discovers mid-quarter that satisfaction is already at 88%, making the key result trivially easy, or at 45%, making it impossibly hard. Either outcome wastes the quarter. The root cause is usually impatience during OKR drafting, where setting the goal feels more strategic than pulling data.
Fix it by making baseline collection a mandatory prerequisite (Step 3 in this guide). If you genuinely cannot pull a baseline before the quarter starts, your first key result should be "Establish baseline measurement of [metric] by week 2" and your second should be the improvement target, set after the baseline is known.
Using binary key results for gradual changes
Correction
0, which means every check-in before completion shows zero progress. This makes mid-quarter reviews uninformative and demoralizing. It also creates a perverse incentive to rush completion just before the deadline. Fix it by decomposing the binary outcome into measurable milestones or percentages.
" Now you can track weekly progress and catch blockers early. Some key results are genuinely binary and time-bound ("Secure signed partnership agreement with X by March 31"), and that is fine for committed OKRs, but they should be the exception.
Bundling multiple metrics into a single key result
Correction
" At scoring time, what happens if signups increased 30%, churn stayed flat, and NPS improved 5 points? You cannot score this key result because it contains three independent metrics. The root cause is trying to keep the key result count low by cramming. Fix it by splitting compound key results into separate, individually scorable statements.
It is better to have four clean key results than two bloated ones. If splitting pushes you above 5 key results for one objective, it is a sign your objective is too broad and should be split into two objectives.
Sandbagging targets to guarantee a 1.0 score
Correction
Sandbagging looks like setting a target that the team is already on track to hit through momentum alone, without any new effort. The signal is a key result where the historical trendline already reaches the target, or where the team expresses near-certainty about hitting it. This happens when OKR scores are tied to performance reviews or compensation, incentivizing safe targets over ambitious ones. Fix it by separating OKR scores from performance evaluation (this is a structural fix for leadership).
At the team level, use the confidence calibration in Step 5: if the team is more than 80% confident before doing any new work, raise the target. 7 on average.
Other Skills in This Method
Running OKR Planning and Setting Sessions
How to facilitate collaborative quarterly OKR-setting workshops that generate buy-in, ensure ambition, and produce well-structured goal sets.
Setting OKR Cadence and Planning Cycles
How to determine the right OKR cycle length, manage quarterly vs annual rhythms, and coordinate timing across different organizational levels.
Avoiding Common OKR Mistakes and Anti-Patterns
How to identify and prevent pitfalls like sandbagging goals, confusing tasks with key results, setting too many OKRs, and tying OKRs directly to compensation.
Conducting OKR Check-Ins and Progress Reviews
How to run weekly or bi-weekly OKR check-ins and quarterly retrospectives to track progress, remove blockers, and maintain accountability.
Writing Effective OKR Objectives
How to craft qualitative, inspirational, and actionable objectives that motivate teams and provide clear strategic direction.
Aligning OKRs Across Teams and Organization Levels
How to cascade and align OKRs from company-level down through departments and individual contributors to ensure strategic coherence.
Scoring and Grading OKRs at End of Cycle
How to evaluate OKR progress using the 0.0-1.0 scoring scale, interpret results, and distinguish between committed and aspirational targets.
Frequently Asked Questions
How do I write key results when I don't have baseline data yet?
If the metric exists but you have not been tracking it, your first action is to instrument it immediately. If instrumentation takes less than a week, pull the baseline during the first week of the quarter and set your target retroactively. If instrumentation takes longer, make your first key result "Establish baseline measurement of [metric] by [date]" and set a second key result as a conditional improvement target. Do not guess at a baseline and set a target against the guess, because you will end up with a target that is either trivially easy or impossibly hard, and you will not know which until mid-quarter.
How many key results should I write per objective?
Three is the sweet spot for most teams. Two works for tightly scoped objectives. Five is the absolute maximum, and only appropriate when the objective spans multiple genuinely independent dimensions. More than five almost always means the objective is too broad and should be split into two objectives. The practical constraint is measurement overhead: each key result needs to be pulled and reviewed at every check-in, so every additional key result adds 5-10 minutes to your review meeting. If you have 4 objectives with 5 key results each, you are reviewing 20 metrics every check-in, which is unsustainable for most teams.
Should I write key results before or after writing effective objectives?
Write the objective first, but expect to revise it after drafting key results. The objective sets the direction, and key results test whether that direction is specific enough to measure. A common pattern is discovering during key result drafting that the objective is actually two objectives (because the key results cluster into two unrelated groups) or that the objective is too vague to generate any meaningful metrics. In both cases, go back and revise the objective. The sibling skill [writing effective objectives](/skills/writing-effective-objectives) covers this in detail. Think of it as an iterative loop, not a strict sequence.
How do I write key results for qualitative goals like 'improve team culture'?
Qualitative goals can still be measured, just through proxy metrics. For team culture, possible key results include: employee engagement survey score (e.g., increase from 3.6 to 4.2 on a 5-point scale), voluntary attrition rate (reduce from 18% to 10% annualized), internal transfer requests into the team (increase from 0 to 3 per quarter), or percentage of team members who report feeling psychologically safe in anonymous surveys. The key is finding the observable behavior or survey response that would change if the qualitative goal were achieved. If you cannot find any measurable proxy, the objective may be too abstract to drive action.
What's the difference between a key result and a KPI?
A KPI (Key Performance Indicator) is a metric you monitor continuously to understand business health. A key result is a time-bound improvement target on a specific metric. " Many key results are built on top of existing KPIs by adding a direction, baseline, and target. Not every KPI should be a key result, only the ones you are actively trying to move this cycle. Turning every KPI into a key result creates an unmanageable number of OKRs and dilutes focus.
How do I handle key results that depend on another team's work?
Dependencies are one of the most common reasons key results fail. If hitting your target requires another team to deliver something, you have three options. First, negotiate a shared key result that appears in both teams' OKRs, creating mutual accountability. This is the strongest approach and is covered in [aligning OKRs across teams](/skills/aligning-okrs-across-teams). Second, reframe your key result to measure only the part you control, and track the dependency as a risk in your check-ins. , "Secure commitment from Platform team for API v2 delivery by March 15"). Never set a key result where the team doing the work has no control over the outcome.
Why does my key result scoring keep producing 1.0 every quarter?
0 scores are the hallmark of sandbagged targets. If a team hits 100% of its key results every quarter, the targets are not ambitious enough to drive real improvement. 7. This means teams are stretching beyond what is comfortable and sometimes falling short, which is by design. The fix is to raise targets until the team feels 60-70% confident of hitting them, not 90-100%. 0 scores will be met with raised eyebrows, not applause. See [scoring and grading OKRs](/skills/scoring-and-grading-okrs) for calibration techniques.