A Product OKR Check-In Template That Forces You to Prove Shipped Work Moved the Metric

I've run product OKRs for about a decade, and the check-in is where most product teams quietly lie to themselves. They report what shipped, not what moved. This is the template I use to stop that. It's built for product specifically: activation and retention trends, the link between a release and the number it was supposed to change, and the uncomfortable question of which feature to kill.

By Max Bondarenko · Last updated June 2026

The template, up front

No buildup. Here's the whole thing. A product OKR check-in is five questions, answered weekly, in writing, before anyone gets on a call. The trick isn't the questions. It's that four of the five are about the metric and only one is about what you built. Most product teams have that ratio backwards, and that's exactly why their OKRs drift into a feature checklist by week 6.

The five questions, every week

01Where is the metric now versus the target? State the baseline, this week's number, and the goal (e.g. activation 38% to 60%, currently 44%).
02Which shipped thing this cycle was supposed to move it, and did the number actually move after it landed?
03Is the trend bending the right way, or are we flat? Look at activation and D30 retention as a curve, not a single dot.
04What did we ship that hasn't touched the metric at all, and are we ready to kill it or cut its scope?
05What's the one bet for next week, and which number will tell us in 7 to 10 days whether it worked?

Why each question is there

Question one exists because product teams love to report motion. "We shipped the new onboarding flow" feels like progress. It isn't, until activation moves. So the check-in opens with the number and the gap, every single week, in the same format: baseline, current, target. If activation started at 38% and the cycle goal is 60%, I want to see we're at 44% this week and 41% last week. A number with no baseline is a vanity slide. A number with a baseline and a target is a status.

Question two is the spine of the whole thing, and it's the one people skip. Every shipped item has to name the metric it was supposed to move, and then you check whether it actually moved after the release date. This is where you catch the lie early. I once ran a team that spent a full cycle on a slick referral feature, beautifully built, and our check-in showed D30 retention dead flat: 22% baseline, 22% three weeks after launch, against a 35% target. Because we'd been honest in the weekly template, we revised the wrong target in week 4, not week 12. That's the entire value of a real check-in. A bad target caught in week 4 costs you a week. The same target caught at the end-of-quarter review costs you the quarter.

Question four is the one that makes the room uncomfortable, so I make it mandatory. Pet features are the silent killer of product OKRs. Someone fell in love with a build, it shipped, the metric didn't budge, and nobody wants to say so. The check-in forces it into the open every week: what did we ship that hasn't touched activation (38% to 60%) or D30 (22% to 35%), and are we killing it or cutting it down? If a feature has been live three weeks and the curve hasn't bent, that's not a "give it time" situation. That's a signal. Cut scope, pull resourcing, or kill it, and move the people to the bet that might actually move D30 from 22% to 35%.

Scoring: three states, one action each

I don't use 0.0 to 1.0 confidence scores in the weekly check-in. They invite fake precision and endless debate about whether something is a 0.6 or a 0.7. For product metrics I use three states, and every state has exactly one action attached. The state isn't a feeling about effort. It's about whether the trend is on pace to hit the target by end of cycle.

On track	The trend is bending toward target on schedule (activation moving 38% to 60% at a pace that lands by cycle end). Action: do nothing different. Protect the current bet and resist adding scope.
Behind	The metric is moving the right direction but too slow to hit target (D30 crept 22% to 26%, needs 35%). Action: name the single biggest lever and concentrate next week's work on it, drop a secondary task.
At risk	Flat or moving the wrong way three-plus weeks after a release meant to move it (activation stuck near 38% against a 60% target). Action: kill or rescope the feature that isn't working, and rewrite the bet for next week. Don't wait for the quarter review.

Product OKR check-in states and the single action each one demands

How to actually run it

Async by default. The five answers get written down, in the same doc, by the metric owner, before any meeting exists. If the whole thing lives in a 30-minute status call, you've built a theater, not a check-in. People perform for the room and the honest answer to question four never gets typed. Written first, talked about second.

Who attends the live part: only the people who own a metric and the one person who can reallocate resourcing. Not the whole product org. Keep it to 20 minutes, and only meet live in two cases, when something is At risk and a feature needs killing, or when two metrics are fighting each other and someone has to make a call. If everything's On track, skip the meeting entirely and just read the doc. A check-in you can skip when things are healthy is a check-in people will actually keep doing. The week I ran a team where nobody could remember the last status call we cancelled, I knew the system was broken.

Questions people actually ask

How is a product OKR check-in different from a regular weekly check-in?

A generic check-in asks "what did you do this week." A product OKR check-in asks "did the thing you shipped move activation (38% to 60%) or retention (22% to 35%)," which is a much harder question. The whole template is weighted toward the metric and its trend, with only one of five questions about output, so you can't hide behind a list of releases.

What product metrics belong in the check-in?

For most products it's an activation metric and a retention metric, tracked as trends with a baseline and target, like activation 38% to 60% and D30 22% to 35%. Pick one or two that you can actually move in a quarter. If you're tracking eight metrics weekly, none of them is a real key result, it's a dashboard.

How long after shipping should I expect a feature to move the metric?

For activation (say 38% to 60%), days to a week, because it hits new users immediately. For D30 retention (22% to 35%) you need a few weeks just to read a cohort, so I give it three weeks before I call it. If a feature meant to move activation hasn't done anything two to three weeks after launch, that's your signal to rescope or kill it, not to wait.

When is it fair to kill a feature instead of giving it more time?

When it's been live three-plus weeks, it was explicitly tied to a metric in the check-in (like activation 38% to 60%), and the curve hasn't bent. That's the bar. "Give it time" is the phrase that turns a one-week mistake into a one-quarter mistake, so I make the kill-or-keep call an explicit question every single week rather than a debate we have once at quarter end.

Stop running check-ins in a spreadsheet

Okiar is free during beta. Voice check-ins, AI projections, team health — live in minutes.

Start free →