Reusing Existing KPIs as Key Results (and When Not To)
Almost every team setting OKRs for the first time hits the same debate. Someone points out that the marketing dashboard already tracks lead conversion rate, so why not just use that number as a Key Result instead of inventing something new? Someone else pushes back, arguing that a Key Result has to be OKR-specific and that reusing an existing KPI is somehow cheating. Both instincts have a point, and the right answer depends on what the metric is actually measuring and why it's tracked in the first place.
The Case for Reusing an Existing KPI
If a metric already exists, is already trusted by the people who look at it, and genuinely reflects the outcome your Objective is chasing, reusing it as a Key Result is usually the right call. There's no new dashboard to build, no new instrumentation to add, and no argument later about whether the number is accurate, because the team has already been living with it. It also means the metric doesn't disappear when the OKR cycle ends. A KPI that becomes a Key Result for one quarter can go right back to being a normal departmental KPI afterward, still tracked, still useful, without anyone having to decide what to do with a one-off metric nobody maintains outside the OKR tool. Preferring measurements with working infrastructure and historical data behind them also makes the Key Result easier to trust: you can see the trend line before the quarter even starts, which is exactly the kind of grounded target-setting Harvard Business Review recommends when it comes to setting realistic, evidence-based goals rather than arbitrary ones.
A Good Example of Reuse
A support team's Objective is "Make customers feel confident during their first 30 days." The team already tracks first-response time on every ticket, a KPI that's been reported weekly for two years and that everyone on the team trusts. First-response time genuinely reflects how confident a new customer feels, a slow first reply is one of the most common reasons early customers churn. Reusing it as the Key Result, "Reduce average first-response time from 6 hours to 2 hours," costs nothing to set up and carries two years of baseline data the team can use to set a realistic target.
When Reusing a KPI Is the Wrong Move
Not every existing number deserves a seat at the OKR table. Two warning signs matter most. First, a KPI is tracked because it's easy to pull, not because it reflects the ambition of the Objective. Just because a number lives in a report already doesn't mean it measures what the Objective is actually trying to achieve, always check whether a candidate Key Result truly moves the Objective forward before adopting it. Second, some KPIs are lagging or steady-state operational numbers that nobody expects to move meaningfully this quarter, things like server uptime sitting at 99.9% for years, or headcount in a stable department. Numbers like that belong in regular reporting, not in an OKR cycle that's supposed to track stretch and change.
An Example That Looks Convenient but Is the Wrong Fit
A product team's Objective is "Deliver a step-change improvement in user experience." Someone suggests reusing the existing "number of support tickets closed" KPI as the Key Result, since it's already tracked weekly and easy to report. On the surface it looks efficient. In practice, tickets closed is mostly a measure of support team throughput, not user experience, and it's already sitting at a stable, predictable level that isn't expected to shift regardless of any product changes. Using it as a Key Result would let the team hit their number without moving the thing the Objective actually cares about, like task completion rate or user-reported friction. The convenient metric and the ambitious Objective simply don't match, and forcing them together produces a Key Result that looks measured but doesn't measure anything meaningful for the goal.
How to Decide
Before reusing an existing KPI as a Key Result, ask two questions. Does this number genuinely reflect the outcome the Objective is chasing, or is it just the easiest thing to pull into a report? And is this number expected to move meaningfully this cycle, or is it a steady operational baseline that stays roughly flat regardless of what the team does? If the answer to the first question is yes and the second is "yes, it should move," reuse it and save the setup time. If either answer points the other way, write a new, purpose-built Key Result instead, and leave the KPI where it already lives.