Set your OKRs such that they state what the business needs and that they leave enough room for interpretation and creativity.Otherwise, if you set prescriptive OKRs, you'll turn them into a micromanagement tool and you'll take away the autonomy of your team.Example of how to set an objective:<ul><li>Good: Increase onboarding conversion rate ← It mentions what needs to be done and it's up to the team how to do it.</li><li>Bad: Make the onboarding flow better ← It limits the team to perfecting the in-app experience, and doesn't leave room to look at pricing, packaging, e-mails etc.</li></ul>

Objectives for autonomous teams

Imagine you landed on a new shore and the crew were tasked with finding food for the night. That would be achievable. Maybe they go hunting. Perhaps they go foraging. Maybe they set up traps. As long as you’re not picky, you’ll all get fed.However, if the leader of the journeying crew said the objective was to get a steak dinner, the team would have likely missed great opportunities for other edible options, and everyone would have gone hungry.

Example of a bad objective

<figure><img width="361" height="209" src="https://www.prodpad.com/wp-content/uploads/2020/06/Roadmap-Building-Image.svg" alt="OKRs and the lean roadmap"></figure><h1>4. How OKRs and lean roadmapping work together</h1><a href="https://www.prodpad.com/features/portfolio-management/objectives-and-key-results/" dir="ltr">OKRs</a> and roadmaps work beautifully together, and are a perfect replacement for the <a href="https://www.prodpad.com/resources/guides/ditch-the-timeline-roadmap/the-trouble-with-traditional-timeline-roadmaps/" rel="noopener" dir="ltr">outdated timeline roadmap</a> way of working.&nbsp;OKRs are a framework for setting and measuring objectives, which as we already covered earlier in this guide, are a <a href="https://www.prodpad.com/resources/guides/ditch-the-timeline-roadmap/intro-to-lean-roadmapping/#h-objectives-on-a-lean-roadmap" rel="noopener" dir="ltr">key ingredient in your lean roadmap</a>. OKR stands for Objectives and Key Results, and it’s these two elements that help give your roadmap structure and purpose. After all, if you’re doing things on your roadmap that don’t serve any sort of objective for the business, why are they on the roadmap?<h2>O(I)KRs</h2>When thinking about OKRs and roadmaps together, it’s important to remember the missing middle child between Objectives and Key Results: Initiatives.&nbsp;An initiative describes the specific activities or projects the team is working on to influence the success of an OKR, and lives squarely in the roadmap space.Even if you identify what you need to achieve (the Objective) based on the company strategy, and determine what good looks like (the Key Result), you’re not going to get very far if you’re unable to clearly communicate the actions you plan to take in order to get there (the Initiative). This is why mapping Initiatives out on a roadmap helps you communicate how you’ll hit your objectives and solve problems for the business.&nbsp;<figure><picture loading="lazy" class="wp-image-9492">
<source type="image/webp" srcset="https://www.prodpad.com/wp-content/uploads/2021/03/okrs1-1024x179.png.webp 1024w, https://www.prodpad.com/wp-content/uploads/2021/03/okrs1-300x52.png.webp 300w, https://www.prodpad.com/wp-content/uploads/2021/03/okrs1-768x134.png.webp 768w, https://www.prodpad.com/wp-content/uploads/2021/03/okrs1-1536x268.png.webp 1536w, https://www.prodpad.com/wp-content/uploads/2021/03/okrs1.png.webp 1600w" sizes="(max-width: 580px) 100vw, 580px">
<img src="https://www.prodpad.com/wp-content/uploads/2021/03/okrs1-1024x179.png" alt="OKRs work best when used with initiatives to make OIKRs" width="580" height="101" srcset="https://www.prodpad.com/wp-content/uploads/2021/03/okrs1-1024x179.png 1024w, https://www.prodpad.com/wp-content/uploads/2021/03/okrs1-300x52.png 300w, https://www.prodpad.com/wp-content/uploads/2021/03/okrs1-768x134.png 768w, https://www.prodpad.com/wp-content/uploads/2021/03/okrs1-1536x268.png 1536w, https://www.prodpad.com/wp-content/uploads/2021/03/okrs1.png 1600w">
</picture><figcaption dir="auto">Adding an initiative makes the OKR actionable</figcaption></figure><h2>Time-based planning and OKRs</h2>OKRs are usually time-bound. Most often, top-level OKRs are reviewed annually, whereas department and team level OKRs are reviewed quarterly. This is a pretty good cadence as it’s typically enough time to see sufficient experimentation and iteration, but not so long that the team dwells on diminishing returns.&nbsp;If an Objective needs to be extended, the business can always make the decision to work on it for a longer period, as the end of the quarter nears.&nbsp;As this guide has already explored, a lean roadmap itself isn’t time-bound. It’s all about setting the sequence of initiatives and outlining experiments that could be tackled in order to solve for each.&nbsp;This combination of time-bound objectives with flexible experimentation-driven work is where the magic happens. It gives the best blend of alignment and autonomy for your team.Using the OKR framework, management sets the top-level Objectives and Key Results for the company, and department managers set department or team level Objectives that cascade from the top-level objectives. This allows management to communicate what success looks like for the business, and what sort of needles have to be moved in order to succeed.&nbsp;For example, management might indicate that it’s important to increase revenue from a particular market segment, or to tackle a critical but underperforming user journey or conversion flow.&nbsp;In the old way of working with timeline roadmaps, management may have identified these but expected the product team to outline the specific initiatives that would be done and by when. This means that the product team is left scrambling to try to come up with a plan to show to management that they can solve the problem, and usually ends up throwing a number of feature ideas at a roadmap and wasting time getting well-buffered estimates that they can ‘safely’ commit to. At the end of the day, that product team has made a lot of assumptions up front, and locked themselves into work that may or may not have been the right path, all while spending unnecessary time doing up-front project planning work that could have been avoided. Planning a quarter’s worth of work up front is an incredibly difficult task when working in uncharted terrority like product management.&nbsp;<h2>Lean roadmapping and OKRs</h2>With lean roadmapping, the product team acknowledges the Objectives, which they should be on board with as they took part in the conversations to help set them, and then commits to spending the next quarter finding ways to tackle them.&nbsp;&nbsp;At the point where OKRs are set, the team doesn’t know up front what features will be built or when. They probably have a bunch of hypotheses and ideas to test. But they do know that they have 3 months to run as many experiments as possible, and to iterate, measure, and learn along the way. This flexibility and guidance is why the lean roadmap is used as <a href="https://www.prodpad.com/resources/guides/ditch-the-timeline-roadmap/intro-to-lean-roadmapping/#h-experimenting-on-a-lean-roadmap" rel="noopener" dir="ltr">a tool to help see and plan experiments</a>.&nbsp;Instead of spending all that time trying to get estimates for work that may or may not have an impact, the team focuses on floating the experiments that are most likely to have an impact (and take the least time – ie. Quick Wins) to the top, and getting through considerably more work as a result.&nbsp;At the end of the quarter, not all of the experiments attached to Initiatives that impact that Objective will be done, but almost certainly, enough will have been done to learn a lot about the problems at hand, and to have moved the Key Results in the right direction.This concept of not doing all of the experiments outlined on the roadmap is actually a strength of the lean roadmapping process. Feature-focused roadmaps give a view that insinuates that each feature needs to be built before you move on to the next thing in the list.&nbsp;Lean roadmapping simply asks that your team focuses on solving key problems by tackling as many of the most impactful experiments as possible, and at the end of the quarter, review and decide if the other experiments are worth trying. Often, you’ll find that you’ve solved most of the problem by completing just a fraction of the potential experiments. You and your team can now decide if it’s worth going back in to solve the rest of the problem, or switching gears and tackling a different problem that’s now more pressing. This way of working is simply less wasteful. It’s why it’s called lean roadmapping!&nbsp;<h2>Autonomy + Alignment</h2>Using OKRs and lean roadmaps give your team the best blend of autonomy and alignment.&nbsp;Your execs are able to give clear direction on the core drivers of success and make sure the team is pointed in the right direction. This drives alignment.But the flexibility of the experimentation-driven roadmap gives autonomy, as it allows the team to work out the best way to solve the problems outlined.It also unlocks a huge amount of opportunity for the company. Many companies are stuck with knowledge bottlenecks, where key decisions are held by middle management and up. Using OKRs and lean roadmapping makes use of the collective knowledge of everyone in the business, including those closest to the customers, to the tech, and to the market.&nbsp;There’s no wonder that teams who use OKRs and roadmaps together wildly outperform teams who are IT project driven.&nbsp;<h2>OKRs and lean roadmaps create high performing teams</h2>Good objectives should leave enough room for interpretation.&nbsp;Put it this way, if you landed on a new shore, and the crew were tasked with finding food for the night, that’s achievable. Maybe they go hunting. Perhaps they go foraging. Maybe they set up traps. As long as you’re not picky, you’ll all get fed.If your company has an Objective around getting your onboarding conversion rate up, then it’s important for management not to dictate how it’s done, just that it does need to be done. By leaving flexibility you might find that the best experiments surprise you. Perhaps the most impactful things had nothing to do with features you’d initially thought were going to make a difference, but instead were around tweaks to pricing or packaging. Or perhaps it wasn’t a change to the app itself, it was an update to the onboarding emails that had the biggest punch.&nbsp;In the end, the answer may have very little to do with how the product works, and very little to do with your team’s initial assumptions around what the solutions are.&nbsp;If the Objective had been more prescriptive, saying something like “Make the onboarding flow better”, you can imagine a team getting lost in perfecting the in-app experience and not daring to look around.Likewise, if the leader of the journeying crew said the objective was to get a steak dinner, the team likely would have missed great opportunities for other edible options, and everyone would have gone hungry.&nbsp;This is one of the big gotchas of OKRs, or frankly of any objective or goal system. It’s what went wrong with KPIs. If not used properly, they can take away autonomy. They just became a tool to micromanage with, rather than a way to set goals for what the business needs, and a way to let the team bring their best skills to the table to meet those needs.To get the best blend of autonomy and alignment, remember that there are lots of paths forward, and so leave room for interpretation and creativity.<h2>Everyone else is doing it</h2>This approach might seem a bit novel, but keep in mind that other divisions around your company are already operating in this way.&nbsp;Take sales, for example. Your VP of Sales doesn’t make a report of exactly which sales are going to land, from which customers, and when. That would be unrealistic, and even the execs know it.&nbsp;Instead, the sales team is given targets that are akin to OKRs (“Go get the APAC market” is an Objective; “Close $2m in new business” is a Key Result), and then has their own experimentation-driven way of working that’s not dissimilar to what any product team would aspire to.After all, what is a sales call or outbound email, if not an experiment of sorts? The sales team doesn’t know which calls are going to work, but they know that if they do a bunch of calls, and focus their efforts on calls to prospects who are easier to reach and likely higher value (think: Quick Wins), then some of those calls will result in success. Just like how running many experiments, especially if you focus on the ones that are likely to be more impactful and easier, will eventually lead to numbers moving in the right direction.&nbsp;Your sales team doesn’t have a roadmap stating who’s going to buy and when. They have a pipeline, where they indicate with various levels of certainty where prospects are in the flow, and therefore how they are progressing with their overall goals.&nbsp;Marketing is another example of an experimentation-driven division. Have you ever heard the quote “Half the money I spend on advertising is wasted; the trouble is I don’t know which half.”? It’s an old saying, but it still rings true today. Most marketing campaigns are essentially just a series of experiments. They don’t know who is going to respond or click to any given piece of marketing work, but they can provide detailed reporting on what is being tried, what’s worked in the past, and what iterations are being tried to improve various metrics.If sales and marketing can find a way to work in a lean, experimentation-driven way, then so can your product team.<OL><LI><UL><LI>Roadmap is a prototype for your strategy</LI><LI>Roadmapping is a process</LI></UL></LI><LI><UL><LI>Time horizons, not timelines</LI><LI>Focus on solving problems</LI><LI>Objectives on a lean roadmap</LI><LI>Product vision and your roadmap</LI><LI>Putting together a lean roadmap</LI><LI>Experimenting on a lean roadmap</LI><LI>Validating outcomes on a roadmap</LI></UL></LI></OL>

