Product Manager's Guide to Writing Great OKRs

Objectives and Key Results (OKRs) are an organizational goal-setting framework developed in the 1980s. Most tech companies live and breathe OKRs, including giants like Google and Airbnb, and even Microsoft is moving to them. Despite how common they are, product managers often struggle to come up with good objectives and to set key success metrics. In this post, I go over what OKRs require, plus a few tips that aren’t essential to the framework but work like training wheels while you learn to ride.

Context in OKRs

Context isn’t a required part of an OKR, but it sets the stage and gives motivation, just like the introduction to this post. Use this section to explain why you are pursuing the objective. Did you notice a pattern in one of your feedback loops? Will it help you reach your product vision? You can also include social proof, like customer quotes. I recommend writing the context first to organize your thoughts, then revisiting and possibly rewriting it as your final step. Keep it short.

Setting key results in product OKRs

I deliberately skip the obvious next step of writing the objective and go straight to key results (KRs). It may seem counterintuitive, but KRs help us understand the problem better, which makes a well-defined objective easier to write.

KRs measure success, the health of the objective and progress toward the goal. They have to be quantitative, and you should be able to measure them today. That way you’ll know whether you actually moved the needle or whether the objective isn’t having any impact. KRs shouldn’t be used by managers to measure product managers’ performance. Use them to prioritize and to allocate resources.

I sort my key results into two groups:

• User value
• Business value

User value

Will this objective bring value to users, and if so, how can we measure their success? Try to define what success looks like for an engaged user. It could be posting and receiving 6 messages, connecting 2 more accounts, or inviting and engaging with 3 users in your app.

Business value

Will this objective bring value to the business, and if so, how much? At the end of the day, we want the objective to make the business more successful too. We can measure things like how many free users convert to paid after using the feature, or how many users stop dropping off because a missing feature now exists. We can also tie KRs to the revenue we expect the objective to bring in. Again, don’t commit to anything you can’t accurately measure or attribute to the objective.

KRs have to drive an outcome, not an output. Say we wanted to add a new feature to our product. A possible KR could be:

“We deliver the feature within a 2-week period.”

That KR measures the output without driving an outcome. Instead, measure the value the new feature will bring. Ideally, before you build the feature, you already know which metrics you want to improve, and the feature helps drive them up. It isn’t mandatory, but I like to number my KRs in order of priority.

It’s also a good idea to write KRs with your product pod to get their buy-in, and to sanity-check them with others in the company. Look for similar objectives from the past, and if you find any, check which KRs they measured.

Defining the objective in an OKR

Now that you understand the problem you’re solving and how to measure success, setting a qualitative, aspirational objective should be straightforward. The objective should be a single sentence that is easy to understand. You’ll use it to empower your team and get buy-in from leadership. It has to be specific to the problem you’re solving, and it can support a higher-level objective or company focus.

“Deliver the best product onboarding experience to increase user activation.”

The objective is aspirational, and it’s clear which metric it supports.

What else to include in OKRs

Depending on your company or team, an OKR may need to include other things. I like to list:

• the person responsible for the OKR (it should be whoever writes it)
• my counterparts in the product pod who contribute to it
• the stakeholders who approve it
• others who should be kept informed

After that, I list the initiatives we need to complete for the OKR to succeed. The last part is milestones for when to revisit and review the KRs. All of these parts are optional. They could just as easily live in a product requirements document or somewhere else, depending on how your company tracks and shares information.

Next steps

Now that you have your OKR, it’s time to get it out there and champion the objective and its success. Just make sure to review the KRs at the intervals set in the milestones section.

If this helped you write better OKRs, please share it with others. If you have feedback, reach out on LinkedIn.