Roadmapping Isn’t Just for Product Managers Anymore

As your IT department changes, the nature of your department’s role may transition to a strategic partner. You will find several product management techniques useful during this transformation, such as roadmapping. Once considered the domain of product managers, roadmaps are useful in various contexts. You can use a roadmap to effectively communicate and collaborate with your business partners at the beginning and throughout an IT initiative.

Here’s a look at how IT departments can take a page from the Product Management playbook and use roadmaps to effectively collaborate and communicate with their business partners.

Why IT departments use roadmaps

When you become a strategic partner to your business partners, you’ll find creating and using roadmaps very helpful. Here are some specific reasons.

Build clarity and understanding

You’ll no longer have solution requests chucked over your cubicle walls as a strategic partner. Rather, you’ll be able to have a collaborative discussion with your business partners about the problems they are trying to solve and what potential solutions might look like.

You can collaboratively build a roadmap for the initiative with your business partners to gain clarity and shared understanding about that initiative.

This collaborative effort helps you clarify why your business partners want to make a change and the potential themes and epics that could play a role in accomplishing that outcome. These themes provide strategic direction to your initiative without diving into specific details too early.

Communicate goals and intent

You can use a roadmap to communicate information about your initiative to a wider audience. Because the roadmap contains information at a broad strategic level, it’s concise enough that people can get an idea of what you’re planning to accomplish without getting bogged down with specifics.

When creating your roadmap, you’ll involve a small group of key people in the initial discussion. That means there will be several people who may be interested in your IT initiative that weren’t originally involved in those initial discussions. When you share the roadmap with them, they can get an overview of the intended benefits of your initiative, what actions are currently underway, and your plans for future efforts.

For most stakeholders, that level of detail is sufficient. There will be some who would like additional data, which is where a tool like ProductPlan comes in handy, providing custom views for different stakeholders and displaying the data most meaningful to them.

Track and communicate progress

A good roadmap is a living document that people can rely on to reflect the current state of your work.

You shouldn’t create a roadmap, present it once, and then stash it in a drawer (real or virtual). Nor should you only update it once a quarter when you have to present your current status to your executive committee.

Instead, keep your roadmap up to date regularly, so it accurately reflects what you’re currently working on and what you plan to work on next.

If you set it up properly, you may even use your roadmap as your primary means of reporting status, removing the need to create multiple different status reports for different audiences. Here again, a road mapping tool like ProductPlan can help you out.

Take the Free Roadmapping Email Course ➜

How to use roadmaps and backlogs together

If you’ve been using backlogs for any length of time, you’re probably familiar with the problem of an overflowing backlog.

This is where the backlog becomes a dumping ground for everything you could do as part of your initiative. While there’s a certain amount of comfort in having a list of to-do’s, you soon find that it’s almost impossible to discern the forest from the trees. There are too many items to manage, and it’s difficult to discern ties between highly detailed items and the broader parts of the initiative.

Fortunately, our friend, the roadmap can provide a big lift here.

The primary cause of the overflowing backlog is when you identify a bunch of low-level backlog items too early. To avoid this issue, use your roadmap as a broad overview of your initiative showing the themes and epics you’re considering.

Avoid the temptation

Avoid the temptation to dive into detail on those epics and create items in your backlog until you’re just about to work on that epic. That means your backlog does not contain any backlog items for an epic unless it shows up in the current period on your roadmap. (Or in the “Now” column of a Now – Next – Later roadmap).

When you take this approach, your roadmap provides the overall view at a strategic level, and the backlog provides a more tactical view of the current time horizon. You avoid breaking epics into user stories too early, preventing wasted effort if you decide you don’t need to do a particular epic. You also have far fewer user stories to manage on your backlog.

Because roadmaps and backlogs contain information at different levels of detail and have different audiences, you’ll be tempted to use different tools for each.

Using separate tools works as long as the two tools integrate seamlessly. Fortunately, ProductPlan integrates with Jira and Azure DevOps so that you can keep your roadmap in sync with your backlog and vice versa.

Examples of using roadmaps

There are many ways that you can use a roadmap for your IT work. Here are three examples that show how you can use different roadmaps to collaborate and communicate with your business partners.

Roadmap for IT portfolio

A nonprofit association wanted a full picture of its various IT initiatives for planning and communication purposes.

The IT Staff created an Enterprise IT Roadmap to show the initiatives that they:

The initiatives were further divided into swim lanes that represented which of the nonprofit’s key objectives the initiatives addressed. Examples of those objectives include:

These are the key decision filters that the association uses to decide whether to undertake the initiatives. When they considered a fairly significant action, they would run it through those decision filters (i.e. “Will this help us deliver value to members?) if it didn’t pass through any of the decision filters, they didn’t do it.

The association used this roadmap as an aid for their regular planning discussions. For example, when one initiative was nearing completion, they’d look at the roadmap and see which initiative in the next column made sense to start next. They could also move items off the roadmap or switch items between the later and next columns if they found their needs or priorities changed.

Roadmap for a custom development project

A team was tasked with replacing a 20-year-old pricing tool built on outdated client-server technology. The original scope included rebuilding the tool on modern technology and adding functionality to support some new business processes.

As the team investigated how staff used the current tool, they found several inefficient processes and unused features. They also realized that the target date for cutover to the new system was very aggressive. It wasn’t likely that they’d be able to rebuild everything and add the new functionality by the initial target date.

IT project roadmap

The team created an IT Project Roadmap to plan out the order in which they would build functionality in the new tool and communicate their plan to executives in their organization. They built the roadmap with a monthly timeline and displayed the epics they planned to work on. They also put key milestones on the roadmap so that when they moved the delivery of epics with each other, they could see whether they had a viable solution for the cutover date.

The team built an initial version of the new tool by the cutover date that addressed all the users’ immediate needs. They then delivered additional functionality over the course of the next few months so that the users had the functionality they needed when they needed it in their annual cycle.

The roadmap helped the team keep stakeholders up to date on their plans and convey what functionality to expect when. It also helped with the frequent discussions the team had about changing their order of delivery when they ran into challenges or uncovered new information.

Roadmap for a platform build-out

A team started work to merge product data from several transactional systems and provide that data to a partner to list those products for sale. As the team progressed with their work, they realized they were building a data platform that several other initiatives could use for different purposes.

The team started having conversations with the other initiatives and began identifying the common patterns from all the requests.

The team put together an IT Infrastructure Roadmap for the data platform to reflect their plans for building out interfaces into the platform. These interfaces included additional data sources and ways for other systems to get data from the platform.

The team designed the roadmap with a quarterly time frame to convey which interfaces they planned to work on and when. They chose this timeframe based on the uncertainty of working with several departments in this large retail organization.

IT teams can use this roadmap as a high-level view of their work. They also tied the roadmap to their backlog tool so they could track how individual backlog items satisfied work toward the broader interfaces shown on the roadmap.

Roadmaps are a powerful IT Tool

As you look for new ways to work with your business partners, take a moment to consider how you can use a roadmap to help you out.

You don’t have to be a Product Manager to use a roadmap, but you can certainly use Product Management tools to use a roadmap more effectively.

When you’re ready to build a roadmap for your next IT initiative, give ProductPlan and one of its IT specific roadmap templates a try.

Here’s How IT Services Can Make a Compelling Roadmap ➜