Listen to the audio version of this article:
OKRs are a method for setting and tracking goals. The acronym stands for objectives and key results. The objective is the goal, which describes what you want to achieve. The key results state the specific criteria that have to be fulfilled to meet the objective.
To make this more concrete, let’s look at an example:
Objective: Grow the product management team.
Key result 1: Three product managers are hired.
Key result 2: The onboarding system is improved, and time-to-proficiency is reduced by 25%.
Key result 3: The product management processes are adapted to preserve the productivity level of the team.
As the example shows, OKRs are often written so that the objective is qualitative, and the key results are quantitative. Additionally, a small number of key results is commonly employed.[1] Please note that I don’t claim to be an OKR expert. But I experienced OKRs first-hand at Intel—where they were originally invented—when I worked for the company in the late 1990s.[2]
What makes working with outcome-based goals like OKRs powerful—and for some organisations challenging—is that they state what needs to be achieved but not how. Rather than handing a list of tasks to people, objectives are agreed. The individuals then determine how they can be met. This helps empower teams and prevent micromanagement.
A product roadmap is an actionable plan that describes how a product is likely to evolve.[3] Traditionally, it is a list of features that is mapped onto a timeline. Fortunately, in the last ten years, outcome-based, goal-oriented roadmaps have become more popular.
Below is an example of how such a product roadmap might be captured and the elements it might contain.
Figure 1 shows a specific goal-oriented roadmap template I developed, the GO Product Roadmap. You can download the template by clicking on the image above.
Let’s take a quick look at the roadmap’s five elements. The most important one is the goal, and it’s positioned in the middle of the template on the third row. It describes the specific benefit or outcome the product should achieve. Sample goals are acquiring customers, increasing engagement, and future-proofing the product by removing technical debt. The other four elements offer additional information: The one on the first row captures the date or the time frame when a goal should be met, for example, in the third quarter of 2024. The second row gives you the option to state a name. This is useful when meeting the product goal results in a new major release or product version, for instance, iOS 17.4 and Android 14.0. The fourth row lists the product’s features. These are the outputs that are required to meet the goal. The fifth and final row captures the metrics to determine if a product goal has been met.
You can learn more about the GO product roadmap by watching the video below.
OKRs and outcome-based product roadmaps both assume that setting specific goals helps people do a great job. This similarity allows you to combine the two approaches. To do so, you have two choices. You can either work with an outcome-based roadmap like the one in Figure 1 and view the goal as the objective and the other roadmap elements as the key results. Alternatively, you can create an OKR-based roadmap. Figure 2 shows what such a plan might look like.
The structure in Figure 2 offers the same information as the one in Figure 1 except for the name element. This becomes clearer when we use both templates side by side.
Figure 3 contains an extract of a GO Product Roadmap for a new healthy-eating product.[4] The initial offering—the MVP—should help the users understand their eating habits and acquire an initial user base. It should be available in the third quarter of 2024 and offer two key features. The MVP is regarded as a success if the product is one of the top 15 diabetes apps six weeks after its launch. The OKR-based roadmap shows virtually the same information. It first states the goal, followed by the target time frame, the key features, and the success measurement.
As this example illustrates, you can happily combine OKRs and outcome-based product roadmaps, as long as the roadmap goals are SMART, that is, specific, measurable, achievable, relevant, and time-bound.[5]
What can we take away from the above discussion? First, understanding the connection between OKRs and product roadmaps can help you move away from feature-based plans towards goal-oriented ones—something I highly recommend.
If your company uses OKRs, you can argue that an outcome-based roadmap brings you in line with the goal-directed planning approach used throughout the business. You may even consider using an OKR-based roadmap like the one in Figure 2 if this makes it easier to stop using feature-based roadmaps. Be aware, though, that this might mean that you’ll have to work with quarterly roadmap goals.[6]
This does not necessarily have to be an issue, as I find that these goals often work well on roadmaps. But there are circumstances where you’d like to choose a shorter time frame like six weeks or two months as well as a longer one, for example, four months. The former tends to be the case when your product is young or experiences a lot of uncertainty and change. The latter applies when your product is in a steady state and benefits from incremental enhancements rather than bigger changes.[7]
Second, it directs your attention to the question of where the outcomes or objectives should come from. It’s not uncommon in my experience that stakeholders and senior managers determine the roadmap content: The individuals essentially tell the person in charge of the product what to put on their roadmap. This approach, however, is problematic. Not only does it disempower product people and product teams. It can also create a Frankenstein product—an offering that is a collection of unrelated features, offers a terrible value proposition, and gives rise to a horrible user experience.
A better way to determine the right roadmap goals is using an overarching product strategy, as Figure 4 shows.[8]
The product strategy in Figure 4 describes the approach you’ve chosen to achieve product success. It captures key decisions including the needs the product should address, the users and customers who should benefit from it, the business benefits it should generate, and the standout features that are required to set itself apart from competing offerings.[9]
The product roadmap takes the strategy as input and states how it will be implemented in the next, say 12 months. Its goals and objectives consequently have to be aligned with the strategy. To achieve this, you have two options—which I discuss in more detail in my book Strategize:
First, you can derive the roadmap goals directly from the needs and business goals by breaking them into subgoals. Second, you can use your key performance indicators (KPIs) to discover roadmap goals such as improving engagement and removing technical debt. In this case, make sure that the goals help you indeed make progress towards the overarching strategic goals.
Using a longer-term product strategy and deriving specific intermediate goals from it is not dissimilar to how OKRs are used to set organisational goals. The top-level OKRs are usually derived from the business strategy—or “mission” as it was referred to when I worked at Intel. If you apply a similar approach at your company, then this should help you mirror the organisational planning approach for your product and build a product roadmap that is based on the product strategy rather than individual stakeholder requests.[10]
Can you use OKRs on a product roadmap? Yes, most certainly. Should you use them in your plan? It depends. If it helps you move from feature-based to outcome-based roadmaps and embrace a goal-oriented product planning approach, then the answer is yes. Employing an OKR-based roadmap like the one in Figure 2 is likely to be beneficial for you. Otherwise, don’t worry. You can simply regard the outcome on the roadmap as the objective and the other elements as the key results—if OKRs matter to you and your organisation.
[1] See John Doerr, Measure What Matters, p. 7, and Christina Wodtke, Radical Focus, 2nd ed., p. 101.
[2] OKRs were invented at Intel in the 1970ies and became more widely used after Google started to adopt them from 1999 onwards, see John Doerr, Measure What Matters.
[3] See Roman Pichler, Strategize, 2nd ed., p. 146.
[4] For simplicity’s sake, Figure 3 uses only a single goal. See the article The GO Product Roadmap for a roadmap example with multiple goals.
[5] As I discuss in the article Should Product Roadmaps Have Dates, showing dates and specific time frames is usually helpful on internal roadmaps, which guide and align stakeholders and teams. If you work with a public product roadmap, then I advise using vague time frames such as in the second half of 2004 or in 2025.
[6] OKRs are usually set for a quarter, see Radical Focus, 2nd ed., p. 102. A product strategy, in contrast, covers a longer period, for example, one to two years for digital products.
[7] That’s typically the case when a product has entered the maturity stage.
[8] Figure 4 shows part of my product strategy model.
[9] Note that I assume that the product strategy has been validated, that is, that its statements do not contain any significant risks and assumptions and are backed up by empirical evidence. See my book Strategize for more advice on strategy validation.
[10] See the article The Strategy Stack for advice on how to connect the business and product strategies.
It may not be pleasant to experience, but conflict is necessary to innovate successfully. Without…
Developing a winning product strategy is hard. Keeping the strategy relevant and achieving continued product…
The product roadmap is a popular product management tool that communicates how a product is…
The product strategy is probably the most important artefact in product management. But how do…
A product team is a cross-functional group whose members work together to achieve product success.…
The most amazing product strategy and product roadmap are ineffective if the stakeholders don’t support…
View Comments
Love this and thanks for sharing. A few years ago I was lucky to be part of a massive transition of a very large airline moving from project-based work to product-based work. One of the things we introduced is similar to, but not quite as tidy as your proposal above. We called it OKRoadmaps.
Business defined Objectives and Key results were laid out. Then the product teams collaborated on ideas (experiments) they could run to address these Key Results. We evaluated these experiments with the stakeholders (including customers) to determine which bets we thought had the highest chance of paying off.
We then separated them into buckets (Qnow, Q+1, Q+2, Q+++). We'd meet quarterly to evaluate our progress on the KRs and determine if the KRs were achieved or not and if we should continue focusing on them. We generally agreed that Objectives should have a yearly scope but this was not a rule. We then determined which of our experiments were complete, which should be abandoned, which should be added and which should move left.
We would then meet briefly, each month (or as needed at any time), to discuss our learnings and any pivots we should make to the plan.
I really enjoyed working in this fashion, and I've secretly hoped that "OKRoadmap" would catch on!
You're welcome, Dana, and thanks for sharing your feedback and experience with OKR-based roadmaps. It's great to hear that you enjoyed the article and that combining OKRs and roadmaps worked well for you.