AI-translated. Read the original in Korean
Are Our Team’s OKRs Working?
CPO

Read John Doerr's book on OKRs, or another well-known book on the subject, and they can seem easy to apply. You might even wonder whether the concepts of Objectives and Key Results really warrant an entire book. But once you earnestly put what you have learned into practice, a familiar question tends to surface: Are we managing our OKRs well?
Let's set Objectives aside for a moment and focus on Key Results. There are two criteria that deserve particular attention when defining them.
- A Key Result must be measurable.
- Achieving all the Key Results should mean that the corresponding Objective has been achieved.
An example that does not work
With those criteria in mind, consider these KRs for a mission team.
- Objective — Build a service people use every day.
- Key Results
- Build a daily check-in feature.
- Implement regular push notifications.
They do not quite seem to meet the criteria above.
You might ask whether “build a daily check-in feature” is measurable. Certainly: it could be a 1 or a 0, depending on whether users can actually use the feature. But if it is not finished by the end of the quarter, the entry often ends up looking like this: “We haven't launched yet, but the feature is mostly implemented. We only have QA and deployment preparation left, so let's call it 0.8.” What does that even mean?
The second criterion is shaky too. Does having those two features make ours a service that people use every day? Are those features the only solution? Should we avoid building something else based on insights gained halfway through the quarter? What happens if we build both features and users still do not come back daily?
Our OKRs did not look particularly healthy.
What should we do?
Please bear with this deliberately rough example.
- Objective — Build a service people use every day.
- Key Results
- Reduce the average interval between return visits from 48 hours to 24 hours.
- Keep the monthly decline in retention rate at 2% or less.
Leaving aside how realistic these targets are, these Key Results seem closer to the criteria for OKRs. They are measurable, and achieving all of them would arguably mean we had made meaningful progress toward the Objective. Yet writing OKRs this way can leave us feeling that something is missing.
Teams feel pressure to include what they are going to do in their OKRs. One reason we list the quarter's projects under Key Results is that we use OKRs to share our plans. The value of “sharing” is sometimes dismissed because “reporting” carries negative connotations, but sharing information is certainly one of the purposes of OKRs.
Then write that down too
As I was wrestling with this, Buzzvil's agile coach, Imamu, gave me a clear answer: “That's why teams sometimes add a section for the tasks they plan to carry out during the quarter.”
- Objective — Build a service people use every day.
- Key Results
- Reduce the average interval between return visits from 48 hours to 24 hours.
- Keep the monthly decline in retention rate at 2% or less.
- Tasks
- Launch daily check-in.
- Send regular push notifications.
- Measure the interval between return visits.
This structure makes the team's goal and measures of success clear, includes the work we intend to do to get there, and gives us flexibility to add or change tasks. We might run A/B tests to reach the goal, or try regular emails instead of push notifications. Whatever the means, achieving the Key Results is the ultimate aim.
Wrapping up
In my view, the purpose of OKRs is to clarify our goals and align the team, the company, and each individual around the same direction. They are not just for reporting or sharing plans. My own experience with OKRs is still limited, but unless we keep asking ourselves why we are doing this, there is a real risk that it becomes little more than another paperwork exercise.
Teams that already manage OKRs well may find this obvious—or think it is complete nonsense. Still, I believe others are working through the same questions, so I wanted to organize my thoughts in the hope that they might help a little. If you have similar concerns or disagree, I would love to hear your feedback.