OKRs and roadmaps work beautifully together, and are a perfect replacement for the outdated timeline roadmap way of working.

teamwork

Teamwork

business

Business

startup

Startups

leadershipandmanagement

Leadership & Management

4. How OKRs and lean roadmapping work together

<a href="https://www.prodpad.com/features/portfolio-management/objectives-and-key-results/">OKRs </a>and roadmaps work beautifully together, and are a perfect replacement for the <a href="https://www.prodpad.com/resources/guides/ditch-the-timeline-roadmap/the-trouble-with-traditional-timeline-roadmaps/">outdated timeline roadmap </a>way of working. OKRs are a framework for setting and measuring objectives, which as we already covered earlier in this guide, are a <a href="https://www.prodpad.com/resources/guides/ditch-the-timeline-roadmap/intro-to-lean-roadmapping/#h-objectives-on-a-lean-roadmap">key ingredient in your lean roadmap </a>. OKR stands for Objectives and Key Results, and it’s these two elements that help give your roadmap structure and purpose. After all, if you’re doing things on your roadmap that don’t serve any sort of objective for the business, why are they on the roadmap?

When thinking about OKRs and roadmaps together, it’s important to remember the missing middle child between Objectives and Key Results: Initiatives.

An initiative describes the specific activities or projects the team is working on to influence the success of an OKR, and lives squarely in the roadmap space.

