Planning work with OKRs

Here’s a fascinating challenge that happens once your teams start targeting outcomes rather than outputs with their OKR goals: planning work becomes unpredictable. Why fascinating as opposed to terrifying? Because unpredictability is the true nature of modern software-based products and services. The illusion of long-term planning evaporates when OKRs are implemented well because you remove any discussion of features or solutions from the conversation. 

Teams and their stakeholders then naturally turn to the next obvious question: what are we going to build? The short answer is, we have some guesses (aka hypotheses) but, in reality, we cannot predict the exact form these ideas will take and, on top of that, when we do start shipping them to market, we really don’t know what our customers and users will do with them. So then how do we plan work when working with objectives and key results? The answer is, in short cycles with a high tolerance for ambiguity and, not just a willingness, but an appetite for course correction. 

If these qualities sound familiar, they should. They’re the qualities of agility. Note I didn’t say Agile — the religion with the capital A. Agility is the organizational ability to change course based on newly discovered evidence. If we can embrace this attitude in our planning it becomes exponentially more realistic, reduces the risk of committing to ideas that don’t work and ensures the organization increasingly deploys its people and resources in the directions most likely to succeed. 

Let’s get specific. 

Assume that you’ve set a compelling strategic OKR for your business unit for the coming year. You’ve identified the meaningful, positive changes in customer behavior that will tell you you’re achieving the strategy and have set quarterly deadlines for each of them. Just in doing this you’ve taken the first step toward planning work with OKRs: you’ve reduced your time horizon. You’re no longer planning a year’s worth of work. You’re planning the next quarter. 

Next, you take a look at your existing backlog of work. What still makes sense? What doesn’t in the face of the newly set goals? Beware the desire to reverse engineer the existing backlog into the new goals. Filter out the feature ideas that don’t make sense anymore — regardless of how far downstream you are in their development. Remember, sunk cost is lost. There’s no getting it back and continued investment in ideas that you now don’t believe will help you achieve your goals is a fool’s errand. 

With a filtered backlog of existing ideas you now have the bandwidth for new hypotheses — educated guesses about what combination of code, copy and design will help you achieve your key result targets. Utilize the entire team — product, design, engineering et al — to create new hypotheses to fill the work filtered out from the old backlog. Consider using the Lean UX canvas as your facilitation tool for this exercise. 

Finally, we need to prioritize the work we will do in the coming quarter. To do this we need to decide which hypotheses to test, which ones to build and which ones to throw away. There are many ways to do this and I recommend the Hypothesis Prioritization Canvas as a good place to start. Working as a team, decide which hypotheses are risky but stand to have a high impact on the customer and therefore the business. These are the hypotheses we are going to test. We have to add this product discovery work to our backlog and ensure it’s accounted for in the team’s efforts (here’s how to integrate discovery and delivery). The faster we can learn if these hypotheses are valid the faster we can move them into a higher level of investment for development and delivery. 

The hypotheses we deem high impact and low risk we don’t test. We get those out to market as quickly as possible, check to see if they meet our KR expectations and iterate on those features over the course of the quarter. 

Anything we deem low impact we don’t test and we don’t build. 

Our backlog now contains a mix of pre-OKR work that still makes sense and newly conceived ideas that we are going to test and build. We have a plan for the next quarter. We don’t look further ahead with any deep detail because there are too many variables that may shift our plans looking too far ahead. If we commit to things that don’t make sense when we start working on them we end up failing both the customer and the company. 

At the end of each quarter we pause and review — how did we trend those our key results? What ideas worked? What didn’t work? What did we learn from that? And now, armed with all of that real-time, current evidence, what are we going to do next quarter? Which hypotheses and features do we persevere? Which do we pivot and how? Which do we kill?

This just-in-time prioritization flies in the face of traditional annual planning because it reflects the modern nature of software-driven businesses rather than a century-old manufacturing model built on predictability and consistency. We just don’t have the luxury of those qualities in our work any more. In my opinion, this type of planning should be welcome in the CFO’s office. After all, if your CFO gave you $1MM and you promised a fixed list of features and specific ROI for each of them only to deliver a small fraction of those features and an even smaller percentage of the ROI, wouldn’t they be upset? Wouldn’t they prefer to give you only a quarter of that, $250k, and have you come back in 3 months with evidence that you should continue spending money on these ideas to get the next $250k? This is risk mitigation. It’s not sexy but it’s a good way to run a business. OKRs help us build that kind of prudent, evidence-based decision making into the way we plan our work. It’s good for customers. It’s good for teams. And it’s good for the business.