There’s a big assumption we make when we set OKRs with a specific time box (often a quarterly one). We assume we will be able to achieve the key result by the deadline or at the very least that we’ll have enough information collected at that point to be able to make decisions about how to move forward with our goals and our work. But what if our cycle times are longer than a quarter? What if within the time box we set for ourselves we aren’t able to collect enough information to decide what to do next?
The risks challenge the core value of using OKRs
If you work in a B2C environment with large numbers of users this is likely not a challenge for you. But in B2B companies or consumer organizations with long buying cycles (e.g., appliances) you likely face this challenge regularly. The risks are significant because what ends up happening is teams forgo too much discovery or learning work leaving the fate of the key result to be determined with features in production. What also ends up happening is that even if after the lengthy time box we learn that our key results were not reached, the likelihood of going back to “fix” that old work is slim to none. It’s simply been too long.
What can we do to make OKRs effective with long cycle times?
Increase the amount of early discovery work
If sustaining a consistent level of product discovery work is going to be hard in the long cycle your company uses (and let’s face it, it will be) consider doing more discovery work earlier in the cycle. The goal is to build as much certainty as you can into the initiatives you’ll ship to production before they go live. While this won’t guarantee their success, more product discovery work builds confidence that the work we’re producing will achieve its goals.
This approach forces teams to explicitly prioritize more learning work in the first few sprints of the cycle than delivery work. The objective is to whittle down the hypothesis backlog to the ones we strongly believe will deliver our desired key results. Once we’ve achieved a high-confidence list of initiatives we can proceed with the design and build work required to get it to market and comfortably move on to new work as these ideas sit in production, collect data and eventually inform our success criteria.
Save capacity for optimization work
Let’s say that your cycle time is two quarters. Assuming you take the increased product discovery advice above, you start to ship your list of de-risked hypotheses sometime in February and March. When your bi-annual check-in arrives in early July the conversation, while ever focused on the future, needs to save some discussion time and ultimately team capacity for optimizing the features we shipped earlier in the year. Despite stakeholder pressure to ship new features at faster rates your team must review how the deployments from February and March are performing in-market.
If it’s determined that these features did not get close enough to their key results to be deemed successes, the team must carve out some of their capacity to understand why that happened. This should include both quantitative and qualitative analysis to inform optimizations that take into account not just what your customers were doing but why they were doing it.
While the perception will be that you’re “going back” to fix things, the reality is that you’re ensuring the features you’ve shipped earlier in the year actually delivered the value they were designed to deliver. If they’re not you can then make an evidence-based decision about whether to kill, pivot or persevere the work on those ideas. There needs to be a company-wide expectation that, because your cycle times are longer than usual, every iteration has some percentage of bandwidth reserved for optimization.
Eventually this becomes a rolling optimization process that regularly takes into account features shipped a “long” time ago and verifies that they are still indeed worth maintaining and improving.
The key is organizational will
If OKRs are going to work with your company’s longer cycle times it will be because, eventually, your stakeholders will stop complaining that we’re “going back to fix old features and we should focus on new ones instead.” For this to happen the organization has to want to optimize features shipped more than a quarter ago. It has to be built into the culture and into the incentive structures. This is the only way to build the collective willpower to push back against the drive for ever faster velocity and put focus back where it should be — on customer success.