Roadmapping: know your audience to gain their buy-in

As Product Managers, roadmaps can be useful to show a clear direction of travel towards your ‘north star’. It conveys a clear vision, your priorities, and your plan to meet them. But how you tailor and communicate your roadmap depends on the audience in question. What is important differs between different audiences - in terms of level of detail, pertinent information, level of technical understanding, and personal priorities. This article explores the different audiences you may encounter and offers some thinking as to how you can tailor your roadmap according to the audience you’re playing it back to.

Map your audiences

On every project, you will find yourself with at least a few different audiences to convey your roadmap to. It is important to know your audiences and what they care about. On my current project, we have identified at least 5:

Internal development squads

This group probably needs the highest level of detail and clarity. They need to understand what is being built, in what sequence, with which dependencies, with what approach, in collaboration with which other teams. They will expect to have a say in the finer details, as they are in a position to assess the feasibility of the plan.

Key stakeholders/Executives

They want to see the big picture. What key milestones are we targeting, and when, and have a stake in ensuring the plan aligns with the wider business goals. They will care a lot less about the finer details, caring more about the “Zoomed-out” view and the thinking underpinning the relative priorities you’ve assigned to each item.

Operational staff

The people who will actually carry out the day to day operations of your product or service will always have a very different perspective of what is important. Outside the development squads, these people understand your product most intimately, in that they interact with it more than anybody else, and will push for very specific fixes to very specific problems. For them, they want to see the roadmap for fixes to those issues. They want to feel heard, and don’t want to see a roadmap that covers just the big ticket items for the financial year - they want to see you are focusing on what matters to them as well. They also may want to challenge the relative priorities you’ve assigned to things, as they may have a very different perspective to your senior stakeholders as to what is most important at any stage.

Participating 3rd parties

The current service we are building also requires participation from local councils. Similar to the ops staff, they interact with the service on a day to day basis, and will want to understand the upcoming work, when to expect it, and will expect some kind of forum to ask questions about the changes. Similarly, they will also be feeding back issues they’re facing, and will expect to see fixes and improvements making it into your priority list.

Wider business audience

This group wants to stay informed and understand the high level project milestones. What will you be releasing, to which groups, at which time. Similar to your executives, they just want to see the bigger picture, and ask questions, and start to plan any activities they need to execute around the plan you present.

This is by no means an exhaustive list or indeed the only way of categorising the groups I’ve already mentioned. In your context, you may want to split your audience into groups such as Sales/Marketing, customers or members of the public, finance teams, customer service and many others. The value lies in finding out what matters to your audiences in their particular contexts.

Speaking their language

Understanding what is important to your audience helps you tailor your roadmap specifically to their needs and focus. From here on, this article will focus on executive stakeholders, development squads, and operational staff.

For your senior stakeholders, that means focusing your roadmap around outcomes tied to the strategic goals of the business. Consider swimlanes that orient around a single business goal, and make sure to tie it back to that goal using data. On my current project, one area of focus is to deliver new case types as part of a case management system. When conveying these on the roadmap, consider sharing data on the extra volumes we can expect as a result, contributing to the overall goal of managing 100% of historical case volumes on the new service.

Development squads need more clarity on specifics. Outcomes are still important to convey to the dev teams, as they want to understand the why as well, but the “What” is far more important. It might be enough to tell senior management we’re improving the user experience of x and y, but to the dev teams, they want to know how, and in fact will want direct input on how we will deliver a particular thing. So you must be ready to share that lower-level detail with them, and expect some pushback.

Ops staff, once again, will expect clarity and detail. When you share the roadmap you must also be ready to field lots of detailed questions, negative feedback, and requests to see upcoming plans and designs for new features. Expect to be schooled in something you knew nothing about and be prepared to thank them for the experience. Your ops staff are true experts in the service, as they are the ones who carry them out, and can be an absolute wealth of knowledge to you - if you can keep them on board. That means listening to them and ensuring their priorities are heard, which are often vitally important to the day-to-day running of your service. If you’re carrying out an early pilot, try to emphasise their role as co-creators in the new service, and help them frame it as such. Reputationally, their attitude towards your project is vital in keeping the project in good standing.

Show them what is important to them

We’ve formatted our roadmap in at least a couple of different ways over the past few months, to account for the different audiences in question. Not every audience is looking for a Gantt chart or a jira board, where you can’t see the wood for the trees.

Senior stakeholders will be looking for something high level and visual. A Now/next/later level of detail should be enough, provided the items tie back to business goals. Try to keep it to a single pager, and make it clear and easy to understand. Execs won’t have the time to trawl through a document to try and work out the plan.

On my current project, we approached this by showing a chart which took the overall outcome (100% of case volumes) as the main aim, with an X and Y axis which reflected the two directions of scaling towards those case volumes (participating councils and the number of case types), with a series of incremental releases which would take us there.

Real contents obscured for anonymity

This was useful as it tied all of our priorities towards a direction of travel which were important to our stakeholders. They were easily able to prioritise the case types according to which mattered most, and could easily flag when the underlying supporting features would be needed to support the higher case volumes brought with the increase in participating councils.

Dev teams, however, need to know specifics. As such, we tailored a roadmap for them which reflected our split into 4 development squads, plus runway and design. We matched up relative sizes with our estimations, and used icons to denote where dependencies lay against upcoming priorities. In other words, we created and shared a much more concrete plan with them, and tweaked it based on their input until everyone had confidence in it.

Image blurred for anonymity

For ops staff, while we did share the above roadmaps with them, we found they were less concerned with the big upcoming items, they wanted to know when the issues they flagged to us will be fixed. It’s all well and good to see the next case type being delivered next month, but when am I going to be able to rename files?

Consider a roadmap for specific improvements which you know are causing friction for your staff. That may be bugs or improvements to features we’ve already delivered, or workarounds they’re currently having to use because of a missing feature. These are often small but nonetheless highly significant to the day-to-day working of your service. Show them you take them seriously by sharing a timeline for those they’ve deemed a high priority, and show them you’re not running full steam ahead towards the overall project aims - as they may see you as running before you can walk. Show them you are listening by planning and sequencing their priorities too.

If you’re conducting regular iterative releases, consider sharing the granular scope of those releases so they know when to expect the improvements which matter to them. Too granular for execs, but the right level of detail for your staff.

A roadmap is a living document

Finally, remember to regularly iterate and communicate your roadmap with the different audiences, particularly if something changes. A roadmap should be a living document, which routes and reroutes as conditions change. As such, you should make sure you have the right touch points with your different audiences, to get regular input, feedback, pushback or buy-in. Keeping everything in sync is hard, and I’m not advocating for creating 10 different versions to keep up-to-date. Rather it is about knowing what matters to your audience, and tweaking the language and presentation slightly, in order to secure the trust and buy-in of your audience.

In summary, to craft an actionable and engaging roadmap for your audiences, you should map your different audiences, to ensure it is written in language they understand, consider their needs and priorities, and ensure what you’re showing them matches up with them.

Do you have any tricky groups on your project you’re struggling to win over? Drop a comment with your experience, or come along to the next Product Breaks Live event.