I’ve not yet been responsible for a roadmap but I have certainly fed information into them, so I was very keen to check out yesterday’s meetup and hear from a panel who disagreed and agreed on the merit and use or uselessness of product roadmaps. The panellists were

• Michael Pearson, Director Product & e-commerce at Expedia
• Michael Bromley, Head of Digital Strategy and Chief Innovation Officer at SMS Management & Technology; and
• Chrissie Zenonos, Head of Product at Mi9 (Channel 9)

While the panelists weren’t in perfect alignment they generally agreed on the following.

What is a product roadmap?

• A communication tool
• A list of priorities

What should a product roadmap communicate?

• Needs, problems
• Goals and objectives
• The business value to be delivered
• The vision
• The capability

How should a product roadmap behave?

• It should be flexible
• It should accommodate a test and learn approach

What value do product roadmaps provide?

• Provide visibility to different teams to enable them to align to a singular vision
• Show how everything fits into a greater scheme, to provide context
• Provide clarity to tackle ambiguity

What a product roadmap is not, or should not be or do

• Should not be a features list
• Should not describe granular detail
• Should not explain how something is to be delivered

The aversion to product roadmaps was best expressed by Michael Bromley:

“Because I can’t predict the future I don’t try.”

And with technology and the market changing so rapidly its easy to see why people need to work in differently. What the panelists had in common was a way of working which was flexible, agile, and iterative, applying a test and learn approach. From what I could gather Michael Bromley, of SMS and Chrissie Zenonos of Mi9 could do away with the traditional concept of a product roadmap deliverable because they worked with co-located teams. They used walls of post-its and the business model canvas as alternative tools. Michael Pearson of Expedia, unlike the others was still an advocate for product roadmaps. He works with distributed teams of developers and needs to communicate the wider context and timelines to engineers and call centre channel teams who need to know when a feature will drop. His version of a product roadmap is a JIRA workflow where the hypothesis to test eventually becomes the code then the feature.

My big takeaway was realising that so much documentation—product roadmaps, feature lists, test schedules, project plans, even the business case—are really communicating the same thing. The challenge is rationalising tools that so many feel so comfortable with to avoid duplication, focus on communicating the vision, and work iteratively and flexibly towards achieving it.

Product Talks is a meetup organised and hosted by Brainmates for Product Managers. Their next topic “Is UX a Part of Product Management” will be on 9 June.