In my previous blog post, I talked about how to create a product strategy. In this blog post, I will talk about creating your product roadmap. A roadmap describes your statement of intent. It outlines how you intend to meet your product strategy and vision. They can manage stakeholders, communicate upcoming work and visualise dependencies. In short, they are important.
Roadmaps are living documents. Iterate them when you get new information. Your roadmap is not set in stone because things change!
Timeline vs. No Dates vs. Hybrid Roadmap
No dates
When you are first starting out, a time-based roadmap is not useful as things are changing all the time. These roadmaps tend to be more flexible. Typically, they have ‘now’, ‘next’ and ‘later’.
Timeline
This is helpful when you are trying to coordinate many teams. Ensure you capture soft and hard milestones on your time. Soft milestones are flexible. They can be dependencies or internal deadlines. Hard milestones are inflexible and fixed. They can be legal commitments.
Hybrid
This style allows you to plan into the future while maintaining flexibility. Like a ‘no dates’ workshop, you can organise work by ‘now’, ‘next’, ‘later’ and ‘not doing’. This time time, those buckets correspond to time:
- ‘Now’ work this month.
- ‘Next’ work in three months’ time.
- ‘Later’ work in 6 months’ time.
- ‘Not doing’ is a useful bucket to manage stakeholder expectations. It shows you have considered the proposal but right now it doesn’t make sense for the team to own. My former manager and all-round product genius, Matt, talks about why this is important here.
There’s so many variations of roadmaps. It’s beyond the scope of this particular blog post. The key thing is to not be dogmatic and to use the right tool for your team and needs.
Before you start plotting your roadmap
If you are starting a roadmap from scratch, ensure you have enough space where you can move items around on a wall.
As with creating your product vision and strategy, you want to have a deep understanding of the problem, your users and their needs.
It’s helpful to capture user needs, OKRs and features onto post-it notes. Arrange the cards into three piles (small, medium and large) based on their effort to finish them.
During the roadmap workshop
Reserve at least half a day to run a roadmap workshop.
- Review your product vision and product strategy. Create a shared understanding of the product.
- We are creating a hybrid roadmap.
We have created four buckets: Now, Next, Later and Not Doing. These buckets correspond to the time indicated in the hybrid description above.
- Go through each user need, OKR and feature, and score using Jamie Arnold’s seven roadmap questions.
- What are we trying to learn or prove?
- Who are the users?
- What are we operating?
- What are we saying?
- What are our assumptions?
- What are our dependencies?
- What capabilities do we need?
The key question is ‘does this work help us reach our product vision and strategy?’.
- Depending on the score, move each item to their corresponding bucket. Spend no more than 15 minutes on each item.
Please note: you don’t need to score items! It’s ok to have a discussion and move items. Scoring just helps you be objective.
- At the end of the workshop, you’ll have a roadmap!
The structure above is influenced by DxWs playbook on running a roadmap workshop.
Remember there’s no one way to create a roadmap. Miro took a different approach.
What does the end result look like?
Let’s use our example from the previous blog series.
Our product vision is to provide a high-fidelity music experience that is as good as the experience of listening to music in a world-class studio.
Reflections on the roadmap
- Each feature is linked to an objective, to show your work is linked to a wider product strategy.
- The percentage of certainty and confidence lets stakeholders know how likely the feature will be delivered. Remember, things change. A roadmap needs to reflect this.
- The roadmap lists when it was last updated. Review your roadmap at set intervals.
- I added a delivered section just to show the great work that’s already happened. Celebrate success!
- The roadmap does have a lot of content, consider reducing or adding depending on the audience. For example, if this roadmap was public-facing, perhaps you don’t want to make your objectives so visible?
- In this example, I use features in the roadmap. I don't always think this is sensible. Stakeholders crave certainty and thus will gravitate towards features. In truth, it means being specific about a solution. A maturer product team will focus on outcomes i.e. increasing the number of people streaming an album.
Conclusion
Your roadmap does not need to look like the one I created. Your project will not progress in a linear way. Create what is best for your organisation. Review your roadmap every quarter. Check you are meeting your objectives. Socialise it with stakeholders to get buy-in. Your project will not progress in a linear way.
This blog post concludes my series on setting the product vision and creating a product strategy. I hope you enjoyed this blog post. Please get in touch if you have any feedback or thoughts.
