I’ve never spoken or written on this subject, but Matt covers it really well so I’m just going to review what he shared. I have been around this for years so I know he’s on target. One thing that makes this so clear for me is that I’ve been on program teams and product teams as well as on project teams (in almost every role), so I’ve had plenty of chances to see how products are managed, grow, and improve in response to customer needs and opportunities created by technological advancement.
Given the above, we might consider an ongoing effort where the backlog is always prioritized and always contains items that will be addressed in the near, medium, and long terms. Items are better defined that will be worked on soonest (or are being worked on right now!), and tend to be increasingly less well defined going farther ahead in time. Items are clarified and progressively elaborated as they move forward in the backlog and actually get worked on in turn.
There are many ways to communicate this information to different participants, but I tend to prefer just enumerating high level features in time-boxed buckets moving into the future. The priority of items will be determined by continuous review of the backlog by the product owner as he or she works with customers, internal teams, and other stakeholders. The information can come from any type of future work repository (e.g., Jira, MS Project, and so on). Here are some examples from Matt’s talk.
You can see that roadmaps can be conceptually organized by many different criteria. Many others are possible, especially if they are targeted to different audiences (e.g., developers, testers, managers, users, and so on).
Roadmaps apply in almost any management paradigm (Waterfall, Agile, hybrid, modification vs. from-scratch), but really shine over longer periods of time.
We learn from the study of economics that human wants are infinite and resources are inherently finite. Roadmaps are a good way to negotiate and communicate the choices you make.