OKRs: how to shift your team’s focus from roadmaps to objectives
The transformation of some companies is necessary, but it takes time. So where do we start?
We’re a stubborn team of Product Managers.
This doesn’t mean you can’t talk us out of developing a feature in a specific way, or that you won’t get us to work in certain ways. We’re stubborn in the sense that whenever there’s something we want to achieve, we put our minds together towards that goal. We’re determined. To do things the way we think it’s right way. We’re determined to pursue our goals.
Some months ago, I wrote a post about OKRs and how they won’t always apply in your company or environment. Yes, it reflects our own situation. Our team might not be fit for OKRs today.
Today.
We just don’t accept the way things are whenever we believe change can bring us a better tomorrow, a more comfortable and meaningful work environment. That’s why Paul Iliffe and myself believe in pushing our team to move towards OKRs. Even knowing it will take time, lots of discussions, and overcoming barriers and detractors, we’re very confident this is the way to go.
Why are we so determined to use OKRs
You might ask us this question. We ourselves still do. What we want is not so much about the OKR framework per se: what we truly want is the mindset it requires. Working towards outcomes and not outputs. We want to make decisions based on hard data and facts, not on opinions. We aim to make an impact in our customers’ lives and help our company grow. And we wish to spread that same mindset throughout the entire organization.
Today, we build 3-month roadmaps every quarter. Every time, no matter how much we avoid saying it, what we’re actually doing is committing to a specific list of projects and features that we will ship over the next 90 days. However, the results that will be achieved with all that effort is out of the picture.
Heck, because of all the bureaucracy and processes, we can’t even refine the products we ship!
The truth we face is that it would be extremely difficult to work with OKRs considering our circumstances. But don’t tell us something will be hard or impossible, because we just will keep going!
How are we going to do it?
The only way we know: trying hard. We just start doing it.
For now, we’ll have to work more. We know we can’t get rid of our current roadmap-based processes, but we still want to give OKRs a serious try. So we’re going to be doing both tracks for a while:
- Roadmap track. Maintain our current “way of working”, based on roadmaps of projects and features. It allows us to give visibility to our stakeholders of our plans, and we won’t disrupt too much the current methodology.
- OKR track. In parallel, we start working with OKRs. We have never worked with OKRs, but we know we want to get there. So we’ve established some basic rules and guidelines to help everyone out.
The rules
First: don’t expect perfect OKRs for now. We’re starting, better if we do most of them good than having all perfectly set. Some people will need more time to adapt, adjust and be familiar with OKRs and the way to set them properly.
Second: if you can’t measure it, don’t use it for your key results. We need to get used to reviewing and tracking OKRs constantly. When we try to define success with metrics that are too complex to obtain, or require too many different teams to reach that KPI’s value, it’s better that we drop it and choose a different KPI.
Third: when talking about projects, refer to your OKRs. When teams from other areas, business people from other countries, or maybe even our CEO, want something done, check your OKRs. Is this something that will help us move the needle?
Fourth: share your learnings constantly. Some people in the team had already worked with OKRs. Others, we just love the framework and the benefits it provides. But most hadn’t, and they’re facing a new challenge to think differently, to challenge and set our own objectives. Even though this is something we do quite often, we wanted to stress the importance of doing so while we move forward with OKRs. Visibility, open discussions, transparency. For example, we have all our teams’ OKRs shared in the same Google Document so we can all see everyone’s struggle and progress.
Conclusions so far…
We jumped and are already in mid-air hoping to land where we planned.
- A shift like this one requires constant evangelization. In every session, every step of the way. Even changing how we used to run some meetings, where we’ll now start to review OKRs when we would have gone over projects.
- Buy in from the team is key. We wanted to make sure everyone in our team was willing to work harder, to have both processes in place at the same time, and to change our mindset. Why? Because we need them to be committed to trying this new way of working and thinking, to keep pushing for it and evangelizing with everyone. It’s not going to be easy, but if we get their compromise, it will surely help us achieve our goal.
- Reading and researching before starting was very important. It helped us create and share best practices on defining OKRs beforehand. We even attended an outstanding masterclass from Javier Escribano, Co-founder and CPO of Ontruck (read this to see how they use OKRs).
- Discussions around our plans are now way richer. We discuss the problems we want to solve for our customers more than we do the solutions to ship. We look at the results and impact we want to generate, not the features we plan on checking off of the list.
- We now have a simpler and much shorter process. We’ve gone from this…
…to this…
Remember, it’s not about OKRs “just because OKRs”. It’s about being objective-driven, tracking progress, and acting accordingly.
