7 Questions That Lead to a Roadmap
This year was the first time that I ran an entirely remote road mapping session. Usually, I would organize this in a workshop format with all the key stakeholders present in the same physical room with a whiteboard, sticky-notes, and lots of sharpies. However, we did not have that luxury in 2020.
For the first time, I also tried Jamie Arnold’s approach of 7 questions to build a roadmap. Previously, I had used different methods ranging from roman pitcher’s templates to a simple excel sheet. However, Jamie’s model seemed better aligned to what I needed for a government project.
If you have ever googled ‘roadmaps’, you must have shown an array of different templates and blog posts, but I came across very few that explained “how” to get to a roadmap (or the final product). This post describes how I worked with a government client to help them define a roadmap that the team could follow, using Jamie’s approach.
Preparation
As with any workshop, preparation was key! One of the key prep was ensuring that the questions from Jamie’s blog would work for us. After a couple of round of discussion with the product manager, we decided to alter question number 3 and 4 to better suit our needs:
1. What do we want to learn / prove
2. Who are our users
3. What measurable benefits we hope to achieve
4. What outputs we are hoping to achieve
5. What are we assuming
6. What are the dependencies
7. What capabilities do we need
Question 3 allowed us to explore the “why” behind the things that we were trying to learn/prove. Whereas with question 4 we were able to surface the artefacts and outcomes that we hoped to achieve by a certain time. This question also lead nicely into then discussing about the capabilities we would need to achieve the outcomes or the dependencies we would have to be mindful of.
Secondly, we ensured that all the right stakeholders will be available ranging from — legal, architecture, product, delivery, lead developers, operations and subject matter experts.
Setting the scene
I started the session by presenting the deck that I prepared with the product manager to explain the importance of a roadmap, vision statement and the difference between a roadmap and a project plan/release plan. This step was necessary as the team had never before participated in anything of the sort and were working with roadmaps for the first. This step may not be needed for your teams.
Before kicking off the exercise we set a few ground rules that everyone must follow including the time allocated for each activity.
Facilitation
For the purposes of this workshop we had used MIRO — a virtual collaboration tool. I had pre-prepared a whiteboard with the above agreed 7 questions and the timeline. Every participant was encouraged to have their mic and video switched on for the entirety of the workshop. The timeslots were followed as closely as possible allowing a bit of extra time if needed.
The following is a screenshot of what the board looked like post our workshop. Every participant was free to add many stickynotes as needed for each of the seven questions. Each question and the related stickynotes were then discussed as a group to ensure clarity. Any disagreements were handled in a professional manner and any conversations that did not align to the workshop goal were parked in a ‘parking lot’.
At the end of the discussion, each participant was allowed “three dot votes” per question to vote for the stickynote/ answer that they most agreed with for a given question. Dot voting is one of my favourite tools that I like to use to democratically make decisions.
Next steps
Following on from this, we created a roadmap which looks every similar to the one above except for the additional sticky notes. This roadmap is shared across the programme and the team is bought into the overall goal and vision of it.
Though we were only able to get the short-term roadmap defined (3months and 6months) we are now working on defining a medium term and long term (12months and 24months) roadmap too, using the same technique. Since this is a ‘live’ document, any changes to the document are communicated widely and the core team is fully involved.
Key takeaways
If you are a consultant or a performing an advisory role then it is very important that you gain trust of your product manager and the team. The reason I was able to get the necessary stakeholders and facilitate a session that achieved the workshop goal was because the product manager was completely bought into the process. Secondly, having a parking lot managed by the product manager allowed us to stay focused whilst not forgetting about any key points or conversations that must be followed up. Finally, I think prefer this approach of thinking about roadmaps as ‘series of questions’; the answers to which can be compared, discussed, debated and agreed upon.
