Supporting an Objective Doesn't Mean Copying Its Metric

I’ve worked at places where the OKRs weren’t aligned, and places where they weren’t visible at all. Both end the same way. Teams do good work, hit their own targets, and nobody can say whether the business moved because of it.

At one company I worked for, we didn’t have OKRs. Then we started writing them. Early on, I talked with my boss about strategic alignment: objectives should cascade, so that every team’s work traces up to something the business actually needs. The next year, that’s how we ran them.

On my product team, I made sure it held all the way down. Each person’s OKRs tied up to the product OKRs, and the product OKRs tied up to the business. The point wasn’t compliance. It was that the people doing the work could see how it helped the business move the needle, and feel like part of something larger.

There’s a name for that. Line of sight.

What line of sight actually requires

Roman Pichler recently wrote about the same disconnect from the other direction in Connecting Product Outcomes to Business Strategy. His argument is that products drift away from the business strategy, and teams can hit their internal targets while the numbers the business cares about stay flat. His fix is a Strategy Stack, where business, portfolio, and product strategies each produce their own objectives, and higher-level goals direct the ones beneath them.

I agree with the stack. But I’ve been writing OKRs for more than seven years, mostly from the PM seat, and there’s a mistake that happens right at the handoff from objective to PRD.

The trap: copying the key result

When a feature is tied to an OKR, the tempting move is to copy the key result into the PRD as the feature’s success metric. It looks aligned. It can leave the team unable to tell whether the feature worked.

Say a tutoring company has a key result to increase district renewals. The product team builds self-booking so students can schedule sessions without going through an administrator. District renewal matters, but it’s a poor measure of whether self-booking succeeds. Renewals happen months later, and they depend on price, relationships, student outcomes, and the district’s budget.

The team needs to measure what the feature can change sooner: Can students complete a booking? Do those bookings turn into attended sessions? The hypothesis connecting those measures to the key result is: If self-booking helps more students attend tutoring consistently, districts will see more value in the program and be more likely to renew.

That hypothesis could be wrong. Booking completion might improve while attendance stays flat. Attendance might improve without affecting renewals. Those are useful findings, but you’d miss them if “district renewal rate” were the only success metric on the PRD.

The feature supports the key result. It doesn’t have to borrow the key result’s metric to prove it.

What to write instead

Line of sight lives in the connection between the two metrics, and that connection is a hypothesis: if this metric moves, that objective should move with it. Most PRDs never write it down. It deserves one plain sentence.

Then add something I’ve learned to put on every PRD and epic template: how you’ll measure it. Name the actual tool. And if there’s a gap, where you can’t measure the metric with what you have today, say so.

A success metric with no way to measure it is a TBD dressed up as a commitment. Naming the gap is useful. It tells you exactly where you need more feedback.

The same applies when the objective itself is missing. If you can’t find the OKR your PRD is supposed to serve, don’t invent one to fill the slot. Flag it. That’s a question for leadership, and it’s better asked in the PRD than discovered at quarter end.

Where AI fits

This is a good job for AI, with one boundary. It can’t tell you what your strategy is. It can pressure-test whether your story holds together.

Here’s the prompt I’d start with:

I'm going to give you a business or department objective, the key result
tied to it, and the success metric from my PRD.

Before evaluating anything, ask me clarifying questions about anything
missing or vague. Then wait for my answers.

Once I answer:
1. State the hypothesis connecting my PRD metric to the key result, in
   one sentence.
2. Challenge it. What has to be true for the PRD metric to move the key
   result? Where could the PRD metric move while the key result doesn't?
3. For each metric, ask me what tool measures it. If I don't have one,
   flag it as a measurement gap. Don't assume one exists.

Rules:
- If the objective or key result is missing, flag it as an open question.
  Do not invent one.
- Don't evaluate whether the bet is worth making. Only whether the line
  of sight holds.

Objective:
Key result:
PRD success metric:

The value is in the challenge. A hypothesis that sounds plausible and one that holds up are not the same thing, and the model is good at finding the step you skipped. Whether the bet is worth making is still your call.

The part frameworks can’t do for you

Frameworks help, and Pichler’s is a good one. But line of sight gets built or lost one PRD at a time: in whether the metric belongs to the feature, whether the connection upward is written down, and whether you’re honest about what you can’t measure yet.

When those three are in place, the people doing the work can see where it goes. That’s what I wanted for my team. Not a tidier OKR document, but the ability to look at their own work and see the business move because of it.