How to set and achieve product goals using objectives and key results (OKRs)

Objectives and key results (OKRs) link your plans with measurable outcomes.

You've probably used them to think about your professional goals on an individual level, but there are product-level OKRs as well. Unlike planning frameworks, they separate the outcome you're aiming from from the activities you think will get you there.

An objective describes the change you're trying to produce for users or the business. Key results are the measurable signals – two to four of them – that tell you whether the change is actually happening.

Done honestly, the format forces a product team to admit what success looks like in numbers before any work starts, which is exactly why so many organizations quietly soften them into status updates.

Poorly written OKRs aren't the culprit. What tends to happen is this: Leadership isn't prepared to keep funding work that misses the mark. So key results get rewritten mid-cycle, scoring gets softened, ambition drops, and a year later the meeting format is just another quarterly status update.

Why OKRs work for product goals

OKR stands for Objectives and Key Results. Objectives describe the outcome you want. Key results are the measurable signals that tell you whether you're reaching it.

Andrew Grove introduced the method at Intel in the 1970s. John Doerr brought it to Google in the early 2000s. Today it's standard practice at LinkedIn, Intel, and countless other workplaces.

The Google re:Work OKR guide gives a detailed overview of how Google applies the method. John Doerr's book Measure What Matters covers the full framework.

Dick Costolo, former CEO of Twitter, described what he took from Google: "OKRs are a great way to help everyone in the company understand what's important and how you're going to measure what's important. It's essentially a great way to communicate strategy and how you're going to measure strategy. As you grow a company, the single hardest thing to scale is communication. OKRs are a great way to make sure everyone understands how you're going to measure success."

OKRs are useful for defining, tracking, and measuring product goal success. They're not a shortcut, though. Doerr's description of well-deployed OKRs: "a vaccine against fuzzy thinking – and fuzzy execution." The vaccine only works when the culture is ready for it.

How to set product OKRs

The process: start with your product strategy and your priorities for the quarter. Write 1-3 OKRs that describe outcomes, not work plans. Define 2-4 key results per objective. Align OKRs across teams, then publish them somewhere visible. Review weekly. Score quarterly.

What makes a good objective

A good objective is owned by the team – it can't depend on other teams to be delivered unless there's been explicit cross-team agreement on shared priorities. It's deadline-bound, whether monthly or quarterly, with a timeframe that's realistic for the scope of work. It's aspirational – requiring real effort and creative thinking to achieve.

And it's aligned with product strategy and customer value. If an objective doesn't trace back to user outcomes or business direction, it probably doesn't belong in the set.

What makes an effective key result

A good key result is quantifiable – each one should have a hard number or target. If you can't score it, it's not a key result.

It's explicit: naming the specific metric, the baseline, and the target, with no room for interpretation.

It's outcome-focused, not output-driven. "Launch feature X" is a task. "Increase daily active users by 20%" is a key result.

And it's tracked in a shared dashboard. OKR monitoring tools like Weekdone, Lattice, and Betterworks support ongoing tracking across multiple teams and stakeholders.

A concrete example of a well-formed OKR:

Objective: Triple average weekly sessions on mobile by the end of February

Key results:

• QA all mobile functions (define acceptance criteria and completion rate)

• Improve loading time by 40%

• Add one new integration to the mobile version

Common focus areas for product OKRs include activation and onboarding outcomes, retention and engagement, revenue and monetization, performance and reliability, customer satisfaction, and delivery predictability.

How OKRs benefit product teams

OKRs create shared language around what success looks like. That makes alignment easier – everyone understands which product goals they're working toward and how their individual work connects.

It sharpens focus: Breaking down strategy into objectives and key results eliminates work on initiatives that don't contribute to the product goal, what Doerr calls "fuzzy thinking." And it creates accountability. When key results are visible and scored, there's no ambiguity about whether progress is being made.

A key result isn't a task. It's a tangible, observable outcome with a hard figure that speaks for itself. When you hit a key result, you know it. That's the point.

Common OKR pitfalls and how to avoid them

Too many OKRs

OKRs should be your top priorities for the quarter. Not a comprehensive list of everything the team is working on. Adding more OKRs dilutes focus and reduces the accountability each one carries. Keep the set small enough that each objective feels genuinely important.

Confusing key results with tasks

Tasks are how you achieve objectives. Key results measure whether the objective is being achieved.

If your key results look like a project plan – "complete user research," "hold three team workshops," "finalize feature spec" – rewrite them as measurable outcomes. "Increase 30-day retention from 42% to 55%" is a key result. "Complete retention analysis" is not. This is the most common mistake teams make with OKRs, and it undermines the entire framework.

Keeping OKRs siloed

OKRs set in isolation create redundancy, misalignment, and confusion about what counts. When each team defines its own OKRs without visibility into what other teams are doing, multiple groups end up pursuing the same objectives independently – or worse, objectives that work against each other. Publishing OKRs company-wide and reviewing cross-team alignment before finalizing prevents this.

Low-effort key results

It's all too common for key results to be written to match an objective without providing real measurability. And that's consequential. If key results can't be scored, they can't be managed – and teams end up with OKRs that feel complete but don't actually tell you whether the product strategy is working.

Qualitative key results are the most common version of this problem.

Why OKRs don't replace a product roadmap

A product roadmap is a communication tool that conveys strategic intent and the sequencing of delivery work. OKRs define the outcomes that delivery work should produce. Different jobs.

OKRs set the destination. The roadmap organizes the journey. Roadmap items are the features, initiatives, and requirements that contribute to achieving the objectives in your OKRs and the broader product goals. The roadmap bridges strategy and tactics by making it visible which initiatives support which outcomes.

For teams at a growth stage – lots of feature development, heavy customer demand, multiple competing priorities – the roadmap is what brings alignment to the full set of OKRs across the organization. You don't have to choose between them. They work better together.

An OKR template helps teams maintain consistent format and scoring across cycles. Tempo's Strategic Roadmaps integrates with Jira to keep roadmap priorities connected to in-progress delivery work – so OKRs don't become a separate planning artifact that drifts from what teams are actually doing.

See also: KPIs.