Linked Better Practices over Stacked Best Practices

​Dear Reader,​

During my last webinar on Connect Strategy, Goals, and Discovery with Progress Wheel, I asked people which part of their work is most prone to Alibi Progress. Almost everyone who chimed in named OKRs.

And that's because many OKR cycles start the same way for teams: Someone opens a spreadsheet, fills in three to five semi-random metrics, and picks a value that isn't too intimidating, but matches the forecast. Metrics include (but aren't limited to) uptime, retention, Customer Effort Score, support ticket volume, or new registrations.

These can be important metrics. But they're not Key Results. They're health metrics. You care about them, but not enough to change your priorities. They'll move or stay stable, whether or not you dedicate an OKR to them.

I ran two OKR workshops recently where the same pattern showed up. In one, a team had put "number of forms submitted" as a Key Result.

But forms got submitted by default through the continued rollout of a new workflow. Nobody has to do anything special for that number to keep going up.

In the other workshop, system health metrics that were already stable got promoted to Key Results. Not because they needed focused effort, but because they were easy to measure and safe to commit to.

This is what I call the risk of Alibi Progress. You go through the motions, you fill in the template. And at the end of the quarter, you "hit your OKRs," but nothing actually changed - neither for users, nor the business.

A health metric is reactive and tells you the system is working.

A Key Result is proactive and describes a change you're actively trying to create.

This is the acid test I keep coming back to with teams:

"If we did nothing special this quarter (no new initiative, no focused Discovery effort), would this number still move in roughly the same direction?" If yes, it's a health metric, which means it'll look great on a monitoring dashboard. But don't put it in an OKR.

When safe metrics fill your OKR slots, the actually ambitious goals don't make it in. In the forms example, the real question wasn't how many forms get submitted. The question was whether non-power users would see a shorter time to receive insights with a new workflow. That's a behavior change. That's harder to measure, less certain to hit, and therefore the actual Key Result.

I think of it like a buffet. Your metrics are everything on the table. OKRs are what you deliberately pick from that buffet because you want to make a proactive effort to change it in the next cycle. If you just load your plate with what's already in front of you, you'll feel full. But you won't have eaten anything new.

So for every proposed Key Result, ask two questions:

Would this happen without the OKR? If yes, it's monitoring, not a goal.

Does achieving this require us to do something we're not already doing? If no, same thing. Dashboard, not OKR.

Real Key Results are harder to hit, but that's the point. They describe the change you don't yet know how to make. And that's exactly what makes them worth committing to.

Thank you for Practicing Product,

​Tim​

If you consume one thing this week, make it this...

You Don’t Need Another Prioritization Framework: Just These 4 Components ​ Read it here

Who is Tim Herbig?

As a Product Management Coach, I guide Product Teams to measure the real progress of their evidence-informed decisions.

I focus on better practices to connect the dots of Product Strategy, Product OKRs, and Product Discovery.