Even if you identify what you need to achieve (the Objective) based on the company strategy, and determine what good looks like (the Key Result), you’re not going to get very far if you’re unable to clearly communicate the actions you plan to take in order to get there (the Initiative). This is why mapping Initiatives out on a roadmap helps you communicate how you’ll hit your objectives and solve problems for the business.

OKRs are usually time-bound. Most often, top-level OKRs are reviewed annually, whereas department and team level OKRs are reviewed quarterly. This is a pretty good cadence as it’s typically enough time to see sufficient experimentation and iteration, but not so long that the team dwells on diminishing returns.

If an Objective needs to be extended, the business can always make the decision to work on it for a longer period, as the end of the quarter nears.

As this guide has already explored, a lean roadmap itself isn’t time-bound. It’s all about setting the sequence of initiatives and outlining experiments that could be tackled in order to solve for each.

This combination of time-bound objectives with flexible experimentation-driven work is where the magic happens. It gives the best blend of alignment and autonomy for your team.

Using the OKR framework, management sets the top-level Objectives and Key Results for the company, and department managers set department or team level Objectives that cascade from the top-level objectives. This allows management to communicate what success looks like for the business, and what sort of needles have to be moved in order to succeed.

For example, management might indicate that it’s important to increase revenue from a particular market segment, or to tackle a critical but underperforming user journey or conversion flow.

