Language selection

Search

How to Use Product Roadmaps to Build Trust with Stakeholders (DDN2-V38)

Description

This video, featuring Ayushi Roy, provides cross-functional product teams with practical advice on how to educate their stakeholders on agile methods and experimentation to facilitate successful product and service delivery.

Duration: 00:03:56
Published: January 14, 2025
Type: Video


Now playing

How to Use Product Roadmaps to Build Trust with Stakeholders

Transcript

Transcript

Transcript: How to Use Product Roadmaps to Build Trust with Stakeholders

[00:00:01: Text appears on screen: How to Use Product Roadmaps to Build Trust with Stakeholders, with Ayushi Roy]

[00:00:10: Text appears on screen: Roadmaps]

Let's start with the example of roadmaps. Roadmaps are a common and powerful strategic tool used by product teams to help keep track of the big picture and correlate our work items to that end goal. However, roadmaps are also really important tools to help product teams stay aligned with their stakeholders.

[00:00:31: Text appears on screen: Not to forecast exactly WHAT will get delivered WHEN]

I would not recommend using road maps, for example, to forecast exactly what will get delivered when, but instead for planning the order in which you'll tackle various pieces of the problem and secure alignment at each of those steps.

[00:00:41: A triangle graph appears on screen with text: Vertical axis: Communication, Horizontal axis: Possibilities; from top to bottom, the triangle is filled with: Problem Statement, Product Vision, Product Strategy, Product Objectives/Metrics, Epics, Themes, Stories, Tasks]

Here is a visual example of the various pieces that will be necessary for your road map to cover. At the very top, you have the broadest problem statement (which is where you're trying to go as a product team). The most defined work covered in a road map are the specific tasks necessary for designers, developers and other members of the product team. This is the 'how' the team will get there. And in between, from the most conceptual to the most defined are all of these various other elements of a road map. The reason I'm mentioning any of this to begin with is because it's not just important for the road map to include each of these components. It's also important to communicate each step of these components with your stakeholders, in order to ensure alignment, understanding and buy in.

You can communicate in a couple of different ways. In one instance, it may be effective to communicate the more conceptual parts of the road map, separately from the more defined and detailed parts of the road map. In a regular fashion, ending perhaps with a demo on a biweekly cadence with your stakeholders in order to build that understanding and socialize the efforts of your product team. There are however, many ways to communicate up and down the various pieces of the roadmap with your team, as well as with your external stakeholders to ensure that your work is being understood along the way, this is just one example. Ultimately, the roadmap is a bridge between your strategic vision and your backlog of work for your team, and it's also a bridge between your team's work and your organization's understanding and support of your team.

Everything in this process, whether it be with your roadmap or with user story collection or usability testing requires careful facilitation. And this is the work of a product team above and beyond the technology components. It's important to facilitate outcomes, team dynamics and of course, stakeholders. There are many examples of what good facilitation can look like, and here are a few.

[00:02:48: Text appears on screen: Business training workshop]

You can bring your leaders into workshops to work on the product vision together instead of just setting product vision with your product teammates. You can bring senior leaders into conversations directly with your end users to give those stakeholders an insight into the needs of the end users to allow leaders to empower your product team. Another example is that you can include senior leaders in workshops on defining features with your designers and developers in the room, so they get a sense of what kinds of future development end up supporting end user needs. And of course, you can always invite senior leaders and stakeholders from across the organization to test and click through features on your pages or other applications your team might be developing.

[00:03:28: A triangle graph appears on screen with text: Vertical axis: Communication, Horizontal axis: Possibilities; from top to bottom, the triangle is filled with: Problem Statement, Product Vision, Product Strategy, Product Objectives/Metrics, Epics, Themes, Stories, Tasks]

These, among many others, are ways that you can help socialize the work of your product team across the organization to ultimately build understanding, buy in and trust for the way that your team is working, to then allow your team to feel empowered to work in its own way as effectively as necessary without the various red tape of an organization.

[00:03:46: Canada School of Public Service Logo of book opening/Text appears on screen: Canada.ca/school-ecole]

Related links


Date modified: