OKRs: How to Set, Measure and Track Key Results

An OKR looks simple on paper: choose an objective, define a few measurable key results and review progress throughout the quarter. In practice, the framework asks teams to make several consequential choices — which outcomes deserve priority, what evidence will demonstrate progress, whether a goal is committed or aspirational, and how often to review and score it.

The measurement of OKRs has become significantly more challenging since the concept emerged in the 1970s. A modern team’s key results might depend on CRM records, business rules maintained by a data team and metrics defined differently across several business intelligence (BI) dashboards. When measurement draws from live, governed data, teams get fresher numbers based on consistent definitions. Review meetings can spend less time reconciling numbers and more time examining the trajectory of the goal, the factors influencing it and what to do next.

Objectives and key results (OKRs) are a goal-setting framework that pairs a qualitative objective with a small set of quantitative key results. The objective states what a team wants to achieve, while the key results specify the measurable outcomes that would demonstrate progress toward the objective.

For example:

Objective: Make onboarding easier for new customers.

Key results:

• Increase activation rate from 40% to 55% by the end of Q4.
• Reduce median time to first value from seven days to three days.
• Reduce onboarding-related support tickets per new customer by 20%.

The OKR framework grew out of work by Intel leader Andy Grove, who developed the management approach that evolved into modern OKRs. John Doerr learned the system at Intel and later introduced it to Google, helping popularize OKRs more broadly through Measure What Matters.

Doerr describes five benefits of effective OKR practice through the acronym F.A.C.T.S.: Focus, Alignment, Commitment, Tracking and Stretching. Focus limits attention to a small number of priorities; alignment connects goals across the organization; commitment establishes shared responsibility; tracking keeps progress visible throughout the cycle; and stretching encourages ambitious targets.

Organizations typically set OKRs on a recurring cadence, often quarterly, then review and score them throughout or at the end of the cycle. That rhythm separates OKRs from a static task list: the framework provides a continuing reference point for deciding where work is producing the intended outcome and where it’s falling short.

See how Thomson Reuters uses Cortex Analyst to build AI-powered analysis on enterprise data:

The two components of an OKR perform different jobs. An objective is a qualitative statement of intent. It should give the team a clear direction while leaving room for different ways of reaching it. “Deliver a smoother onboarding experience,” for example, describes the outcome the team wants without prescribing a particular feature, campaign or workflow.

A key result translates that direction into measurable evidence. Consider this key result that would demonstrate a smoother onboarding experience: “Reduce median time to first value from seven days to three days by the end of Q4.” The metric is median time to first value. Seven days is the baseline, three days is the target and the end of Q4 supplies the time boundary.

That structure also helps separate outcomes from outputs. “Ship five onboarding improvements” records activity. “Reduce time to first value from seven days to three days” measures the result the work is intended to produce.

Each key result names a measurable outcome, which means each also relies on a metric definition and a data source. The framework establishes what the team intends to measure, but the data behind the metric determines how confidently the team measures it.

Organizations often distinguish between committed and aspirational OKRs, a practice associated particularly with Google’s implementation of the framework.

• A committed OKR represents an outcome the team is expected to deliver within the cycle. Resources and priorities should reflect that expectation, and the target is generally treated as a 100% commitment.
• An aspirational OKR deliberately reaches further. These stretch goals carry more uncertainty, and partial achievement may still represent substantial progress. Google’s grading approach, for example, treats 0.7 to 1.0 as the green range for aspirational OKRs, while committed OKRs are expected to reach 1.0.

Labeling the type at the beginning of the cycle gives the eventual score useful context. A 0.7 against a highly ambitious expansion goal and a 0.7 against a required regulatory milestone represent very different outcomes.

Some organizations also separate strategic OKRs, which express higher-level or longer-horizon priorities, from operational or team OKRs that support them. Whatever terminology an organization adopts, the hierarchy should show how a team’s measurable outcomes connect to broader priorities.

OKRs and key performance indicators (KPIs) are closely related, which explains much of the confusion between them.

