The product roadmap, a tool to show the direction of software projects. A tool to translate strategy into actionable work. It is also for those in Agile software development to understand the priority and the sequence of work for team members in the day to day work. But it’s also a tool to communicate with those who are not in the day to day work. Namely, the stakeholder.
Typically this is a communication from the Product Owner, but not always so. This communication is one of the most important aspects of Agile product roadmap. Do you ask how to create a product roadmap that shows priorities? One that communicates product strategy and vision for your Agile project? The simple answer is that you must focus on the information. Then remove items that get in the way.
Often the Agile product roadmap gets overburdened with details and loses focus. It loses its ability to communicate with those most needing the information on and off the Agile team. Of course, these are the stakeholders, the users, and those working on the product. But what do you focus on to build a better product roadmap, one that works for all involved?
The following will give you good tips on how to create an Agile product roadmap and how to win over stakeholders. It is how you create a product roadmap that is simple but effective. Use them in your technology roadmaps, or Agile roadmaps. Product Owners, or anybody involved, can use these tips to communicate product strategy and vision. These ideas will help you understand how to create more effective Agile product roadmaps. Show where your product is going and how to get there!
- 10 tips for building an Agile product roadmap that will win over stakeholders
- Focus on the goals and benefits
- Show increments of time
- Understand the priority of the work
- Priority is a relative ranking between the work
- Show clear descriptions of the work
- Roll up work to high-level displays on the roadmap
- Promote a direction for the work
- Interaction and communication are key
- Remember to push back or say no when appropriate
- Regularly adjust and update the Agile product roadmap
- What should you avoid when unsure how to create a product roadmap
- Final thoughts on how to create a product roadmap
- Additional reading and eBooks that help with how to create a product roadmap
10 tips for building an Agile product roadmap that will win over stakeholders
What does a product roadmap need to show? Do you ask how to create a product roadmap for your business plan, technology work and more? As a product roadmap is a tool to communicate information, its all about organizing the info for effective communication. So what you need to know is how to create a product roadmap that is streamlined. Something organized well enough to communicate effectively. Leverage these tips to create product roadmaps that communicate clearly to your stakeholders and users.
Focus on the goals and benefits
Showing the goals and benefits of the work helps viewers to understand the work. Getting into other aspects of the work, like how it’s being done will lose viewers that you need. Focus on the business value to keep that focus. It also helps with later items on this list, which is a priority. The business value actually drives a lot of what makes up the roadmap.
Remember to collaborate with stakeholders to get a true understanding of goals and benefits. Keeping the focus on goals and benefits is a top factor in getting to shippable software products quicker. Keeping to the goals, and eliminating extra, so that you can complete those goals. This allows you to decrease the time-to-market and get quality software done.
Show increments of time
Show increments of time, that work will be done in. Keeping in mind, the time does not have to be as specific, but can if that helps. I don’t even use the sprint or iteration as this time. An example of this is 3 columns of work. From left to right, those columns are loosely labeled “current work”, “next up”, and “future work”.
In my opinion, showing current work, next up or near term work, and future or long term work is a great way to organize the efforts. This gives an easy way to classify the timing of work. While avoiding the arbitrary due date that might be given to work. All in a nice visual depiction for easy viewing.
Understand the priority of the work
Know the priority of the work. This leads to you understanding what work to do and in what order. Visually depict this priority. As an example, if the roadmap shows 5 work items in the current work lane, the order of those 5 items is the priority. It should not be simply rating things as high priority, etc. The reason this is important for the team, is they need that priority to help them tackle work, to best meet goals. Priority is one of my number one items for display. It is heavily influenced by the business value gained from the work.
Priority is a relative ranking between the work
Ensure priority is a relative ranking between work on the board. Often times work is a mix of priorities, and there can be a stop and go nature to work. Where you work something for a bit, then you have to set it down and wait while you move on to something else. Once ready, you move back to the higher priority work. Prioritize work in a sequenced order for the roadmap. A clear reference to priority helps a team move through these decisions seamlessly. The other reason for the need is that the stakeholders, users, leadership, and others all can use this priority to better understand the work.
Show clear descriptions of the work
This one seems straight forward. However, sometimes descriptions of the work are too vague. Or just as bad, sometimes they are too detailed. Aim for finding that description that is just right, so a roadmap can properly show the priority and time frame of the work. Having clear and concise descriptions helps the cross functional team, as it is information that can be used by all of those involved.
Roll up work to high-level displays on the roadmap
Also, the work items are more objectives or higher-level work tasks. This is not at the level of individual user stories. Or more detailed work break downs, if you don’t use stories. It is more what goal you achieve by completing a set of user stories, that deliver larger functionality. Communicate that higher-level objective or goal concisely. Include additional details in a description if needed. The name or title should convey the work and be able to be understood by users and stakeholders.
Promote a direction for the work
Remember, the Product roadmap shows a direction for the work. A strategy you are working towards. Line up work that moves to accomplish that strategy. IE, if you complete A, B, and C, then you have met some goal of the company. This is a product-development focus, but that is what the team is doing. They are building work that adds to products and ultimately delivers business value. Show that direction in the product roadmap.
A direction and goals allows for team self organization, to best meet the goals. This is a more effective way to tackle work. You will get better solutions from the team. So set goals, and allow the team to work towards those goals.
Interaction and communication are key
This is to communicate a goal for the work. Communicate the direction of the work. Keep it simple and communicate only what’s needed to make the point. Agile teams require good communication and collaboration. It’s part of being a good Agile and Scrum practitioner. I include part of the Agile Manifesto here, which is the value of individuals and interactions over processes and tools.
This is a key principle to remember. The roadmap is a process and tool. Use it to have those interactions with the right individuals. Don’t use it to replace conversations with those needed, which is users and stakeholders. This is part of an Agile mindset in general, but still great practice on the product roadmap.
Consider The Agile Guide To Product Roadmaps!
Remember to push back or say no when appropriate
Sometimes you can’t do all of the work. When new items come up that are a lower priority, remember you can push back. Often this could be when the business value just isn’t there for proposed work. This is important as it helps enable a focus to finish on the higher priority work. These items can go to a product backlog for prioritization later on. Maybe the items just don’t make the cut at that time. To work good iterative and incremental Agile processes, you have to say no to things that aren’t the top priority, to do them later.
Regularly adjust and update the Agile product roadmap
Remember, the work is fluid. To meet the ever-changing business needs, work is changing. Priorities can shift. These changes need to be reflected on the Agile product roadmap. It’s more than just the work that was delivered that is updated. There will be changes to work that is not underway. There are also changes from the last completed increment of work. I purposefully call it the Agile roadmap here, as having that flexibility is part of what makes it Agile.
What should you avoid when unsure how to create a product roadmap
Additionally, here are some items I would try to avoid in the roadmap. These items make the roadmap less clear. They will impact your understanding of the work. Ultimately the roadmap is communicating a direction of the work and these items will impact that ability.
The first is don’t turn the roadmap into a GANTT chart
The GANTT chart is a traditional project management tool, and it serves that purpose. However, it is different from a roadmap. And, I am careful not to exchange one for the other. The GANTT chart shows the project deliverables, in order. Which, it uses to identify when a piece of work should be complete. Then what work comes next.
Where it differs, is in sequencing the work. With the GANTT chart, you show the dependency of the work. Where slips in the first work items will cause times to move out on subsequent work items. The tendency to use this approach is more of Waterfall model. Which is fine on its own, but if practicing Agile, you don’t want to try and turn aspects of your software project back into Waterfall practices. The GANTT chart is also a tool of a more traditional project management methodology.
Remember to keep it as a priority based depiction of work
The product roadmap is not trying to illustrate a timeline. As it aims to show relative priority amongst the work. It also is not breaking down work into segments to show how the pieces need to be completed to reach a larger implementation. Thus the GANTT view, or timeline view, is not ideal for the product roadmap. It will cause rework to the roadmap if you follow that format.
Estimation for the project team should more be around relative scope or sizing of the work. Where you take on the work and the estimation of the top priority items first. Thus software delivery is always working towards top goals first.
Avoid information clutter
I imagine the work items on the product roadmap like card displays, almost like cards for a user story or tickets in JIRA, for those that use JIRA. In your summary view of the cards or tickets, you see high-level information. Enough to let you know what that item is. The rest of the product roadmap is not about the information on individual work, so you don’t really need more than that.
Final thoughts on how to create a product roadmap
The items here will help you communicate the information. They will help you decide how to create a product roadmap that meets your needs. Helping to determine if you are building the product that will meet your user’s needs. As well as achieve stakeholder objectives. So that you win the support needed for your Agile product roadmap. Start using these ideas and help with how you build a product roadmap.
Additional reading and eBooks that help with how to create a product roadmap
Some practices that greatly help to organize the work and promote working a roadmap in this Agile model are Vertical Slicing and Just in Time Requirements. These are Agile development methodology practices that will help break apart user stories and help to get the requirements you need. Building better user stories in an efficient manner. They also help promote good teamwork in the process. Continuous improvement of both the software work and the team along the way.
