Inspire action through an impactful product roadmap
Roadmap: a step-by-step guide to successfully building, communicating, and executing an impactful product roadmap.
A product roadmap is an effective way to communicate what the team will build. It’s particularly true for innovation projects as they sometimes generate excessive expectations or a lack of understanding by stakeholders. As an innovation leader, you may build a roadmap to align vision, share common knowledge, get leadership buy-in, and collect feedback about your innovation.
But where to start to build a roadmap? What distinguishes an innovative product roadmap from project planning? How to make it a working document that evolves throughout the project?
I’ll answer all these questions in this article. I co-built a product roadmap without falling into the common traps. I’ll walk you through the 3-step process I put in place to define a clear, practical, and inspiring roadmap:
- Step #1: Create a first version of the roadmap
- Step #2: Create and share versions of the roadmap
- Step #3: Update the roadmap
I’ll use the project I led as an example — the project aimed to develop an internal Asana-like project management tool for employees.
Step #1: Create a First Version of the Roadmap
Building a roadmap is a collective effort for which the product manager is responsible.
The first version of the roadmap is a working and living document.
#1.1: From Vision to Goals
I started with the product vision: “To provide people with a common tool to effectively complete projects.”
The product vision is the purpose for creating the product, and the positive change it should bring.
But this vision is still too vague for building a roadmap. I broke it down into objectives for each target user:
- For project managers: “effectively manage operational tasks on projects.”
- For decision-markers: “effectively manage strategic decision-making on project portfolios.”
- For top managers: “improve project performance within the organization.”
The product goal describes the future state of the product, and the desired benefit or outcome the product should create.
#1.2: From Goals to Problems
Discovery interviews enabled me to identify the problems encountered by target users. I listed all of these pain points, for example:
- “Information shared on projects is not always validated.”
- “Processes are not homogeneous from one entity to another?”
- “Once started, it’s difficult to stop a project, even if it’s not performing well.”
- …
I clustered these issues into themes: information sharing, project tasks management, approval request, innovation dashboard, etc.
Focusing on pain point themes ensures that the problems to be addressed are clearly defined before moving towards solutions. Solutions may change as the team ideate, but the problems to be addressed are always the same.
With the team, we positioned these themes on a simple timeline that tells a story:
“We will first build a simple tool for managing the tasks. It will be our MVP to collect data on our users quickly. We will then provide features to optimize decision-making. Finally, when the platform contains enough data, we will monitor project performance within the organization to improve it.”
A product roadmap should tell a convincing story. It should describe the journey to take in order to create the desired value for the users and business.
#1.3: From Problems to Features and Capabilities
I ideated possible solutions for each pain point theme with the team, and we expressed these solutions as features and capabilities.
- Features for the short-term: “assigning a task to a team member, requesting approval from a manager, etc.”
- Capabilities for the medium and long-term: “dashboard, benchmark, risk assessment, etc.”
We asked ourselves for each feature or capability: Is it something that would help us meet our product goals?
This approach led us to dismiss ideas, even if they were interesting.
I’m actually as proud of the things we haven’t done as the things I have done. Innovation is saying no to 1,000 things. — Steve Jobs
We added three sections that are, from my point of view, essential to distinguish a roadmap from a project plan:
- Risks: barriers that could prevent us from achieving our goals; for example, “the product is considered by users just as a reporting tool.”
- Discovery tools: means to learn from our users and ensure that the design meets users’ needs, for example, “user interviews, usability testing, lean experiments, etc.”
- Metrics: measurements that help us to determine if we reached the goal.
Adding risks, discovery tools, and metrics to a roadmap reminds stakeholders that the features and capabilities positioned at any given time are based on assumptions that will evolve as we learn more about our users.
At this point, the roadmap would look something like this:
However, I cannot share this first version as such. There are as many roadmaps as there are stakeholders and communication goals. So let’s move on to the different versions of the roadmap.
Step #2: Create and Share Versions of the Roadmap
Now is the time to share the roadmap with execs, cross-functional teams, developers, and users.
There is no natural order to follow. The stake for the product manager is to go back and forth between the high-level vision shared with the execs and what is possible to develop by the development team while integrating user feedback. It’s a real challenge!
#2.1: Execs
We started by sharing our roadmap with top management to ensure that we were moving in the right direction and to obtain their sponsorship.
Goals: Gain alignment in vision and direction, obtain financing, and get leadership buy-in.
Timescale: 12 months.
Format: Simplified and a high-level overview of the capabilities we will develop.
Pro-tips:
- Show user verbatim to emphasize the importance of creating the product.
- Use inspiring but straightforward wording.
The execs’ roadmap would look like this:
With this roadmap, the execs had a clear vision of the problems and the capabilities to promote the product to employees.
#2.2: Cross-Functional Teams
Once the roadmap was shared and approved with the execs, we communicated it to cross-functional teams and departments.
Goals: Help coordination, identify dependencies, share resources, avoid effort duplication, and get feedback on planned work.
Timescale: 12 months.
Format: Simplified and a high-level overview of the capabilities that will be developed, coupled with a detailed roadmap.
Pro-tips:
- Add a glossary of the used terms, as not everyone is necessarily familiar with UX and agile terms.
- Be open to collaboration opportunities with other teams.
- Explain the vision and the roadmap elements as many times as necessary. To communicate is to repeat.
We shared with these teams the execs’ version of the roadmap, coupled with the first detailed version of the roadmap.
Sharing the roadmap with cross-functional teams enabled us, for example, to identify dependencies and opportunities to create IT workflows with other internal products to prevent our users from duplicating entries.
#2.3: Dev. Team
The roadmap for the development team consists of breaking down the “Now” goal into sprint goals and features to be developed in the short term to deliver value when expected.
This roadmap needs to be co-built with developers.
Goals:
- Align the team with the value to be delivered throughout the development.
- Motivate the team to achieve precise and ambitious 2-week goals without losing sight of the big picture.
- Help prioritize developments.
Timescale: 3 months.
Format: Detailed and complete view of the features to be developed during each sprint, with the associated design and discovery work.
Pro-tips:
- Connect the big, inspiring vision to the tactical, short-term sprint goal.
- Highlight the links between delivery work and discovery work.
- Make sure to focus on one goal per sprint.
The dev. team roadmap would look like this:
This roadmap enabled the development team to focus on essential developments and establish priorities to achieve motivating goals.
#2.4: Target Users
Last, we shared our roadmap with users to give them visibility on the work in progress and ask for their feedback.
Goals: give an overview of the capacities that will be developed, reassure them, and collect their feedback through comments and votes on features.
Timescale: 12 months.
Format: An online ticketing tool that enables users to interact with the roadmap (Trello, Notion, ProductBoard, etc.)
Pro-tips:
- Make sure that the capabilities and problems are things that resonate with their pain points. Simplify the features’ title so that it is understandable and impacting. Use the JTBD framework.
- Don’t give specific dates unless there is a confirmed release date.
- Add a card to explain the goal of sharing the roadmap with them. Put disclaimers on forecasted dates. Indicate how you will integrate their feedback into the roadmap.
Here are some examples of roadmaps shared with users: Slack, Twitter, ProdPad, Front.
Sharing our roadmap with users enabled us to involve them in our design process.
Step #3: Update the Roadmap
Communicating the product roadmap triggers feedback. The goal is to collect this feedback to integrate it into the roadmap iteratively.
In addition, the more time advances, the more we convert the problems or themes into capabilities and features. It’s important to keep stakeholders informed of design choices that may impact them.
For this purpose, I planned the following meetings:
- A presentation of the roadmap once per trimester to the execs to keep them informed.
- An update every other week of the roadmap with the dev. team to ensure we achieve our objectives.
- A monthly summary of how we integrated their feedback into the roadmap for the target users to keep them engaged.
Takeaways
- Focus on problems and pain point themes to solve rather than specific features. It allows thinking of relevant solutions as you collect more information about target users.
- Add risks, discovery tools, and metrics to the roadmap to remind stakeholders that the features and capabilities positioned at any given time are assumptions that will evolve as we learn more about our users.
- Adapt the format to the target audience. The goals, timescale, structure, level of detail, wording, and actions vary depending on the audience.
- Explain the vision and the roadmap elements as many times as necessary. To communicate is to repeat.
- Set up meetings to regularly update the roadmap, ensure it is relevant, and communicate the overall vision.
Resources
- The Goal-Oriented Roadmap by Roman Pichler
- Product Roadmaps Essential Guide by Richard Holmes
- UX Roadmaps: Definition and Components by Sarah Gibbons
- The Product Roadmap that Boosts Innovation by Janna Bastow
- The Art of Building a Roadmap by Sherif Mansour
- Product Roadmaps by Des Traynor
- Building a Product Roadmap by Katie Salley and Aaron Szerlip
- Escaping the Roadmap Trap by Emil Kabisch