A KPI is an ongoing measure of performance. Monthly churn, gross margin, uptime, forecast accuracy and conversion rate might all remain on a dashboard quarter after quarter because the organization wants to monitor their health continuously.

An OKR specifies an objective with key outcomes the organization wants to produce during a defined period.

Take customer churn:

A KPI of monthly customer churn might be 5%. An OKR key result might include the same metric this way: Reduce monthly customer churn from 5% to 3% by the end of Q2.

The KPI supplies the measurement. The key result adds a baseline, target and deadline that describe the intended change.

Many key results therefore use existing KPIs, although that relationship isn’t required. A team might create a new metric for an initiative that has never been measured before. In either case, the key result needs an agreed-upon method of calculation and a reliable source for the underlying data.

KPIs can also serve as guardrails around an OKR. A product team pursuing rapid adoption, for example, might track support volume or customer satisfaction alongside its growth objective so that progress in one metric doesn’t hide deterioration in another.

A good OKR narrows the field of attention. If a team enters a quarter with 15 objectives, dozens of key results and no clear ordering among them, the framework isn’t being used effectively. Writing a useful set of OKRs starts with the following best practices.

Write objectives around outcomes

An objective should describe an outcome the team wants to produce. “Run three acquisition campaigns” describes planned work. “Increase qualified demand from target accounts” gives the team a result that several kinds of work might contribute toward. The objective doesn’t need a metric since the objective’s key results supply them.

Give every key result a baseline and target

Baselines also reveal the scale of the proposed change. Raising activation to 60% means something very different if the current rate is 58% vs. 35%.

Key results should also have specific targets. “Improve forecast accuracy” leaves too much unresolved. “Increase quarterly forecast accuracy from 72% to 85% by the end of Q4” establishes both the starting position and the expected result.

Assign one named owner

A key result often depends on work from several people, but responsibility for tracking it should remain clear. This person keeps the measurement visible and makes sure changes receive attention.

Pressure-test the measurement

Before committing to a key result, ask how its current value will be calculated during the cycle. Where does the data originate? How frequently does it refresh? Who owns the metric definition? Does the same label refer to the same calculation across dashboards and teams?

A key result that requires a new measurement pipeline isn’t necessarily a bad key result. The team simply needs to account for that work before the cycle starts.

The same test catches key results that are difficult to evaluate at all. “Improve brand trust,” for instance, needs a defined measurement approach before the team can determine what progress looks like.

OKRs take different forms across the organization because each team influences different business outcomes. The metrics might range from activation and retention to pipeline and forecast accuracy, but each key result should give the team a measurable way to connect its work to a broader objective.

Leadership

Objective: Become the category’s most trusted brand.

Possible key results:

• Increase net promoter score from X to Y
• Raise competitive win rate from X% to Y%
• Increase customer retention from X% to Y%

Product

Objective: Make onboarding easier for new customers.

Possible key results:

• Increase activation rate from X% to Y%
• Reduce median time to first value from X days to Y days
• Reduce onboarding support tickets per new customer from X to Y

Marketing

Objective: Build a more predictable demand engine.

Possible key results:

• Increase qualified pipeline from $X to $Y
• Raise opportunity conversion from X% to Y%
• Reduce cost per opportunity from $X to $Y

Sales and revenue operations

Objective: Improve confidence in the revenue forecast.

Possible key results:

• Increase forecast accuracy from X% to Y%
• Reduce median sales-cycle length from X days to Y days
• Increase pipeline coverage from X to Y

Many OKR programs score individual key results on a 0.0-to-1.0 scale, then use those results to assess the objective as a whole.

Suppose a key result aims to increase activation from 40% to 55%. If activation ends the cycle at 50%, the scoring method translates that progress into a standardized result so teams can review different KRs consistently.

The interpretation depends partly on the type of OKR. Google’s approach places aspirational scores from 0.7 to 1.0 in its green range, while committed OKRs are expected to reach 1.0. Consistently reaching 100% of highly aspirational goals could also indicate that the targets aren’t stretching the team very far.

