Recently, I had the pleasure of (virtually) meeting Marty Cagan from the Silicon Valley Product Group and author of the seminal product management book, Inspired. One of his key messages during a Q&A session was that product teams waste so much time developing and estimating feature roadmaps, when they should be focused on build, measure, learn cycles. That is, focus on product outcomes, their priority, and buy time until you have data-informed tactics.

This does a couple of things:

1. You learn what really matters to users faster
2. You avoid unwanted feature bloat

You can read more about Marty’s thoughts on this here and here.

Bottom line: the intent of a feature in a roadmap can be interpreted subjectively, and as a result we have seen teams drift from their original goal during execution. Whereas an outcome on a roadmap is unambiguous, offering a constant reminder of your desired goal throughout your delivery cycle.

Examples of drift range from:

• Anecdotal thesis: starting a project without success metrics
• Product bloat : having clear measures for success, but deviating due to over investment and sheer momentum
• Goal posts: feature scope shifts yet the measures unchanged
• Never ending story: delivery time extends with no recognition of the original desired result and in turn checks and balances for incremental delivery

We spend a lot of time reviewing product roadmaps with our portfolio companies at Tidal and many more in review sessions over my lifetime a product leader. We tend to run into this issue consistently. So we created a practical guide on developing a connected roadmap that leans on complementary artefacts to address the goals above.

Overview

Here is a visual map of how we will progressively leverage a set of common artefacts to achieve a connected roadmap:

Goals pre-flight check

Before getting started on a roadmap, we need some guidance from leadership. Your company goals form this guidance. We will use the OKR (Objectives & Key Results) format to frame them with a business lens.

This is what it might look like:

Use this checklist to inform your roadmap:

• Focus Areas: Does the OKR call out your team(s) as a dependency to achieve the goal? We recommend defining Focus Areas per OKR to set expectations for accountability and provides an opportunity to have a conversation about resourcing.
• Focused Key Result: Does each Objective have one primary Key Result? A secondary Key Result should only be used to help qualify the effort. This helps reduce unambiguity and will align behavior. An example of a primary key result would be improving sales efficiency from $x to $y, with a complementary qualifying objective that maintains your conversion rate at a floor of z%.
• Ordered Objectives: Are the OKRs an ordered list? This forces leadership to prioritize the bets the company is taking; just like you need to prioritize your roadmap. Guaranteed these priorities will be tested throughout the time span and it’s best to understand those trade-offs early.

Finally, are the company OKRs you are accountable for grounded in rational optimism? You want to be ambitious, but it needs to be coupled with a reality check that considers cadence, dependencies, and the timespan for achieving the result. While this is not specific input into building a roadmap, it's worth asking if you are set up for success?

Posing the checklist and your own situational questions helps develop a shared understanding with stakeholders and is half of the solution for aligning on value.

Now that you have tightened up the business OKRs, let's connect them to your product roadmap.

Outcomes not features

The fundamental challenge with most feature-based roadmaps is they are used to convey product strategy to stakeholders but are rarely self-explanatory. They require a talk track to explain how tactics (features) ladder up to strategy (outcomes), rather than stating the strategy itself and making it accessible. This way, your feature doesn't get in the way of your outcome. If your feature fails the goal, you can pivot without changing your high-level roadmap.

Outcome-oriented roadmaps help you defer and switch tactics while maintaining the original intent that stakeholders are aligned on:

Feature roadmap

• Improved onboarding (frames it from the user's lens; push this down one level)
• Establish a baseline conversion rate of at least 4%

versus

Outcomes roadmap

• Increase unassisted user adoption (frames it from the product lens)
• Establish baseline conversion rate of at least 4%

This is what it might look like:

Here are the ways to convert typical roadmap elements into an outcome-oriented roadmap:

1. Swimlanes: Use the business OKRs that require a direct contribution from product teams. Traditionally you would use themes, but they only serve as a narrative to your feature grouping rather than being an effective way to remind stakeholders how product strategy connects to your business objectives.
2. Timeline: I recommend using quarterly intervals if you are having some delivery cadence challenges or you are a time-driven organisation; alternatively Now, Next, Later may provide a more flexible structure for fluid development.
3. Bars: Cards should be represented as outcomes instead of features. Leave features for your Scrum or Kanban boards to build more conviction in your tactics through rapid iteration.
4. Milestones: this is an optional element, but should tie to a series of major stages

You may be thinking an outcome-oriented roadmap lacks the depth of the feature roadmap. But what you lose in detail you gain in clarity of purpose. It is the other half of the solution for aligning on value and illustrates how you intend to prioritise value delivery.

Now that you have expressed your product strategy using outcomes, let’s connect your strategic outcomes to your feature tactics.

Make it epic

In agile development, epics encapsulate a set of related stories. Often a few epics may be required to achieve a desired outcome through gradual iterations. The simple use of a progress bar within each (outcome) bar connects strategy to tactical delivery. It also enables stakeholders to track progress in delivering user value, associated with the outcome, and finally the business OKRs.

This is what it might look like:

We do not prescribe a specific agile methodology. That is very much a team decision. However techniques like User Story Mapping or Jobs to be Done are a useful methods in curating what actually gets on your backlog.

The mindset of having a groomed epic backlog should be strong opinions, loosely held. Each epic merely represents a way to capture your thesis of the user value impact for a given feature; and why it is a suitable leading indicator to the outcome's lagging indicator in your roadmap.

Here are ways to tweak a typical Scrum or Kanban board elements to connect your roadmap:

1. Columns: our recommendation is to capture select stages of your delivery cycle per column. Consider this as a more precise snapshot of a feature's delivery using a common language of your product team. For example we have seen teams track Backlog, Discovery, Build, Test, Beta, GA and added steps in between to suit their path to production. The use of a time-scale is less relevant at this level and you are better off aligning the team to your roadmap for time.
2. Cards: are simply the epics or stories/tasks that progress through each of your stages. Again it's important to iterate that having a rapid test & learn culture means not all things get to production. Being deliberate about this will help you forge a better product.
3. Tags: using tags (aka labels) helps connect an epic to an outcome. By doing this it should control the progress bar on each outcome's bar on your roadmap.

By tuning your board elements this way, you have connected to your roadmap, and in turn the company goals. Congratulations, time to celebrate.

Let’s recap the benefits of using a connected roadmap:

• You have a self-serve document that better communicates your strategy.
• Reducing communication friction allows you to spend more quality time debating the things that matter.
• Deferring tactics till slightly later in the planning cycle reduces feature bloat and speeds up your path to validating if a feature will actually deliver on a given outcome.

Thanks to Tash, Andrea, Georgie, teams at Bonjoro, Shippit, and Secure Code Warrior for contributing and reading drafts of this article.