From a Jira timeline
nobody could read
to a system everyone used.
How I built a roadmap system that served engineers, product teams, and stakeholders simultaneously — without creating more overhead for the people already doing the work.
The roadmap was a Jira timeline. Engineers understood it. Almost nobody else did.
When I joined LINK, the roadmap was a Jira timeline. Items had ticket numbers, technical descriptions, and status colours. Engineers understood it. Almost nobody else did.
This wasn't a tooling problem. It was a communication problem with tooling symptoms. The roadmap served one audience — the people who built things — and excluded everyone else who had a stake in what was being built: sales teams trying to understand what they could promise customers, support teams preparing for new features, market managers tracking progress against strategy, and stakeholders who just needed to know: is this on track?
The result was predictable. Stakeholder syncs were long and inefficient because people needed context that should have been visible in the roadmap. Tech teams made decisions in isolation. And when dependencies between different product teams created delays — which they did, regularly — nobody saw them coming because nobody was looking at the same picture.
The roadmap isn't just a planning document. It's an agreement. If two teams are looking at different documents, they've made two different agreements — and they don't know it yet.
Three iterations. Each one taught me what the next needed to be. The solution only made sense after living through what didn't work.
My first move was to introduce Miro. The company didn't use it — I brought it in, built the first roadmap there, and presented it to stakeholders. The response was immediate enough that the company bought a licence and adopted it across teams.
The Miro roadmap did something the Jira timeline couldn't: it told a story. Instead of a list of ticket numbers, stakeholders could see initiatives grouped by theme, timelines that showed sequence and dependency, and a view that answered the question they actually had — what is being built, when, and in what order?
But Version 1 had real limitations. It was good for presenting. It was difficult to maintain. As soon as technical realities changed — a sprint slipped, a dependency shifted — the Miro roadmap became stale within days. The fundamental problem remained: two roadmaps, two different stories.
The solution came from asking a different question. Instead of “what tool should we use?”, I asked “what does each audience actually need from a roadmap, and how do we serve all of them with the least duplication?”
The answer was a two-layer system: Product Plan for stakeholder management, connected to Jira for technical execution. Product Plan sits on top of the technical work and translates it into language that stakeholders can use — initiatives grouped by strategic theme, progress visible at a glance, different views for different audiences.
Crucially, Product Plan connects directly to Jira. When an engineering task moves, the roadmap updates. The two documents stopped being two separate truths and became two views of the same truth.
One persistent problem in roadmap planning was that different PMs prioritised items using different criteria. The result was that negotiation between teams was often based on whoever argued most persuasively, not on shared data.
I introduced the Impact Value Matrix — a scoring framework integrated directly into Product Plan — to bring a common language to prioritisation. Each roadmap item is scored against impact and value dimensions, making trade-offs visible and comparable across products.
This shifted the negotiation from “my initiative is important” to “here's how this item scores against the agreed criteria” — a much faster and less political conversation. Other PMs adopted the framework too. It became the standard across the whole product organisation.
A system is only as good as the process that maintains it. I defined a roadmap planning cycle that starts 6 weeks before the end of each quarter: global research across product, UX and tech; negotiation between teams on priorities and resources; communication to stakeholders; triggering of first sprint tasks; and ongoing follow-up. This rhythm meant the roadmap was always being prepared for the next quarter while the current one was being executed.
Four workstreams. Three audiences. One source of truth. Sales teams check status without scheduling a sync.
Strategic workstreams
Visible to all stakeholders in real time
Audiences served
Engineers, PMs, and stakeholders — one source of truth
Planning stages
Standardised across all product teams from 6 weeks out
Tool introduced
Miro — adopted org-wide after the first roadmap presentation
The current roadmap for MyLINK Portal runs quarterly in Product Plan with a full-year view, structured across four strategic workstreams: Identity, Access & Enterprise Readiness; Portal Data & Insight Evolution; Billing & Invoicing; and Portal Adoption & Onboarding. Each initiative has a clear status, owner, and connection to the Jira epics being worked on by the engineering teams. Sales teams can check the status of a specific initiative without scheduling a sync. Support teams know what's coming before it arrives.
A roadmap is a communication tool first. Accuracy is the floor, not the ceiling.
A roadmap is never just a planning document — it is a communication tool. The question is not "is it accurate?" The question is "does it give each audience the information they need, in a format they can use, without making them dependent on someone else to interpret it?"
The two-parallel-roadmaps phase was frustrating but necessary. I needed to understand what each audience actually used before I could design a system that served both. Skipping straight to the integrated solution without going through the messy middle would have meant building something elegant that nobody actually needed.
The hardest part was the tech team coordination — not because engineers were unwilling, but because asking teams to plan with shared visibility is a cultural change, not just a process change. Building that trust took longer than building the system.
“A sales manager told me they hadn't needed to schedule a roadmap sync in two months. Not because things weren't changing — but because the changes were visible before anyone needed to ask.”