The score is only one part of the end-of-cycle review, which should also look at what contributed to the result, which assumptions held up and what should change in the next cycle.

For example, a team that reached 0.6 might have encountered an incorrect assumption, an external dependency or a shift in business priorities. Another team with the same score might have started late or allowed the KR to drift out of daily work. The score alone can’t distinguish among those circumstances.

Finally, the quality of the score depends on the quality of the underlying measurement. A carefully designed 0.0-to-1.0 scale is of little value if the source metric can’t be trusted because it’s out of date or defined in conflicting ways.

OKRs are designed to operate as a recurring management cadence. Planning establishes the target, check-ins surface changes early and the retrospective turns the final result into input for the next cycle.

Set the OKRs

A typical quarterly cycle begins with drafting and aligning objectives, establishing key results and naming owners. At this stage, teams should confirm that each key result has a clear baseline, target and measurement source, since unresolved definitions tend to surface later during check-ins.

Review progress regularly

During the quarter, teams review progress weekly or biweekly, identify KRs that are slipping and adjust the work around them. Frequent check-ins give teams a chance to respond while there’s still time to influence the result. Rather than waiting until the end of the quarter to discover that a key result fell short, teams can investigate what’s driving any changes in a metric and adjust their work accordingly.

A useful check-in starts with the current value of each key result and then asks what changed, what’s blocking further movement and which actions deserve attention before the next review.

If the first part of every meeting goes toward collecting spreadsheet updates or reconciling conflicting figures, the cadence carries unnecessary administrative overhead. With current measurements available at the time of the meeting, the discussion can move more quickly to the trajectory of the goal and what to do next.

Score and run a retrospective

At the end of the cycle, teams score the results and review what shaped them. The score shows how much progress the team made toward the target, while the retrospective looks at what contributed to the result, which assumptions held up and what should change in the next cycle. This review should feed directly into the next round of planning.

Most OKR problems fall into a few recurring patterns, several of which surface only after execution starts.

• Too many OKRs: A long list weakens the prioritization the framework is supposed to create. Keep the active set small enough that each objective receives attention throughout the cycle.
• Outputs framed as outcomes: “Launch a new feature” records completion of work. A KR such as “Increase weekly adoption of the workflow from 22% to 35%” measures what happened after the feature reached users.
• Weak alignment: Team OKRs should connect visibly to company priorities rather than operating as an independent planning layer.
• Set-and-forget planning: Quarterly goals lose operational relevance when teams review them only during planning and closeout. Regular check-ins keep the metric in the decision cycle.
• Goals detached from daily work: A team needs some ability to influence its key results through the choices it makes during the quarter. Otherwise, the metric functions primarily as an observation.
• Gaming the score: Treating OKR attainment as a direct proxy for employee performance encourages safer targets and complicates the use of aspirational OKRs.
• Untrustworthy measurement: A manually copied or stale number, or a disputed definition wastes time on reconciliation tasks. This problem is easy to treat as an OKR-tooling issue, but it often starts further down the stack with metric definitions, data sources and governance.

Spreadsheets and dedicated OKR tools are often enough to record objectives, owners and scores. The challenge is keeping the measurement behind each key result current and consistent, particularly when that measurement depends on data from several systems.

Consider a KR to increase qualified-pipeline conversion from 18% to 24%. Teams need to be in agreement on which opportunities qualify, which stage transition counts as conversion, how reopened opportunities are handled and which dates determine inclusion in the reporting period. If those rules are implemented separately in a CRM report, BI dashboard and analyst query, each system might produce a different result while measuring the same KR.

Copying a value into a spreadsheet introduces another issue: the recorded score reflects the metric at the time someone entered it, rather than its current value.

Connecting a key result to live, governed data addresses both problems. The underlying data is managed and refreshed according to the organization’s requirements, while shared business logic establishes how the metric is calculated. The OKR view can then reference that measurement rather than maintaining a separate copy.

The flow looks roughly like this:

Source data → integration and transformation → governed metric definition → current metric value → OKR tracking and analysis

