A colleague at Government Digital Service recently told me that they’d adopted objectives and key results (OKRs) in their team, but they were struggling with the objectives (plural) their leadership had set. The objectives just described the things that the leadership team wanted them to do rather than problems to solve. They had been given a list of outputs, not outcomes. This meant the team was finding it hard to buy into the mission and worried they might not explore the problem space enough.
Outputs vs outcomes
An output is a thing which a team produces or does. ‘Build this thing, upgrade this thing, change this thing.’ An outcome is an end result which a team delivers or reaches. ‘Improve this experience, increase this measure, explore this market.’ Setting outputs is easy, we’re all focussed on doing things. But doing things to reach an end result is a bit more complicated; achieving outcomes requires domain expertise, a willingness to explore the problem space, and a culture which supports experimentation.
Take apples as an example. I eat apples because they are tasty and healthy. All apples are alike, in that they are all tasty and healthy…until someone produces an apple which is tastier. Or an apple which is crisper. Or stores over winter longer. In an apple market with different varieties from different producers, I tend to buy products with the characteristics which appeal to me. These differentiators help me choose one eating experience from the others. Outputs are physical things but outcomes are the differences made by the outputs – a change that will occur as a result.
Producing an apple is an output. Producing a tastier apple that appeals to a specific audience is an outcome. Producing an output is manufacturing work, whereas producing an outcome is knowledge work.
Turning ‘Build this’ into ‘Realise that’
My colleague was looking for guidance on how an objective should relate to a known problem, and not just be things on the leadership team’s wish list, which my previous post on OKRs didn’t cover. In the past, I’ve found that instead of asking what you’re doing but why you’re doing it, leadership teams share some of their vision which helps you turn outputs into outcomes.
When asked to upgrade a part of our infrastructure, I used the 5 Whys to dig into the root reason why the GOV.UK programme team wanted us to do it. They said it was because it was out-of-support and hadn’t been upgraded in a while, because we manage the servers ourselves. Upgrading search ate up a lot of time and effort, which would be better spent on making GOV.UK a more unique and special corner of the web.
Understanding their vision meant we could set an outcome-focussed objective together. Instead of upgrading Elasticsearch, the team ended up making our search functionality more supportable in the future, and we improved our perspective of the resilience and performance of our search infrastructure.
That example was a delivery mission but it’s also possible write outcomes for discovery missions too. When we were asked to explore personalisation on GOV.UK, again I asked the leadership team why we were doing it. They wanted to understand whether it should be a direction to head in, and they also had some questions from government ministers to answer. So we came up with this: ‘Manifest the opportunities, if any, for a more coherent, personalised experience of interacting with government.’ Our key results were almost entirely research initiatives.
A great way to frame user needs and outcomes in your day-to-day product work is by using problem statements and hypotheses1.
Unlearn your output-based leadership style
It’s a change in mindset for leadership to manage outcomes or results, instead of the traditional way of managing effort and output. But knowledge workers focus on outcomes because it sets the goal in their mind, enables them to better track their progress, and enables them to learn. For leadership teams, setting outcome-based objectives is a protection against having to micro-manage.
An output communicates the piece of value a product team is delivering, but an outcome helps communicate the context and priorities a product team will need to grapple with to be successful. If your product teams aren’t clear on the desired outcomes of your organisation, how can they ever help you achieve it?
I’ll write about this soon. Very soon. ↩
Here's how I frame what we've achieved so far, what's left to do and what's next with product teams at GOV.UK.
I think it's time for people working on computers to look sideways (metaphorically) and help each other out in designing their future of work.
Our roadmap for GOV.UK Pay has always been open, but we wanted to explore how we might collaborate with users on prioritising things on the roadmap.