In the old way of working with timeline roadmaps, management may have identified these but expected the product team to outline the specific initiatives that would be done and by when. This means that the product team is left scrambling to try to come up with a plan to show to management that they can solve the problem, and usually ends up throwing a number of feature ideas at a roadmap and wasting time getting well-buffered estimates that they can ‘safely’ commit to. At the end of the day, that product team has made a lot of assumptions up front, and locked themselves into work that may or may not have been the right path, all while spending unnecessary time doing up-front project planning work that could have been avoided. Planning a quarter’s worth of work up front is an incredibly difficult task when working in uncharted terrority like product management.

With lean roadmapping, the product team acknowledges the Objectives, which they should be on board with as they took part in the conversations to help set them, and then commits to spending the next quarter finding ways to tackle them.

At the point where OKRs are set, the team doesn’t know up front what features will be built or when. They probably have a bunch of hypotheses and ideas to test. But they do know that they have 3 months to run as many experiments as possible, and to iterate, measure, and learn along the way. This flexibility and guidance is why the lean roadmap is used as <a href="https://www.prodpad.com/resources/guides/ditch-the-timeline-roadmap/intro-to-lean-roadmapping/#h-experimenting-on-a-lean-roadmap">a tool to help see and plan experiments </a>.

Instead of spending all that time trying to get estimates for work that may or may not have an impact, the team focuses on floating the experiments that are most likely to have an impact (and take the least time – ie. Quick Wins) to the top, and getting through considerably more work as a result.

At the end of the quarter, not all of the experiments attached to Initiatives that impact that Objective will be done, but almost certainly, enough will have been done to learn a lot about the problems at hand, and to have moved the Key Results in the right direction.

This concept of not doing all of the experiments outlined on the roadmap is actually a strength of the lean roadmapping process. Feature-focused roadmaps give a view that insinuates that each feature needs to be built before you move on to the next thing in the list.

Lean roadmapping simply asks that your team focuses on solving key problems by tackling as many of the most impactful experiments as possible, and at the end of the quarter, review and decide if the other experiments are worth trying. Often, you’ll find that you’ve solved most of the problem by completing just a fraction of the potential experiments. You and your team can now decide if it’s worth going back in to solve the rest of the problem, or switching gears and tackling a different problem that’s now more pressing. This way of working is simply less wasteful. It’s why it’s called lean roadmapping!

Using OKRs and lean roadmaps give your team the best blend of autonomy and alignment.