“Live” doesn’t necessarily mean real time. A quarterly revenue KR might need daily updates, while an operational metric has much lower latency requirements. What matters is that the measurement remains connected to its managed source and refreshes at a cadence appropriate to the decisions the team needs to make.

Governance applies consistent metric definitions, ownership, lineage and appropriate permissions to help teams understand what a number represents, where it came from and whether they should use it for a particular key result.

AI is beginning to influence several parts of goal management, including work that involves drafting, monitoring and summarizing OKRs.

Improve OKRs during planning

During goal setting, AI-assisted tools can review draft objectives and key results for structural problems such as vague language, missing baselines, unrealistic targets or activities presented as outcomes.

That kind of review is most useful as a quality check rather than a substitute for strategic judgment. An AI system might flag that “launch three onboarding improvements” describes output, for example, while the team still has to decide which customer outcome should replace it and what level of improvement is realistic.

Monitor progress during the cycle

Once the quarter is underway, AI has a different role: helping teams identify changes that deserve attention. When key results are connected to current metrics, an analytical or agentic system can compare progress with the target, surface an unexpected shift and gather supporting information about what changed. A sales KR that starts falling behind, for instance, could trigger analysis by region, segment or pipeline stage before the next scheduled review.

That moves some of the monitoring work out of manual status preparation. Rather than waiting for someone to notice a problem in a spreadsheet, teams receive earlier signals that warrant investigation.

Prepare for reviews and retrospectives

At review time, AI-assisted analysis can help assemble the context behind a score. A system might summarize how a metric changed during the quarter, identify periods of acceleration or decline, surface related KPIs and draft a pre-read for the team to review before a quarterly business review.

Natural-language interfaces give leaders another way to investigate the result. Questions such as “What contributed most to the decline in activation this month?” or “Which customer segments are furthest from the Q4 target?” can lead directly into analysis when the relevant metrics and business concepts are available to the system.

Across all three stages, the same constraint applies: AI inherits the quality of the measurements it uses. If a key result relies on inconsistent definitions, stale values or poorly governed source data, faster analysis simply reproduces those weaknesses at greater speed. Live, governed data and shared metric definitions give AI-assisted and agentic workflows a more reliable basis for interpreting progress.

Organizations can use Snowflake to bring together data from operational systems, apply consistent business logic and supply governed metrics for BI, analytics and AI workflows. For OKR tracking, a key result can reference the same metric definition used elsewhere instead of relying on a separate calculation maintained specifically for the OKR process.

Snowflake Semantic Views are schema-level objects for defining business concepts, including metrics, dimensions and relationships, over physical data. Centralizing that logic helps reduce duplicated metric definitions across queries and analytical tools, while the resulting Semantic Views can be queried directly with SQL and used by Cortex Analyst.

For a qualified-pipeline KR, for example, a Semantic View could define the metric and the relationships required to calculate it according to the organization’s agreed business rules. The Semantic View Editor in Snowsight provides a visual interface for creating and editing those definitions, including logical tables, dimensions, facts, metrics and relationships.

Cortex Analyst uses Semantic Views to interpret natural-language questions and generate SQL against the associated data. During an OKR review, a team could use that semantic context to investigate a change in a key-result metric — for example, by looking at performance across regions, products or customer segments represented in the view.

Because Semantic Views are Snowflake schema-level objects, they also integrate with Snowflake’s privilege system and metadata catalog. This keeps metric definitions, access controls and the underlying data within the same governed environment, while allowing the same business concepts to support SQL, BI and AI-assisted analysis.

For OKR programs, the benefit is specific: teams can measure a key result using the same governed definitions already used elsewhere in the organization, rather than maintaining separate formulas and periodically copying their outputs into a status report.

OKRs give teams a disciplined way to choose priorities, define measurable outcomes and revisit them throughout a planning cycle. The framework works best when that measurement discipline extends into the data behind each key result.

For a small team, the supporting system may be straightforward. As OKRs span functions, analytical tools and AI interfaces, teams need shared metric definitions and current data that provide a more consistent basis for scoring progress and deciding where to act.