Case 03 — Building the Roadmap
Building the Roadmap
From a technical Jira timeline nobody could read to a system that serves engineers, product teams and stakeholders — simultaneously
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: sales teams trying to understand what they could promise customers, support teams preparing for new features, market managers tracking progress against strategy.
Stakeholder syncs were long and inefficient because people needed context that should have been visible in the roadmap. Tech teams made decisions in isolation because there was no shared surface for coordination. When dependencies created delays — which they did, regularly — nobody saw them coming because nobody was looking at the same picture.
My job wasn't to replace the technical roadmap. It was to build a system that served all audiences simultaneously, without creating more overhead for the people already doing the work.
Version 1 — Making it visible
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.
But Version 1 had real limitations. It was good for presenting. It was difficult to maintain. As soon as technical realities changed, the Miro roadmap became stale within days. And the fundamental problem remained: there were now two roadmaps — the Miro one for stakeholders and the Jira one for tech — and they told different stories.
The structural problem
The deeper problem wasn't the tool. It was that teams working on related products had no shared roadmap. Each product had its own Jira space, its own sprint cadence, its own planning rhythm. When Product A depended on something Product B was building, that dependency existed only in someone's head.
Tech teams were also making architectural decisions that affected product timelines without communicating them through the roadmap. From their perspective, they were doing their job. From the product side, it looked like the roadmap was wrong.
I tried parallel roadmaps — one for product, one for tech. Better than one, but it created new problems: two documents needing to stay in sync, by different people with different incentives. In practice, they diverged.
Version 2 — Building the system
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 stakeholders can use — 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.
The Impact Value Matrix
One persistent problem in roadmap planning was that different PMs prioritised items using different criteria. 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. 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 way to compare and commit to items across the whole product organisation during quarterly planning.
The planning cycle
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; ongoing follow-up through the quarter.
The current roadmap 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.
4
Strategic workstreams
Visible to all stakeholders in real time
3
Audiences served
Engineers, PMs, and stakeholders — with one source of truth
5
Planning stages
Standardised across all product teams — starting 6 weeks before quarter end
1
Tool introduced
Miro — adopted org-wide after the first roadmap presentation
The biggest lesson from this work is that a roadmap is never just a planning document — it's a communication tool. The question isn't "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. It requires trust that the information won't be used against them when things slip. Building that trust took longer than building the system.