Your execs are able to give clear direction on the core drivers of success and make sure the team is pointed in the right direction. This drives alignment.

But the flexibility of the experimentation-driven roadmap gives autonomy, as it allows the team to work out the best way to solve the problems outlined.

It also unlocks a huge amount of opportunity for the company. Many companies are stuck with knowledge bottlenecks, where key decisions are held by middle management and up. Using OKRs and lean roadmapping makes use of the collective knowledge of everyone in the business, including those closest to the customers, to the tech, and to the market.

There’s no wonder that teams who use OKRs and roadmaps together wildly outperform teams who are IT project driven.

OKRs and lean roadmaps create high performing teams

Good objectives should leave enough room for interpretation.

Put it this way, if you landed on a new shore, and the crew were tasked with finding food for the night, that’s achievable. Maybe they go hunting. Perhaps they go foraging. Maybe they set up traps. As long as you’re not picky, you’ll all get fed.

If your company has an Objective around getting your onboarding conversion rate up, then it’s important for management not to dictate how it’s done, just that it does need to be done. By leaving flexibility you might find that the best experiments surprise you. Perhaps the most impactful things had nothing to do with features you’d initially thought were going to make a difference, but instead were around tweaks to pricing or packaging. Or perhaps it wasn’t a change to the app itself, it was an update to the onboarding emails that had the biggest punch.

In the end, the answer may have very little to do with how the product works, and very little to do with your team’s initial assumptions around what the solutions are.

If the Objective had been more prescriptive, saying something like “Make the onboarding flow better”, you can imagine a team getting lost in perfecting the in-app experience and not daring to look around.

Likewise, if the leader of the journeying crew said the objective was to get a steak dinner, the team likely would have missed great opportunities for other edible options, and everyone would have gone hungry.

This is one of the big gotchas of OKRs, or frankly of any objective or goal system. It’s what went wrong with KPIs. If not used properly, they can take away autonomy. They just became a tool to micromanage with, rather than a way to set goals for what the business needs, and a way to let the team bring their best skills to the table to meet those needs.

To get the best blend of autonomy and alignment, remember that there are lots of paths forward, and so leave room for interpretation and creativity.

This approach might seem a bit novel, but keep in mind that other divisions around your company are already operating in this way.

Take sales, for example. Your VP of Sales doesn’t make a report of exactly which sales are going to land, from which customers, and when. That would be unrealistic, and even the execs know it.

Instead, the sales team is given targets that are akin to OKRs (“Go get the APAC market” is an Objective; “Close $2m in new business” is a Key Result), and then has their own experimentation-driven way of working that’s not dissimilar to what any product team would aspire to.

After all, what is a sales call or outbound email, if not an experiment of sorts? The sales team doesn’t know which calls are going to work, but they know that if they do a bunch of calls, and focus their efforts on calls to prospects who are easier to reach and likely higher value (think: Quick Wins), then some of those calls will result in success. Just like how running many experiments, especially if you focus on the ones that are likely to be more impactful and easier, will eventually lead to numbers moving in the right direction.

Your sales team doesn’t have a roadmap stating who’s going to buy and when. They have a pipeline, where they indicate with various levels of certainty where prospects are in the flow, and therefore how they are progressing with their overall goals.

Marketing is another example of an experimentation-driven division. Have you ever heard the quote “Half the money I spend on advertising is wasted; the trouble is I don’t know which half.”? It’s an old saying, but it still rings true today. Most marketing campaigns are essentially just a series of experiments. They don’t know who is going to respond or click to any given piece of marketing work, but they can provide detailed reporting on what is being tried, what’s worked in the past, and what iterations are being tried to improve various metrics.

If sales and marketing can find a way to work in a lean, experimentation-driven way, then so can your product team.

<ol><li><ul><li>Roadmap is a prototype for your strategy </li><li>Roadmapping is a process </li> </ul> </li><li><ul><li>Time horizons, not timelines </li><li>Focus on solving problems </li><li>Objectives on a lean roadmap </li><li>Product vision and your roadmap </li><li>Putting together a lean roadmap </li><li>Experimenting on a lean roadmap </li><li>Validating outcomes on a roadmap </li> </ul> </li> </ol>

Autonomy in OKRs

Objectives for autonomous teams

Example of a bad objective

Ovidiu Podariu's ideas are part of this journey:

Related collections

Similar ideas