📋 PLAYBOOK
📍 IN BRIEF
By the end of this playbook you will be able to run roadmap communication as an engagement discipline rather than a publishing exercise: audiences mapped before a word is written, one message per group instead of one per milestone, a cadence people can set their watch by, and a route for feedback to change the plan. The prize is a roadmap other teams plan their own work around.
A roadmap does not fail in the steering committee. It fails three floors down, weeks later, when the people whose working day it changes hear about it second-hand and decide what it means without you. Platform teams put enormous care into what goes on the roadmap and almost none into how it travels, then wonder why adoption lags a plan everyone supposedly saw.
The correction is not a better deck, it is treating roadmap communication the way a marketing team treats a campaign, with defined audiences, a message built for each of them, a deliberate cadence and channel mix, and a feedback loop that visibly changes the product. This playbook walks the five moves in order.
When to use this
You own or govern a ServiceNow platform whose roadmap spans more than one release and touches more than one business function. Two things must be true before it is worth starting. The roadmap must exist and be anchored to outcomes the business has agreed, because you cannot communicate value you never defined, and you need an engaged executive sponsor, because one of the five moves depends on a voice more senior than yours. If either is missing, fix that first. A communication plan for a roadmap nobody has agreed is a newsletter about dreams.
Stage 1, translate every item into an outcome someone receives
Rewrite the roadmap so a reader who does not care about the platform can find themselves in it.
Most roadmaps are written by the delivery team for the delivery team, a list of capabilities, phases and release names. That version is fine for planning and useless for engagement, because no stakeholder can see what any line buys them. Before you communicate anything, rewrite each item as the outcome it delivers and the group that receives it, so the line reads as ‘faster onboarding for field engineers’, or ‘one place for resilience reporting that the audit committee can trust’. If an item resists that translation, it is not ready to communicate, and it is worth asking whether it is ready to build.
The gotcha is doing this translation once, for the annual deck, and letting the working roadmap revert to feature language. The translated version is the roadmap as far as your stakeholders are concerned. Maintain it with the same discipline as the delivery view.
Stage 2, map the audiences before you write a word
List every group the roadmap touches, then rate each one for influence, likely attitude, and what actually changes for them.
This is the unglamorous move that everything else depends on. For each group you want the same four things on one page, which are how much sway they hold over the roadmap's fate, whether they are likely to arrive supportive or sceptical, what the roadmap changes about their daily work, and what they get in return. That last column is the one you will draw on for every message you send. The mapping conversations are not overhead before the real work either. They are the first act of engagement, because people who were asked how the change lands for them behave differently for the rest of the programme than people who were merely informed.
⚠️ COMMON PITFALL
Authority is not influence. The org chart tells you who must approve the roadmap. It does not tell you whose opinion the teams actually adopt. Every organisation has informal influencers whose verdict travels faster than any announcement, and if your map only contains job titles, your roadmap's reputation is being set in conversations you are not part of.
Stage 3, write one message per audience, not one per milestone
Build each message around what the change means for the group receiving it, and choose the sender as deliberately as the words.
The board care that the platform consolidates risk reporting. The service desk agent cares whether Tuesday gets easier or harder. Both are reading about the same roadmap item, and a single message cannot carry both. So write the translation each audience needs, in their language, and resist the all-staff email, which is the most ignored artefact in corporate life. Sender matters as much as content. Vision and investment belong in the executive sponsor's voice, because championing the platform to the wider organisation is part of what that role is for. Delivery specifics belong with the platform owner. What changes for a given team lands best from that team's own leader, equipped by you with the talking points.
Audience | The question they are asking | What you send | Who sends it |
|---|---|---|---|
Executive sponsor and board | Is this still the right investment? | Outcome progress against the agreed case | The sponsor |
Function and process owners | When does my area change, and how much say do I get? | Their slice of the roadmap, plus the route into prioritisation | The platform owner |
Delivery and support teams | What are we building, and in what order? | The sequenced plan with its dependencies | The platform owner |
End users | What changes for me, and when? | The one change that matters to them, close to the moment it lands | Their own leadership |
The gotcha here is tone, because you are selling a future while some of your readers are quietly anxious about what it does to their role. A message that is all enthusiasm reads as deaf. Acknowledge what gets harder before you celebrate what gets better, and the rest of the message earns a fairer hearing.
Stage 4, set the cadence early and hold it
Start communicating a quarter before delivery starts, then keep a rhythm each audience can predict.
The strongest practitioner advice on timing is to start earlier than feels natural. A quarter before the work begins is a sound anchor for the broad audience, and your executive audience should hear the story earlier still. Then set a per-audience rhythm and hold it, so the steering group get a formal monthly read on milestones and health, function owners get a shorter note on the same beat, and the broad population hears from you at the moments that matter to them, through more than one channel, because a message that only ever arrives by email reaches only the people who read email. Repetition is your friend here, since a message has not landed until people can repeat it back, and that often takes more communication than feels comfortable.
The gotcha is going quiet between milestones. Silence is also a message, and it reads as drift, and it costs you the one asset a steady rhythm buys. When a date moves, and one will, an audience used to hearing from you monthly receives the news as ordinary planning, while an audience that only hears from you at go-lives receives it as a crisis.
Stage 5, give feedback a route back into the roadmap
Open a channel for stakeholder feedback, and make what happens to it visible.
Engagement is bidirectional or it’s theatre. Every roadmap message should carry a way to respond, and the responses need an owner and a path to the forum where priorities are actually decided. Close the loop in public, keeping a visible record of what was raised, what was decided and why. When a stakeholder watches their objection either change the plan or receive a reasoned no, they stay in the conversation. When their feedback disappears into a mailbox, they stop offering it and start working around you, which is how shadow demand starts. Adoption signals belong in this loop too. If a capability you announced is not being used, that is the roadmap talking back, and it should carry weight in the next prioritisation round.
The gotcha is opening the channel without the route. A feedback mechanism that nobody routes anywhere is worse than none at all, because it converts goodwill into evidence that you were not listening.
The checklist
Translate. Rewrite every roadmap item as an outcome plus the group that receives it.
Map. List every stakeholder group with influence, likely attitude, what changes for them, and what they get.
Add the informal influencers the organisation chart does not show.
Write one core message per audience, led by what the change means for them.
Assign senders. The sponsor carries vision, the platform owner carries delivery, local leaders carry local change.
Set the cadence. Start a quarter early, fix a rhythm per audience, use more than one channel.
Open the loop. A feedback route with an owner, a path into prioritisation, and a visible record of decisions.
Measure by behaviour. Judge messages by what people do next, not by open rates.
Common failure modes
The roadmap as a secret. The plan lives in a governance deck a handful of people have seen, on the theory that sharing it invites challenge. Rumour fills the vacuum, and the challenge arrives anyway, later and angrier. Publish a version every audience can see, tiered by what they need.
The optimism ratchet. Every message rounds up, with dates presented as certain and benefits at their best case. The first slip spends credibility you never budgeted for, and every message after it gets discounted. Communicate what you are confident of, and say plainly which parts are still moving.
The delegated voice. All roadmap communication flows from a project mailbox, and the sponsor never says a word in public. Stakeholders conclude, correctly, that leadership attention has moved on. Sponsorship is a speaking role. If the sponsor will not carry the vision messages, you have a sponsorship problem wearing a communication costume.
Feedback theatre. Surveys and town halls gather input that visibly changes nothing. This is worse than not asking, because each unanswered round teaches stakeholders that the engagement is decoration. Never open a channel you are not resourced to answer.
The bottom line
If you protect one move, protect the translation. Every failure above is a version of the same mistake, which is talking about the roadmap in your language instead of the reader's. The outcome the board funds has to arrive at every desk as the thing that changes for that person, carried by a voice they trust, on a rhythm they can predict, with a way to talk back. That is what stakeholder engagement means when it is real, and it is the difference between a roadmap people saw and a roadmap people act on.
A roadmap communicated in the builder's language reaches the people who built it. Translation is what makes it travel.
P.S. A quiet test of your current state is to ask three stakeholders outside IT what the platform delivers next quarter and what it means for their team. If you get three different answers, you do not have a communication problem. You have three of them, one for each audience you have not yet mapped.