The role of OKRs in Product Development

In my recent annual performance review, my (unfortunately now former) boss Patrick and I discussed the goals we had defined for the various projects we worked on over the past 12 months.

The discussion evolved particularly around the ambition level when setting goals and how high to aim for works best for committing on it as the Product Owner and getting the (Scrum) team on board.
As you may know, the procedure of setting goals which are quite out of reach (and where achieving 70% is the maximum success rate) has its origins in the OKR methodology which has mainly been shaped by Google after originating from Intel.

So, when I was recapping our discussion, I revisited the best source around OKRs in product development and took some time to dig into the topic.
While there are a lot of valuable details in the re:work guide by Google, I wanted to highlight some of them in particular to help you establishing OKRs in product development:

  • Creating unachievable goals is tricky as it could be seen as setting a team up for failure.
  • Moreover, when aiming high, even failed goals tend to result in substantial advancements.
  • The key is clearly communicating the nature of stretch goals and what are the thresholds for success.
  • Google likes to set OKRs such that success means achieving 70% of the objectives, while fully reaching them is considered extraordinary performance.
  • OKRs should be public within an organization so that every employee knows the organizational objectives and metrics for success.
  • Pick just three to five objectives – more can lead to over-extended teams and a diffusion of effort.
  • Avoid expressions that don’t push for new achievements, e.g., “keep hiring,” “maintain market position,” “continue doing X.”
  • Use expressions that convey endpoints and states, e.g., “climb the mountain,” “eat 5 pies,” “ship feature Y.”
  • Determine around three key results per objective.
  • Key results express measurable milestones which, if achieved, will directly advance the objective.
  • Key results should describe outcomes, not activities.
  • If the KRs include words like “consult,” “help,” “analyze,” “participate,” they’re describing activities.
  • Instead, describe the impact of these activities, e.g., “publish customer service satisfaction levels by March 7th” rather than “assess customer service satisfaction.”
  • Measurable milestones should include evidence of completion and this evidence should be available, credible, and easily discoverable.
  • Use this Scorecard to look back at your OKRs