OKRs and Product Roadmaps

OKRs—objectives and key results—are a popular goal-setting technique. But can and should you use OKRs on product roadmaps? What benefits does this approach offer and are there any drawbacks? These are the questions I’ll answer in this article.

Listen to the audio version of this article:

What are OKRs?

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.

What are Product Roadmaps?

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.

Can You Combine OKRs and Roadmaps?

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]

So What?

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 achieving 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]

TL;DR

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.

Notes

[1] See John Doerr, Measure What Matters, p. 7, and Christina Wodtke, Radical Focus, 2^nd 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, 2^nd 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, 2^nd 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.