OKRs in product management work when the objective names a business outcome and each key result is a number the team can move, reviewed on a fixed schedule. They fail when the key results are a list of features with ship dates. At that point the OKR is a roadmap with a new heading, and nobody learns whether the work mattered.
In December 2018, BetterLesson set one number for the following year: grow revenue from $5M to $9M. I ran the three-sprint product and go-to-market strategy process that got the company from that number to a plan, starting with a kickoff on December 13 and ending at the company meeting on January 16. When it was over, 11 teams had each set six-month KPIs against that single target.
They were called KPIs, not OKRs. The label mattered less than two other choices: one company number at the top, and a quarterly review where every team had to walk through its number in front of the CEO and its peers. A product team can have a perfect OKR template and still be missing both.
What are OKRs in product management?
OKRs in product management are a goal format: an objective that states the change the product should create, and two to four key results that measure whether it happened. A good product key result is a customer or business number. A feature, a launch, or a deadline is a task, and tasks belong on the roadmap.
The format came out of Intel and reached most of the tech industry through John Doerr, who brought it to Google in 1999 and wrote it up in Measure What Matters in 2018. The objective says where you are going. The key results say how you will know you got there. Nothing in the format tells you what to build, and that gap is on purpose. The team is supposed to fill it during the quarter, as it learns which bets move the number.
That is where product OKRs go wrong. The gap gets filled before the quarter starts.
Why do most product OKRs turn into a roadmap?
Most product OKRs turn into a roadmap because the OKR process gets added on top of a planning process that already decided what to build. The team writes the roadmap first, then translates each item into a key result so the template is complete.
Marty Cagan and Felipe Castro describe this in their March 2025 SVPG essay, Outcomes Are Hard. Countless companies, they write, "thought that they could layer in the OKR technique on top of their existing, output-based product roadmap processes," and that mistake is what fueled the backlash against OKRs. The technique was built for teams that own a problem. Laid over teams that own a backlog, it becomes paperwork.
You can see it in the wording. Take a key result like "Launch the redesigned onboarding flow by June 30." It has a date, so it looks measurable. It is binary, so it looks clean. And it scores 100 percent the day the flow ships, even if activation drops the next week. The team gets graded on delivery, which is what the roadmap already graded it on.
Teams write these because a feature key result is safe. Shipping is mostly in their control. A number like activation or retention is not, and a team that misses a number in a public review feels exposed. When a team's standing depends on showing green, it writes key results it can guarantee. That is an incentive problem before it is a goal-setting problem, and misaligned incentives are almost always behind misaligned teams.
How do you tell a real key result from a feature list?
Ask what would be true about a customer or the business if the work succeeded, then ask whether the team could hit the key result while that thing stayed false. If it could, the key result is a task.
A few checks catch most of the disguised ones.
| Check | Roadmap in disguise | Real key result |
|---|---|---|
| What it names | A feature and a date | A number and a target |
| When it is done | The day it ships | When the number moves |
| Can it be hit while customers ignore the work? | Yes | No |
| What a miss teaches | Engineering ran late | The bet did not work, so change the bet |
| Who picks the features | Decided before the quarter | The team, during the quarter |
The third row does most of the work. A key result that can be hit while customers ignore the feature is measuring the team's effort, and effort is already visible in the sprint board.
Picking the number is the hard part, and it is political. At EverQuote the choice between total leads and qualified leads decided which teams' work counted as progress, which I wrote about in the north star metric workshop. Key results carry the same politics one level down. The test I apply is the same one I use for key product metrics: a number worth managing is expensive to move dishonestly. Traffic you can buy is a weak key result. Qualified leads, repeat purchases, or paid conversions from a cohort are strong ones.
This also settles the OKR vs KPI question that sits under a lot of product OKR confusion. A KPI is a number you watch. A key result is a KPI you have committed to move by a date. BetterLesson's six-month KPIs worked as key results: each was a number with a six-month horizon, set against the $9M.
A feature with a ship date is a task, and tasks belong on the roadmap.
What does a goal system that works look like?
A goal system that works has one company number at the top, team numbers that roll up to it, and a fixed review where those numbers get discussed. The template is the least important part.
The BetterLesson target was $5M to $9M, which is 80 percent growth in a year. A target that size does not fit inside a feature list. No one can lay out twelve months of features and show, on paper, that they add up to $4M of new revenue. So the conversation has to start from the number and work down: which teams can move which part of it, and what each team will measure along the way. That is what the three sprints were for, and the work ended with 11 teams setting six-month KPIs.
Six months was the horizon for those KPIs. It is long enough for a team to try a bet, read the number, and try a different bet before the half closes. A quarter can be too short for a product change to show up in revenue, and a year is long enough to hide a bad bet. The review cadence closes that gap: six-month targets, checked every quarter.
BetterLesson has always been a useful case for me, going back to what BetterLesson taught me about ed-tech marketplaces. In a two-sided business the number you pick decides which side gets the investment, which is another reason a feature list cannot stand in for a goal.
The label matters less than the number on top and the meeting where someone has to explain it.
How should a product team review OKRs each quarter?
Review product OKRs in a meeting built for discussion rather than presentation, on a fixed clock, with the number shown first. The format I defined with BetterLesson's CEO gave each of six teams a seven-minute walkthrough and thirteen minutes of discussion.
Six teams at 20 minutes each is a two-hour meeting. Across the meeting that is 42 minutes of walkthrough and 78 minutes of discussion. Nearly two-thirds of every slot belonged to the room, not the presenter. The walkthrough is the part teams prepare most and the part least worth hearing, because the numbers are already on the page. The discussion is where someone asks why a number moved, whether the bet behind it still holds, and what the team will stop doing.
The same principle runs through the best review format I have worked in. At TripAdvisor, presenters in the product review meeting had four minutes, and the rest of the time belonged to the questions. A short, fixed presentation slot tells everyone that the point of the meeting is the questions.
The clock also protects the format from the roadmap. When a team has seven minutes, it cannot spend them walking through every feature it shipped. It has to lead with the number and say whether it moved. A team whose key results are features has nothing to say in that slot except "we shipped it," and the room notices.
Key results also need somewhere to come from. Teams that set OKRs without a product strategy above them drift back to features the first time a quarter gets hard, because a feature is the only thing left to promise. The company number gives the strategy a target, and the review checks it every quarter.
What should change in your next OKR cycle?
Rewrite every key result that names a feature as the number that feature is supposed to move, and put a review on the calendar before the quarter starts.
Start with the sheet you already have. Circle every key result that could be marked done on a ship date. For each one, ask what customer behavior or business number the feature was supposed to change, and write that down instead. Move the feature to the roadmap, where it was all along. Then book the quarterly review with a fixed clock per team, and make the walkthrough shorter than the discussion.
A product OKR is a promise about a number, made in front of your peers, that you will have to explain in 90 days. Everything else on the page is a guess about how to keep it.
