If there’s one thing we’ve had a strong opinion on in our work with Objectives and Key Results it’s that your key results must be outcomes. They must be meaningful changes in human behavior that drive business results. This is the critical pivot in goal-setting that OKRs enable and this is what makes them powerful. It’s also what makes them difficult to implement. Almost without exception, every team we work with asks some variation of this question, “Is it ever ok to have an output as a key result?” And, as strongly as we feel about the need for managing to outcomes, we also don’t like to speak in absolutes. So, yes, there is a scenario where having an output as a key result makes sense. 

Low risk, high certainty situations were made for focusing on outputs

One of the benefits of using outcomes as your key results is that it doesn’t lock you into one deliverable. In fact, it creates the space for you and your team to discover the best way to meet the needs of your customers and evolve that approach (or discard it completely) based on how well you’re impacting their behavior. This approach works well for most situations where risk is high and certainty is low. In most cases we don’t know exactly what to make to solve our customers’ problems. However, if you do find yourself in a situation where the certainty is high and the risk is low, an output may just make sense as your goal. 

What does low risk, high certainty actually mean?

Let’s be clear. If you believe something is low risk it’s not just a feeling. You have data to back up that assertion. It’s also not because your boss told you to produce that output. They may be confident but how do they know it’s low risk and high certainty? Let’s describe exactly what we mean when we use those two phrases to describe our work. 

First of all, we should know exactly what problem we’re solving. This should be an observable problem that a significant portion of our customers are experiencing. The impact of this issue should be significant enough to be felt by the company. Second, we should know our users very well. There should be no hesitation to clearly spell out exactly who uses our product, why they use it and how well we’ve been meeting their needs in the past. Finally, we have a clear sense of what we should make and how we should make it. This last one is the trickiest. 

If I was to ask you right now what you should make for your customers and how you think it should be designed and produced you’d likely have a clear answer for me. That’s not what we’re asking with that last question. Not only should we know what to make but we should be convinced either by a deep subject matter expertise or lack of alternative viable options that this is the only way to meet the customer’s needs. 

If you can confidently state the problem you’re solving and its impact on the organization along with a deep understanding of the customer and a compelling case for why this one approach is the only way to solve the problem, you can use an output as your goal. 

Here’s an example: years ago I had a short engagement with a newspaper. I spent a bit of time with their internal content management team. They used a custom-built tool to manage their publishing workflow. The users of the CMS – everyone from reporters to editors to layout designers – needed a meta-tagging feature. The need was clear and pronounced from across the user base. The CMS was the only system into which this effort could be put. The interface and publishing workflow only offered a finite number of options for where and how to add in the required metadata. In this case, the problem was known as was the user and the subject matter. There was very little risk in the team’s proposed approach and high certainty of success. In this case, working towards an output made sense. 

Confidence is not the same as risk reduction

I hesitated writing this blog post. I feel like it could be interpreted as “permission” to use outputs as your key results whenever you are confident in your product idea. Confidence is great. We should all present our ideas with confidence but it’s not the same as data nor explicit risk reduction efforts. In most cases there are way too many assumptions to focus on just one solution. Use outcomes as your key results in the majority of cases. If you do find yourself in a niche situation with few viable options, perhaps an output would make sense.