After last week's article, I received several questions about how to use the two bucket technique in practice. I'll try to answer them in this post.
Barry (not his real name) shared a common situation:
I'm curious about how using the two buckets compares to a different method I learned where you explicitly connect projects to each Key Result, as shown in this example:
The method above sounds nice in theory, but in practice it creates two challenges:
Some people end up focusing on the projects. They ignore or don't really care about the Key Results.
We have some essential projects that don't tie to an OKR and it's not clear what we should do with them.
Your two-bucket approach helps address #2. But how can we achieve our OKRs if we don't have projects explicitly connected to them?
To answer Barry's questions, we need to understand that focusing on outcomes requires a fundamental mindset shift.
Admitting we can't know everything in advance
You've probably seen a lot of advice like the example shared by Barry in the image above.
You are told to map out a list of projects under each Key Result so you can plan exactly what you're going to do to achieve your OKR.
The problem is that people often end up sticking to that predefined project list regardless of the outcome. When they do that, they focus on projects, not on outcomes.
They are only using OKR on paper.
The company may have OKRs, but people don't take ownership over them, and focus on projects instead. OKR is seen as a formality that doesn't guide day-to-day work.
Truly focusing on outcomes requires a fundamental mindset shift.
Using the outcomes approach requires admitting that we can't know everything in advance and that some of our projects won't generate the expected outcomes.
In real life, even ideas that seem obvious and are executed flawlessly can fail to meet expectations.
That means we can't create a list of all projects we'll ship in the quarter and stick to it. Instead, we have to quickly test different ideas to discover which ones will help achieve the outcome.
To do that, we have to develop new muscles: the skills and organizational capabilities to enable people to run experiments and quickly test ideas.
The table below contrasts the implicit assumptions behind the outcomes approach and the due dates approach.
How to use the two buckets
I always try to keep things as simple as possible in my writing. However, I may have gone too far in simplifying my last article. I left too much information implicit and made it harder for people to fully grasp the concepts.
Let me fix that by providing a more detailed explanation about how to use the two buckets, with slightly different wording than I've used before.
The core idea is to imagine that we are going to put our investments and priorities into two “buckets”:
In the first bucket, we'll put the investments that are focused on achieving outcomes and will be managed using the outcomes approach.
In the second bucket, we'll put the investments that are focused on meeting project deadlines and will be managed using the due dates approach (also known as the “PMO approach").
Investments with outcomes we can measure go into the outcomes bucket, while investments with outcomes we can't measure—at least for now—go into the bucket focused on due dates.
Both buckets contain projects inside
To be clear, both approaches for managing work use projects, but they do it in completely different ways.
One way to visualize this is to imagine we have two "layers" inside both buckets. On top, you have your desired outcomes, and underneath them you have projects to help achieve those outcomes:
Inside the outcomes bucket, we have an OKR on top and projects at the bottom. These projects are just ideas for achieving the outcome, and we have to discover which ones will help us do that.
The list of ideas can change at any time. We can test different ones or test different ways to implement the same idea.
For example, let's say one of your ideas is to redesign the account registration flow of your app. There are multiple ways you could do that, and you may want to quickly test different options to discover which one will help reach the outcome.
Inside the bucket focused on due dates, we find something different: projects where the link to outcomes is missing or unclear. That's why I call them “projects without outcomes”.
Without an outcome associated with them, these projects become the goal. Teams focus on completing a predefined list of deliverables rather than doing discovery and testing different ideas.
Using the due dates approach is not a problem. The problem is overusing it.
But there are many investments that companies “should” manage using outcomes, but don't.
Besides our OKR, we have to complete our projects without outcomes
Here's an example of the two buckets:
In addition to achieving our OKR, we also have to complete these projects without outcomes, or just projects, for short.
To do that, we have to do two things.
First, we have to include these projects without outcomes alongside our OKRs when setting OKRs at the beginning of the quarter and when tracking progress during the weekly check-ins.
Second, we have to ensure we continue to test different ways to achieve the OKR. Our list of ideas has to remain flexible instead of turning into a fixed project roadmap.
This enables us to stay focused on the outcome rather than just completing predefined tasks.
To achieve those two things, we have to start thinking about OKR + Projects.
The OKR + Projects format allows us to communicate and track our desired outcome and our projects without outcomes side by side:
The OKR + Projects format does not include the list of ideas, and that's intentional.
We want to have separate conversations about our OKR+Projects (in blue) and our ideas or experiments to achieve the OKR (in green):
We have to focus on our OKR + Projects when discussing our priorities for the quarter and during the weekly check-ins.
Teams can share brief highlights of the ideas they are testing or planning to test, but they should avoid detailed updates that can take a lot of time and distract from the outcomes.
We must resist the urge to turn these discussions into detailed project reviews or brainstorming sessions for new ideas to test.
Our brains are wired to think about projects, and it's extremely easy to start prescribing specific solutions for the teams. We all fall into this trap from time to time, myself included.
Leaders may choose to “Dive Deep” and help the teams with the details of the ideas being tested, but that has to be a separate conversation from the OKR check-in.
This deep dive should focus on understanding what the teams have learned, the data they have, the experiments they have run, and their main hypotheses moving forward.
Let’s put this into practice
The best way to put this article into practice is by discussing its main takeaways with your colleagues or friends.
Here are a few questions to help:
Are you only using OKR on paper? Are you focusing on projects instead of using OKR to guide your day-to-day decisions?
Are you comfortable with the idea of not knowing everything in advance and adapting plans as you go? What steps could you take to adopt this mindset?
How can you use the OKR + Projects format to better communicate priorities and track progress?
What can you do to ensure you continue to test different ways to achieve the OKR? How can you avoid turning your list of ideas into a fixed project roadmap?
How can you avoid prescribing specific solutions for the teams?
I’ll be back soon with another post. In the meantime, feel free to share your thoughts in the comments or email me.
If you’re finding this newsletter valuable, share it with a friend and consider subscribing if you haven’t already.
This article was extremely helpful, and an excellent follow-up / expansion to other recent articles. Well done!