OKRs are particularly well suited to Product planning, as Objectives correlate directly to the problem area a team is focused on, while the Key Results represent the progress that can be made against that problem over a given time period.
As an example, let’s consider a team focused on user’s first-time experience with a hotel booking website. Following is their Objective:
Improve the user experience by addressing core product performance issues.
The Objective is intentionally broad and speaks to the team’s long-term mission (prioritizing the problems that have the biggest impact on conversion and retention). The objective will likely carry over until our core strategy changes. However, the results (KRs) they seek to achieve and the projects they define to impact those results will change with each planning cycle.
During a particular planning cycle, the results they plan to achieve could be something along the lines of the following:
- Decrease average 1st page load time to interactive of hotel pages for United States users from 4.62 seconds in May 2017 to 500ms in September 2017
- Decrease average 1st page load time to interactive of the home page for United States users from 3.59 seconds in May 2017 to 500ms in September 2017
- Decrease average 1st page load time to interactive of search result pages for United States users from 3.94 seconds in May 2017 to 500ms in September 2017
Each KR is specific and measurable. If defining a specific metric is impractical, one can instead define a result in binary terms: “achieve code completion for X by Y.”
The order of the KRs is also stack ranked by importance (in this example the pages with the highest amount of traffic and bounce rates).
The problem the team is focused on and the impact of their work becomes the main focus. During the OKR planning process, potential solutions are not discussed. Solutions are simply potential ways to drive impact. In this way, PMs grow attached to the problem, rather than specific solutions. They are non-attached to the solutions, but are laser-focused on the problem and solving it in the quickest and least costly way possible.
Executives should only care about the product team’s OKRs. What they plan to build should be of little interest, as the features themselves are simply a means to an end, and unless the executives have themselves done extensive research and prioritization, their opinion about what features should be built is irrelevant. We aren’t building the product for them, we are building it to appeal to a specific set of users or customers in order to achieve our business goals.
Similarly, a PMs performance should be assessed on their ability to achieve their stated goals, not on how much software they have shipped or someone’s subjective opinion about the features they created.
While it is common practice for a team to have 3 to 4 objectives, with 3 to 5 key results for each objective, Squads (sub-teams) should focus on one simple objective that reflects their core mission as a team.
OKRs are formulated by each squad by drawing consensus within the squad and across stakeholders. The PM operating as a squad leader is responsible for building consensus while using his or her best judgment to decide when consensus cannot be reached and making or escalating a decision.
Thanks for reading. In Part 5 we’ll summarize a list of best practices for defining both Objectives & Key Results, as well as how to best facilitate OKR retrospectives.