What happens after OKRs?

Posted by Alex Galin
on August 6, 2018

This is a guest blog from Jeff Gothelf, Author: Lean UX and Sense & Respond. You can follow Jeff’s blog, follow Jeff on Twitter, or visit his website.

So you’ve made the leap to Objectives and Key Results. Congratulations. And you did it right. You wrote qualitative objectives that were aspirational and inspirational. They’re aligned to your strategic goals and the executive team is on board. Your Key Results are written as measures of behavior (your customers’ or your employees’), just the way they should be. Good work. Now it’s time to get the teams to work on those objectives but, wait a minute, did you notice what happened now that your teams are being managed to outcomes (yep, KR’s are outcomes)?

The prescriptive, feature-centric product roadmap they’ve been working from is gone. What do your teams do first?

Enter product discovery.

When well-written OKRs are given to teams as their new measure of progress and success those teams have to now figure out what the right combination of code, copy and design is that will result in those changes in behavior. The product roadmap that guided the teams before may certainly hold some promising ideas but how do we know that this set of features will deliver the KRs we seek? The short answer? We don’t.

Product discovery is the work your teams do to test their ideas. It’s research. It’s design. It’s experimentation. It’s proofs of concept. And much more. When these tests reveal promising changes in customer (or employee) behavior then we continue to invest in those ideas because we have clear, market-driven evidence that our ideas our working. Success is defined by our Key Results, not by the deployment of a specific feature. Teams work in cross-functional collaboration to propose ideas, test them, validate/kill them and move forward in the most objective, evidence-driven way they can.

OKRs will fail without product discovery.

If you’re considering implementing OKRs in your organization then you must also train your teams in product discovery. There are lots of ways to mess up the actual writing of the OKRs themselves, but, if done right your teams will no longer have a committed list of features to deploy (a roadmap). While there is no shortage of resources on product discovery, here’s a quick list of first steps once your OKRs are confirmed:

  1. Gather the team — product, design, engineering at the very least — and present the quarter’s OKRs to the team with rationale of how they ladder up to the corporate goals.
  2. Brainstorm ideas from everyone on the team on ways they believe the team can hit it’s KRs. Ideas in your old roadmap are absolutely fair game for this exercise.
  3. Prioritize the ideas based on how likely the team believes they are to achieve the goals.
  4. Identify the biggest risks to the top ideas in your list.
  5. Design experiments to test those risks to see if they’re worth overcoming or too risky.
  6. Implement the features that show the most promise from experimentation.
  7. Measure the deployed features’ impact on your desired KRs.
  8. Optimize those features that are working and deprecate the ones that aren’t working.
  9. Repeat

Objectives and Key Results, when done right, are the right alignment and goal-setting mechanism for building customer-centric, continuously learning teams. However, if your teams don’t know how to practice continuous learning, teach them how to do product discovery. It’s tactical, practical and builds the muscles they need to encourage a culture of continuous learning, improvement and agility.