“What’s the benefit of a roadmap, if we already set OKRs every quarter?” - If you work with OKRs in your Product and Engineering organization, someone will ask you that question sooner rather than later.
At Personio, we believe that a common understanding about which problems to tackle and why, leads to ownership and high performing teams. That’s why we work with OKRs in addition to roadmaps.
In this article, I’d like to share the answer to the above question which I gave to our product teams at Personio.
The evolution of a product organization
Most products start with an MVP and a roadmap on how to improve and extend it. During the early phase of a product’s lifecycle, execution is fast while the team is small. At this point, your roadmap essentially is your product backlog, with customer feedback almost directly ending up in it. At the same time, a roadmap comes with a timeline. This is essential to plan and derive ETAs for specific features you need to build in order to retain early customers.
With time, your product matures, the customer base grows, and so does your Product and Engineering organization. At this point, you start having multiple teams as well as increasingly specialized individuals. The time where collaboration was as simple as one product manager talking directly with engineers is over. Now there are multiple teams, each with product managers, designers, and engineers. There might even be additional functions around research, copywriting, infrastructure or QA.
The alignment of multiple product teams but also all members of the same team, that happened naturally before, now becomes a significant challenge. Creating strategic alignment should be considered management’s absolute focus. We faced this challenge two years ago at Personio, and thus decided to introduce the OKR framework.
Today, our product teams set their OKRs on a quarterly basis. At the same time, product managers heavily work with roadmaps as a tool for internal and external communication, and for planning team initiatives. For product managers it’s important to know what’s ahead (1) for their specific domain as well as (2) for a longer timeframe than one quarter. During our last OKR setting process, one of our product managers asked the following - very valid -question: “What’s the benefit of a roadmap, if we already set OKRs every quarter?”
Roadmaps vs. OKRs
Roadmaps and OKRs guide us in what to do, but they are fundamentally different.
OKRs are set on a quarterly basis and are therefore time-bound. They are set and owned by the whole product team cross-functionally. OKRs are also very contextual, having to be in line with the company or department OKRs. Most importantly, they are a tool for measuring progress towards high-level strategic goals (objectives), that focus on user problems.
Roadmaps typically are solution-driven and owned by individual product managers rather than an entire team — given that product managers are responsible for product delivery. Roadmaps ultimately are a tool for planning the implementation of specific initiatives based on their priority.
- Address team specific issues
- Owned by the product manager
- Planning tool
- Time-bound to a quarter
- Contextual reg. the company strategy
- Owned by the team (cross-functional)
- Measure progress towards goals
Working with Roadmaps and OKRs
This article is focused on how to work with Roadmaps and OKRS on the squad (aka. product team) level:
(1) One level above, on “Company Level”, live artefacts like global OKRs or a Product Vision. Those should drive objectives and roadmaps of each product team.
(2) Also, there are bottom-up, domain-specific drivers like user needs or technical needs. E.g. “Product analytics shows 60% of users directly access feature X after login, but they need three clicks to get there” or “We need to increase test coverage before being able to modify this part of the system confidently”.
(3) At the intersection of a team’s roadmap and its objectives (red outline), the quarterly OKR setting process can be considered a “course refinement”. It’s the conscious challenging of the roadmap based on strategic objectives in line with the company strategy. It’s also a team effort, equally involving product management, design and engineering. In the other direction, team and domain specific initiatives from a roadmap can be reflected in the OKRs by formulating a user-oriented objective and defining key results for measuring progress. This is the great synergy of using OKRs along with roadmapping. You’re neither ending up with objectives but no idea on how to execute on them, nor are you having a solution-driven roadmap with no measure of success.
Let me summarize what Objectives, Key Results and Roadmaps each are for:
Objectives provide strategic focus and answer the question of why. “We have a clear value-based strategy”
Key results measure success towards objectives in terms of outcome. “We are able to monitor progress and are held accountable for achieving our objectives”
Roadmaps define a set of actionable initiatives. “We properly plan cross-functionally, everyone knows what to do by when”
To learn more about how to work with Product OKRs in general, I can highly recommend Gannon Hall’s article “Product planning with OKRs”.