Need someone to lead product management at your software company? I create software for people that create software and I'm looking for my next opportunity. Check out my resume and get in touch.

How I use OKRs

I like to manage with OKRs. This post describes how I use them, how I think about what’s important, and the tactics I use to execute using them. This isn’t a complete primer on OKRs. There are plenty of those on the internet and in books. I highly recommend Christina Wodtke’s Radical Focus if you want a detailed guide to OKRs. I’m writing this mostly so I can send it to my future teams when we’re implementing OKRs.

The OKR is an Objective, something like “Establish Product Foo among PHP developers” and a set of Key Results (KR), the performance indicators that measure if you got there.

An Objective is an aspirational goal that describes in a big picture what you’re trying to accomplish. It’s the headline. A KR is how we measure that goal. Because it’s a measurement, it should always have a number. A good KR is a measure of a change in the behavior of our users. "Ship a PHP SDK for Foo" isn’t a good KR. "45 different developers have used our Foo PHP SDK to make at least one API call" is a good KR. It’s measurable and it’s focused on what the user did instead of what we did.

I remember this by applying Wodtke’s quote, "A KR isn’t something you did. It’s what happened because of something you did."

I’ll make an exception to "the KR should always have a number" if you’re creating a long, multi-quarter OKR that’s broken down into smaller quarters. The early quarter might have a learning Objective where your goal is to know if you should proceed or know how to structure later OKRs. This is much rarer than most people think it is - I find that most KRs can have a number if you spend a few minutes thinking about it.

The other thing that’s important in a KR is that it solves the objective. Can you solve the objective without hitting the KRs? Can you reach the KRs and not solve the objective? Then the KRs are not good ones.

Many KRs should also have a qualitative element. It might be easy to get 45 PHP developers to use your SDK once by offering a prize for anyone who makes an API call. But to be meaningful to your "establish us among PHP developers" objective, many of those developers would have to stick around for more than one API call. Adding a qualitative facet to the KR can keep you from using shortcuts and tricks to reach the KRs. Something like "45 different developers have used our Foo PHP SDK to make at least one API call, and 12 are still using it in a significant way after 3 weeks."

KRs should always be stretches. "Shoot for the stars, because even if you miss you’ll reach the moon." If you think you’d be able to easily get 35 developers to use the PHP SDK, but would have to work extra hard to get 42 to use it, then setting the target at 45 is a good idea. When people set goals that are hard to reach, they achieve more than if they set easy goals. If you set the target at 35, you’ll stop when you get there. But if you set it at 45 but only get to 41, you’ve still done more than you would have with the easy goal. A good rule of thumb is that you should consistently reach 70-80% of your targets on average. If you’re hitting higher than that, your KRs are too easy.

For this reason, OKRs must never be used for performance management. OKRs are a tool for deploying strategy across an organization and aligning everyone on common goals. They should not be tied to compensation, promotions, or even mentioned in performance reviews. It’s tempting to look at this set of goals with measurements and use those to manage the individuals, but it will backfire. The moment you connect OKRs to performance, people will start creating KRs that are trivial to achieve. You’ll pull performance down by lowering expectations.

I like OKRs that are a quarter long. A quarter is long enough to do something meaningful but short enough that you’ll choose achievable objectives. I like one to three objectives per team. You don’t list everything you’re doing in an OKR. Functions that keep the ship running and the lights on don’t go in OKRs. An OKR is for the things that are going to leap you forward. “If we only got these things done this quarter, would we feel successful?” You can’t do more than three of those in a quarter.

For teams just getting started on this working style, having one objective is better than having three. That doesn’t mean you only do one thing - you might do things that aren’t in the OKRs at first. But choosing one forces clarity of purpose.

In addition to quarterly OKRs, I like to have one objective for the year. This is the North Star. The direction we’re heading throughout 2023. The quarterly objectives are then designed to steer us there.


A common problem with any longer-term goal is that the team reaches the end of the time box and then suddenly remembers their goals. With a week left in the quarter, you dust off the OKRs you created 3 months ago and realize you didn’t do any of them. You got busy with the day-to-day and didn’t make progress on a single OKR. So you look at the KRs and try and jam the work you did into them. Or you try and cram a quarter’s worth of work into a few weeks to make some progress.

This isn’t helpful.

If the OKR is there to keep many groups aligned to a shared purpose, you have to have all groups working on that purpose continuously.

To fix this last-minute scramble problem, I like the teams to score ORKs weekly. At the end of each week, take 2 minutes to look at each KR and score how much progress you’ve made toward the number. If you have a KR of "45 new signups to our newsletter" and you have 20, then you’re about halfway there. Celebrate that and write it down. I don’t care if you use percentages, raw numbers, smiley faces, or something else. It’s not the act of writing down that’s important, it’s the introspection: every week you’re looking at your OKRs as a team and thinking about your progress.

This can get demotivating for some KRs that take a long time to achieve. Getting 45 signups to a newsletter might mean you first have to create the newsletter. That takes a couple of weeks. Then you have to start advertising it, and customers need to see the ad 4-5 times before they follow through. Suddenly you’re 8 weeks in and only have 6 signups. Looking at a KR that’s stuck under 10% achievement for weeks on end can be a drag. So if you find it helpful, score using the metric of confidence instead of or in addition to your KR score. Yes, you only have 4 signups, but all those came in the last 3 days and traffic to your newsletter page is growing. So you have high confidence you’ll hit this, even if the raw number doesn’t look great right now.

Recently Written

Great prodct managers own the outcomes (May 14)
Being a product manager means never having to say, "that's not my job."
Too Big To Fail (Apr 9)
When a company piles resources on a new product idea, it doesn't have room to fail. That keeps it from succeeding.
Go small (Apr 4)
The strengths of a large organization are the opposite of what makes innovation work. Starting something new requires that you start with a small team.
Start with a Belief (Apr 1)
You can't use data to build products unless you start with a hypothesis.
Mastery doesn’t come from perfect planning (Dec 21)
In a ceramics class, one group focused on a single perfect dish, while another made many with no quality focus. The result? A lesson in the value of practice over perfection.
The Dark Side of Input Metrics (Nov 27)
Using input metrics in the wrong way can cause unexpected behaviors, stifled creativity, and micromanagement.
Reframe How You Think About Users of your Internal Platform (Nov 13)
Changing from "Customers" to "Partners" will give you a better perspective on internal product development.
Measuring Feature success (Oct 17)
You're building features to solve problems. If you don't know what success looks like, how did you decide on that feature at all?


What I'm Reading


Adam Kalsey

+1 916 600 2497


Public Key

© 1999-2024 Adam Kalsey.