Building Effective Product Roadmaps

Hey I’m Ant and welcome to my newsletter where you will find actionable posts on topics related to product, business and leadership.

You might have missed these recent posts::
- Long Backlogs and Unmeasurable Work
- Break Outcomes Down, Not Initiatives
- The Process to Building a Great Product Strategy

My day job is helping companies shift to a Product Operating Model. My evening job is helping product people master their craft with Product Pathways.

---

Last week, over 300 passionate product people joined me live for a free webinar on ‘Building Effective Product Roadmaps’ (the recording is below).

I want to share the results of the polls I ran during the webinar and figured, why not do a summary of the key points too.

Let’s get into it!

FYI I run free webinars every month. ​Follow Product Pathways to find out about future events. You can find past recordings here.

Roadmaps vs Plans

The first thing I want to clarify is the difference between a Roadmap and a Plan.

This is something I’ve recently found myself needing to clarify a lot with my more traditional clients.

So, what’s the difference between a roadmap and a plan?

I like to frame it this way:

Roadmaps:

• Look at a long-time horizon.

• They are flexible and iterative.

• Describe the WHAT and the WHY (not the HOW or WHEN).

• Customer-centric and outcome-focused.

• A communication tool.

Plans, on the other hand, are:

• More short-term. They look at the near horizon.

• Are more static and sequential, as they need to deal with things like sequencing, dependencies, etc.

• Describe the HOW and WHEN

• Internally focused, a tool for internal use, not the customer.

• Therefore, it is more output-focused.

• A planning tool.

Roadmaps vs Plans with annotations from the webinar

By no means is this an either-or.

Don’t go drinking too much 'agile cool-aid’ now and think that plans are somehow anti-agile.

In fact, planning is something you do more of with agile.

Plans are good practice.

They are a helpful tool.

I couldn’t imagine trying to manage a product launch, GTM, release, event, etc, without at least some kind of skeleton plan.

But plans are a tool for managing things like dependencies, sequencing, and actually determining how we intend to get something done.

And yes, no plan survives contact with the enemy, but that’s why we plan just in time. We focus on the near term, where the cone of uncertainty is narrow (more on this in a minute), and we also continuously reflect and adjust.

This is the notion of continuous planning rather than big upfront plans that try to predict along a long time horizon.

But I digress.

The point is that it is a completely different activity from road mapping.

Roadmaps, on the other hand, are a communication tool.

They are a tool for communicating the future direction of the product, as it aligns with your vision and strategy.

Product Roadmaps communicate the future direction of the product.

Let me describe it this way.

You are likely already doing planning activities like Quarterly or Sprint Planning.

Of course, your Product Roadmap is an input into those planning activities, just like you do with your product backlog, OKRs, goals, strategy, etc.

However, planning is not the primary intent of your backlog or strategy.

That doesn’t mean they can’t be an input into planning, nor that the outcome of planning might have an impact on them.

And roadmaps are very much the same.

Their primary intent (in my opinion - happy to be wrong on this one) is as a communication tool.

You use your roadmaps to communicate the future direction of your product with your stakeholders.

But this doesn’t stop your roadmap from being an input into activities like quarterly planning, nor does it void the need to update your roadmap as a consequence of decisions made during planning activities - just like you would with your backlog, OKRs or strategy.

Now, none of this is helped by poorly designed and named tools like Jira Plans.

Which, many of you might remember it being called ‘Jira Advanced Roadmaps’ for a long time.

I always felt that Jira Advanced Roadmaps (now Plans) was poorly named as it was a Planning tool, not a Roadmap - good to see that corrected.

Of course, full credit to Atlassian for their recent update and correcting the name from Advanced Roadmaps to Plans.

Rightly so, as it was always a planning tool, not a Roadmap.

FYI Atlassian now points you to their new Jira Product Discovery for Roadmaps, which has a proper road mapping tool - glad to see these changes come into effect (it’s saved me a lot of arguments with clients about roadmaps vs plans haha)

In fact, their online guide has this table to clarify the difference.

Again, you can see the clear distinction between Roadmaps and Plans.

Table from Jira Product Discovery guide explaining the difference between Jira Product Discovery and Jira Software showing the clear diliniation between roadmapping vs planning.

Elements of a Great Product Roadmap

When I work with clients, and I look at their product roadmaps, I’m immediately looking for a few things:

1. Outcomes: Does the product roadmap describe the outcome that you’re trying to achieve? This could be through representing your OKRs, linking the work to specific KRs, or even simply describing an outcome product goal.

2. Features vs Opportunities: Is the roadmap a long list of features, or does it also include things like opportunities and problem spaces?

3. Short-term vs long-term work: Does the product roadmap balance long-term vs short-term work?

4. Flexibility: Is the product roadmap designed in a way in which it is flexible?

I really want to hone in on the last one.

Flexibility doesn’t just mean avoiding hard dates and using formats like Now-Next-Later.

I’ve seen plenty of product roadmaps that use Now-Next-Later, and they’re still a long laundry list of features to build with no coherence or customer outcomes.

