Traditional roadmaps (and I use that phrase loosely), communicate rigid detailed plans that are not flexible enough for lean and agile product and delivery teams. They also tend to lack context that communicates the larger product vision. Instead, being myopically focused on relatively arbitrary releases.

With a high degree of frequency, I will have variations of the following conversation:

• I have a bunch of stuff in my backlog and need to create a roadmap from it.
• I have a vision for the product I want to build and need to create a roadmap from it.

There are valid reasons why you might already have a catalog of features that you think your product requires and so the need to organize those is vital, and there are also valid reasons why some start with the product vision when developing their roadmap. Let me start by saying that neither of these is wrong, but only one of them is right.

You must start with the product vision when creating roadmaps and subsequently backlogs. This is where the journey begins.

Let’s first define what we mean when we talk about product vision, roadmaps and backlogs - starting with product vision.

Product Vision

Product vision provides a lighthouse that every member of your deliver team can look to, no matter what area they are working on, to understand how their work contributes to the overall product market fit journey. The product vision communicates the impact your product will have on those who use it as well as the impact to your business.

A simple way to craft your first product vision statement is by using Geoffrey Moore positioning framework.

Your product vision should share the following primary components:

• Who you product is for - aka target customers
• What your target customers specific needs are - what problem(s) do they need to solve
• Type of product (market category) and name
• Benefits of using your product
• Unlike these other products - i.e., competitors
• Only statement that describes your products differentiation

Your product vision should communicate each of these and can be encapsulated in a positioning statement.

Here is an example:

Acme Inc. is a mail-order company which provides DIY mayhem gear for extraordinary genius’ that struggle to catch elusive Road Runners. Our line of DIY mayhem devices are guaranteed to not fail in improbable and spectacular ways! Unlike sprockets and cogs which require complex assembly, Acme’s mayhem gear is ready to use out of the box with instructions that even a genius could understand.

Crafting your product vision is a critical step that is often taken for granted, overlooked or poorly executed.

Product Mission

Not to be confused with your product vision which describes your product’s ‘what’, your product mission defines the ‘why’ and contains all of the achievable ambitions for your product. Unlike your product vision there is not a templated format to get you started, however your product mission should make your product vision immediately actionable. For example, the AbductiveReason prodct mission is: To help product people make products people want.

Roadmaps

Now how do we create a compelling product roadmap that is strategically aligned with the product vision, mission and strategy?

Again, let’s first define what we mean when discussing roadmaps; what they are and how to use them.

Roadmaps are strategic artifacts that communicate product vision and drive alignment. Roadmaps describe how you intend to achieve your product vision. It focuses on the value you intend to deliver to your customers and to your business.

I am certain you have all seen roadmaps with charts and dates, and I challenge you to derive how such an artifact conveys value to the customer or the business.

Similar to your product vision, your roadmap should focus product and delivery teams around a well-defined set of priorities. For example, if sales constantly loses deals in favor of customers choosing to “do nothing”, your roadmap should rally your teams around making it compelling to no longer do nothing and instead chose your solution to solve their problem. The number one reason many companies choose to do nothing is because they do not wish to start a new strategic project and will express that they are extremely busy, too busy in fact to roll your product out or maintain it day-to-day. A roadmap that rallies your teams around themes that make your product easier to acquire, adopt and manage will breakdown this barrier to sales and product market fit.

You will note that I said rally your team around themes and not features. This is key as simply having a roadmap with a feature such as “Implement Google SSO” misses the mark in expressing the value you need to deliver - “Reducing sign-up friction”. Additionally, focusing on a specific solution to a problem to early, in this case implementing Google SSO limits your options and destroys creativity. Great product teams embrace continuous product discovery that will allow you discover the best solution.

There is no harm in also having a rolling 3 month feature based roadmap that is used to keep focus on tactical execution, however such a roadmap should not be for widespread consumption and certainly should not be used with your sales and marketing teams to help them understand what value they need to sell on.

Developing theme-based roadmaps are the best way to articulate your product vision and drive alignment.

Every theme-based roadmap should focus on the following:

• Delivery value to your customers
• Communicating strategic organizational goals
• Unite teams around a well defined set of priorities
• Emphasize continuous product discovery

Additionally, your roadmaps must have elements of:

• Timeframes
• Themes
• Disclaimer

Remember that roadmaps can come in different styles and types. They all however must communicate some critical information such as what is coming and roughly when it will arrive. The most effective ones provide context about why by including an explicit statement of product vision and a set of value-oriented themes such as the example we gave above.

Backlogs

Clearly articulated product vision and value-oriented theme-based roadmap in hand you are ready to create your backlog(s). One last time, it’s important for us to understand what we mean by a backlog. These too come in different flavors and have different purposes.

I have encountered a fair number of teams that simply have one big backlog. This is not a great strategy as it near impossible to keep any structure around. I have also encountered teams with too many backlogs. Also problematic for many of the same reasons.

So what is a Backlog?

Backlogs are an Agile development tool consisting of an ordered list of work to be done during product development. The backlog typically consists of features (user stories and use cases), defects, tasks, and technical work, including discovery task and spikes for answering questions and gathering information. The work which is most important is ordered at the top of the backlog, while those that can be completed later are ordered to the bottom. The backlog is typically owned by the Product Owner or Product Manager.

“A Product Owner orders the work for a complex problem into a Product Backlog” - Scrum Guide

There are traditionally two backlogs:

• Product backlog - You can think of the product backlog as a tactical, task-level breakdown of the strategic plan outlined in your product roadmap.

• Sprint backlog - A sprint backlog is the set of items that a delivery team selects from its product backlog to work on during the upcoming sprint.

Not everyone will have had the opportunity to work top down from creating their vision, to defining their roadmap and breaking the roadmap down into work to be done to achieve those goals. It may be the case that you find yourself starting with a product backlog and needing to create a roadmap and in other cases you may have a vision for your product and a backlog of work to be done but either lack a roadmap or find that no one understands why things are on the roadmap. There are many reasons different companies find themselves in these scenarios and the focus at this point should be on:

1. having a clear vision for the future of your product and

2. prioritizing your backlog with a focus on

• delivering the necessary value to customers
• contributing to the broader business objectives

A well-prioritized backlog makes iteration planning easier, it communicates the work that needs to be performed, and sets expectations with internal and external stakeholders. Prioritization however consistently ranks as one of the hardest things for teams to do well. This is where the not so traditional opportunity backlog, also referred to as a discovery backlog plays a key role in your prioritization process. A discovery backlog is a prioritized set of customer problems that your product discovery team will explore during product discovery. The output of product discovery is what goes into the product backlog.

To summarize, the creation of your backlog should focus on delivering value to your customers, be rooted in your product vision and support the strategic goals of the organization. It is also worth knowing that whatever process you use to create your roadmap it will inevitably require regular updating as you continuously discover your customer’s needs.