On roadmaps and themes

The wrong kind of roadmap...

This post was inspired by a chance conversation from a developer, from another Brighton based software product firm. This occurred during The Lean Event. The conversation started during an audience participation section of Jared Spool's talk . I told him about trying to organise around themes and in exchange He told me about a lack of connection without that. This pleased me as it meant I was on the right track, but also reminded me not everyone has it sorted (even if you think they do from the outside). Unknown to me at the time I was sat at the table with Roman Pilcher! (more on him later)

In the past three years there have been three big influences on the way that I look at roadmaps. Well that and software development, they are (in chronological order):

1. Gojko Adzic introduced me to Impact Mapping at one of the first Product Owner Survival Camps. First we learned about the importance of goals. Then being able to measure the impact of changes you make to meet them.
2. On a more academic note I then took the Open University course Managing Technological Innovation. During this course I read the paper "Technology roadmapping—A planning framework for evolution and revolution" by Phaal et al (2004). In this paper they discuss the various roadmapping approaches. And then described how this works in different industries and organisation sizes. This was useful for looking at aligning technology and business disciplines. 
3.  Finally on a project to refresh our product's user interface. I needed to prioritise and produce a roadmap for hundreds of features. This is when I found the template created by Roman Pilcher. This was useful for communicating what problem we were solving and why. 

Once you have all these elements then it is easier to create a narrative. First telling a story about the problems people have. Then how your product will evolve over time to solve those problems. 

Of course that is great, but one thing that you need to do is gain trust from your stakeholders. From the management, the team, and the customers. By delivering. After that you need to deliver again. And again. To start with don't worry about having too little in your releases. As long as it's what you said that you were going to focus on and it works. Even if it is basic functionality. Remember that you can improve this with user feedback and it helps avoid analysis paralysis. 

The themes are useful here for providing some kind of commitment in tackling a problem. Without having to be certain on the exact features or time scales. They allow some flexibility in the face of uncertainty of what you need to do. Additionally in what you might discover as you start user research before delivering.

I have found that this momentum and flow is the most important thing to get right. Without it you can have the most perfect ideas and  crafted user stories backed up with data, but it won't matter. Roadmaps only mean something if the items on them get delivered.

Think. Build. Revise. Repeat. 
 

Further Reading

• How To Build A Product Roadmap Everyone Understands - tips from the people behind ProdPad
• How we built a product vision and roadmap - how Postmark did it
• Building Products - a look at a Facebook framework on focus in Product Development
• 2014 article on GOV.UK's experiments in roadmapping, I particularly like the concept of showing what you have recently done as an anchor (and example GOV.UK roadmap 2015-2016 in Trello)

Sources

Phaal, R., Farrukh, C.J. and Probert, D.R., 2004. Technology roadmapping—a planning framework for evolution and revolution. Technological forecasting and social change, 71(1), pp.5-26.