Objective and key results (OKRs) are becoming the new norm for tracking and reporting progress on key bets to executives. It is a key part of product planning as outlined in my third post on 1-N product management.
Here are things that surprised me when I dove deeper into OKRs
OKRs are not a panacea or a cure-all
OKRs are not new. They have existed for over 30 years
OKRs are not tied to compensation. Huh! Yes, its true. You can miss your OKRs and still get a raise. What!
OKRs are hard to get right
OKRs need CFRs. More on CFRs later
OKRs need to be public
OKRs need to be reviewed regularly for them to drive culture
OKRs are not a panacea
There can be bad OKRs. Some OKRs can also lead to bad behaviour. Especially when the “counter” OKR is not specified. So, if you have an OKR on adding functionality, you should also have an OKR on bugs found by QE and code reviews by peers so that you can catch bad behaviour.
OKRs are not new
OKRs were popularised by Andy Grove. You must read his stellar book - high output management if you still haven’t. They were popularised at Intel and are embedded deeply in Google’s culture. They have been used at most large silicon valley companies at some point.
OKRs are a new take on Peter Drucker’s Management by Objectives. Unlike MBOs OKRs are more bottoms up. Teams in large organisations can come up with their own OKRs to tie into the top level OKRs.
OKRs are not tied to compensation
It is also very important to note that OKRs are not tied to compensation or bonuses. They are only tools to align a large organisation towards stated objectives and help more people in the organisation stretch and achieve great things for the organisation and themselves.
OKRs are meant to increase the velocity and aligning the speed vectors in one direction. It also encourages risk taking. You should not be meeting all your key results (KRs). If you do, then the KRs are too easy.
John Doerr wrote a book about OKRs, which I highly recommend to anyone serious about implementing OKRs. Watch this talk here:
It is also good to look at how Google does OKRs. Clearly explained in the video below.
The broad idea is to build a story around your bets for a defined time frame. Most companies do yearly OKRs with a quarterly check-in. Faster moving or smaller companies might do the OKR setting process quarterly.
OKRs are hard to get right
Good OKRs require a lot of work and alignment. Here is an example:
Established products generally have two areas of focus:
Delight and retain existing users
Grow by bringing more users to engage with your product
So, how can we make these goals into OKRs?
Lets pick one objective. “Delight and retain existing users”
The key results for this objective can be:
Improve NPS by x% each quarter by reducing crash rate by 20%
Improve NPS by y% each quarter by improving <file open> performance by z%
Get 10 positive mentions by users on social by influencers with over 10K followers each quarter
Improve 3 month return rate by x%
Reduce median response time for all customer complaints from x days to y days over the next 2 quarters
Address all customer calls within x minutes.
Build self help content to deflect phone and chat support to self service
All these should result in improved retention and help you meet your objective.
Now you have to cascade this OKR to each member of your team or each scrum team. For example, you may have a team responsible for fixing bugs and addresses user issues. Their objective should be:
Fix top 10 user reported bugs in each quarter
Implement top 5 user requests each quarter
Write a blog post every quarter to communicate progress on user issues
A PM on this team can have the following KRs:
Make sure top 5 feature requests are always scoped out and in JIRA for design to pick up every month.
Prioritise user requests received on different channels into a unified backlog. Prune it every week. Share this backlog monthly with stakeholders (eng, pm, design, user research, pmm, growth)
Meet 5 key influencers this month to scope out issues with app performance so that engineering has a list of areas to focus on when they are ready to pick up performance stories.
Work with product marketing to share progress on user issues every month via a public blog post.
Similarly, support teams can have their own KRs that bring customer delight.
OKRs are not new. They have been in existing for a while. They were derived from Peter Drucker’s management by objectives (MBOs). They do not guarantee success. When used throughout the organisation and publicly shared, they provide line of sight between your work and the objectives of the organisation.
They also allow you to discuss priorities by comparing existing objectives to newer ones.
OKRs need CFRs
CFR stands for Conversations, Feedback and Recognition.
These go hand in hand with OKRs. This post details how CFRs work with OKRs.
To me, CFRs are the outline for every check-in or 1 on 1 conversation you have with your team. CFRs enable continuous performance monitoring and support.
OKRs need to be public
OKRs need to be accessible on the company intranet so that you can know what are the key objectives for each team. Progress on OKRs should also be public. This sets a culture of transparency within the org.
It also allows team to work together better. If you know what is success for a team you are working with, you can frame any negotiations in a way that allow them to succeed.
OKRs need to be reviewed regularly
OKRs do not get met if they are not reviewed at a regular cadence. Many “Chief of staff” program management jobs require discipline around reviewing team OKRs and what needs to change to meet stated OKRs.
You cannot “Set and Forget” OKRs.
That’s it.
This became too long of a post.
Let me know if you have any questions or anything else you want me to cover on OKRs. I have a lot more including issues in implementing OKRs with PM teams.
Try any of these free OKR tools to start your journey:
Use GTMPlan when you get serious about OKRs.
—Anubhav