The only flexibility is in WHEN - not HOW.

To help explain this, I want to introduce a concept known as the cone of uncertainty.

For illustrative purposes, I’m going to draw it backwards.

Sketch of the cone of uncertainty. Screenshot from last week’s webinar.

The cone of uncertainty illustrates that the further away something is in the future, the more uncertainty there is.

For example, if you asked me where I would be in March 2027, there’s a high chance my guess would be wrong. I might move house, be overseas on holiday, or travelling for work even - who knows!

However, if you asked me where I would be tomorrow, there’s a high chance I would be correct in saying that I would be WFH unless something urgent and unexpected happened.

But the uncertainty is much less.

In fact, the sheer number of variables is significantly less between today and tomorrow as compared to today vs 3 years from now.

Why am I explaining all this?

Well, this is an important mental model for us to consider when creating our roadmap.

Of course, this is a key reason why we want to avoid hard dates, but this doesn’t stop you from having dates either.

Poll results from last week’s webinar on Product Roadmaps.

I can’t say I was surprised when I polled the audience during the webinar and found that Timeline Roadmaps came out on top.

You won’t find me preaching that Roadmaps shouldn’t have dates.

Of course, I would advise against having dates and likely tell you to read this brilliant thread from Janna Barstow, the CEO and Founder of ProdPad first.

But I understand that for many companies, no dates at all is a leap too far, and let’s be honest, there are circumstances where it makes sense.

However, if we are going to put dates on our roadmap, we want to do it in a way that takes the cone of uncertainty into account.

For example, we should aim to have shorter, more precise time horizons in the near term.

And have broader time horizons in the long term.

A common example is to use quarters at the start and then shift them to ‘half-years’ and full years/beyond.

Dates getting broader as the cone of uncertainty gets wider. Screenshot from last week’s webinar.

By doing so, we still have a level of flexibility.

Of course, this is less than if we didn’t have the dates, but we’re still not saying exactly when something will be done.

If we put it in Q2, we’re not saying when in the quarter - it could be in the first week or the last.

But we’re giving some indication that we believe we should get it done in the quarter.

Adding Opportunities to the Roadmap

Now, dates aren’t the only thing that changes.

‘WHAT’ we put on the roadmap should also reflect the cone of uncertainty.

We do this by having more concrete items in the near term, often in the form of Features.

And less clear items further out, such as Opportunities.

Opportunities are less concrete because we’re not describing exactly WHAT we’re going to deliver. Instead, we’re saying that these are some opportunities that we would like to look into.

When the time comes, we will discover these opportunities, validate them, and either discard them or find a solution to them.

At that point, the opportunity will turn into features on the roadmap and move into the near term.

Visualising more concrete roadmap items, like features, at the start of the cone of uncertainty and getting less concrete later (ie opportunities). Screenshot from last week’s webinar.

Here’s an example that pulls all this together.

The roadmap comes from a Productboard article from 2017, but it’s a good one to illustrate these concepts. Plus, it’s hard for me to use examples from my clients publicly, as it’s not exactly something I’m allowed to share.

Example Product Roadmap that covers most of the elements I talked about. Credit to Productbaord for the example roadmap.

Tailor Your Product Roadmap to the Audience

The last thing I want to cover is the notion of tailoring your Product Roadmap to the audience.

Since Product Roadmaps are a communication tool, we should really be considering WHO the consumer is.

In most cases, product managers will have different stakeholders with different needs.

For example, the level of information that executives want (or should have) will be different than what dependent teams need.

It’s therefore common for me to have 3 different versions of my Product Roadmap.

1. High-level view for senior execs

2. A market-facing view for teams such as sales, customer success, and marketing

3. and a more detailed view for the team, my direct manager, and peers.

I polled the audience to see who else does this and found that 36% of you did.

However, the majority (64%) had only one version of their product roadmap.

Poll results from the webinar on Product Roadmaps. 

While having different versions of your roadmap isn’t mandatory, I’ve found it to be a good practice.

Really, what you’re trying to do here is influence.

If I can visualize my roadmap in a way that communicates more effectively, then I have a better chance of creating alignment and buy-in.

Of course, if you can achieve all this and even the planning aspects with the one Product Roadmap, then more power to you.

However, I’m still yet to see that done effectively.

Rather, what I see are convoluted roadmaps that attempt to do everything for everyone but don’t do any one thing well.

At the end of the day, a Product Roadmap is a communication tool.

And if you want to communicate effectively, it requires tailoring your message to the audience.

It’s less work than it looks, but I also see this as the tax you pay to communicate well and influence others.

---

Need help with scaling your product or business? I can help in 4 ways::

1. Level up your craft with self-paced deep dive courses, FREE events and videos on YouTube, templates, and guides on Product Pathways.

2. 1:1 Coaching/Mentoring: I help product people and founders overcome challenges through 1-hour virtual sessions.

3. Consulting and Advisory: I help companies drive better results by building effective product practices.

4. Private Workshops and Training: I run practical workshops and training courses for product teams globally.

---