Flowstate - Roadmap communication

The job

Your CEO just pulled you aside after a board meeting. “The board wants to know why engineering is so slow.” You’ve shipped fourteen features this quarter, migrated two services to a new infrastructure provider, and reduced P1 incident response time by 40%. But none of that was on the slide the CEO showed the board, because your roadmap is a Jira export that nobody outside engineering can read.

The number one complaint I hear from non-technical leadership about engineering is: “I don’t know what they’re doing or when it’ll be done.” It’s almost never true that engineering isn’t delivering. It’s almost always true that engineering is terrible at communicating what it’s delivering.

Your roadmap is not a project plan. It’s not a Gantt chart. It’s not a list of Jira epics. It’s a communication tool — and its job is to build confidence that engineering knows what it’s doing, is working on the right things, and can be trusted to deliver. Most roadmap failures aren’t about content. They’re about format, audience, and update cadence.

Why it matters

Bad roadmap communication is expensive in ways that don’t show up in any dashboard.

When leadership doesn’t understand what engineering is doing, they fill the gap with assumptions — and those assumptions are almost always worse than reality. They assume you’re behind. They assume you’re not focused on the right things. They assume engineering needs more oversight. And then you end up in a cycle of status reports, review meetings, and escalations that eat into the time your teams could spend actually building things.

I watched a VP of Engineering at a Series C company lose their job over this. Not because engineering wasn’t delivering — they were. But the CEO’s perception was that engineering was a black box. When the VP finally produced a roadmap, it was a 47-page document full of technical jargon, dependency diagrams, and conditional timelines. The CEO looked at it and said, “I still don’t know what we’re shipping this quarter.” The VP was gone within three months.

On the flip side, the best engineering leaders I know spend maybe 10% of their time on roadmap communication, and it buys them enormous latitude. When leadership trusts that you’re working on the right things, they stop micromanaging. They approve headcount requests faster. They give you the benefit of the doubt when something slips. That trust starts with a roadmap they can actually understand.

What good looks like

Mature practice:

Different roadmap views exist for different audiences. The team-level view has detail. The exec-level view has outcomes. The board-level view has themes and timelines.
The roadmap is updated regularly (fortnightly or monthly) without drama. Changes are communicated proactively with context.
Uncertainty is explicit. Things further out are less defined, and everyone understands that’s appropriate.
The roadmap connects engineering work to business outcomes. Not “build search indexing service” but “improve search performance to support 10x query volume growth.”
When reality forces a change, the roadmap is updated within a week, not at the end of the quarter.

Struggling practice:

One roadmap for all audiences, usually too detailed for leadership and too vague for teams.
The roadmap is updated quarterly at best, and the version leadership saw three months ago bears no resemblance to what engineering is actually doing.
No uncertainty is communicated. Everything looks equally committed, whether it’s next week’s sprint or a vague idea for Q4.
Changes are communicated reactively. Leadership finds out the roadmap has changed when they ask why something hasn’t shipped yet.
The roadmap is a list of features with no connection to why those features matter to the business.

The approach

Build three views

You need three roadmap views. Not three separate documents maintained independently — that’s a maintenance nightmare — but three presentations of the same underlying information, each tailored to a different audience.

Team-level view: This is the detailed view. Epics, milestones, dependencies, technical work. Your engineering leads and product managers live here. It should be in whatever tool your teams use daily — Jira, Linear, Shortcut, whatever. Update cadence: weekly or continuous.

Exec-level view: This is a one-page view that answers three questions: What are we working on? Why does it matter? When will it be done? No Jira ticket numbers. No technical implementation details. Each item should connect to a business outcome. “Launching self-serve onboarding to reduce time-to-value from 14 days to 2 days” — not “building OAuth2 integration and user provisioning API.” Update cadence: fortnightly or monthly.

Board-level view: This is a half-page or a single slide. Three to five themes for the quarter, each with a one-sentence description and a RAG status. “Platform scalability — on track. AI capabilities — slightly behind, mitigated by [action]. Enterprise security — ahead of schedule.” The board doesn’t want to know about your microservices migration. They want to know engineering is executing against the company’s strategic priorities. Update cadence: quarterly, aligned with board meetings.

Use the Now / Next / Later framework

This is the single most useful framing for communicating uncertainty without looking incompetent. It works for every audience.

Now — what we’re currently building. High confidence, specific timelines, clear outcomes. “We’re shipping the new billing engine by end of March. It’ll support usage-based pricing, which unblocks the PLG motion.”

Next — what we’re planning to build in the near term. Medium confidence, approximate timelines. “In Q2, we’re tackling the reporting overhaul. Scope is still being defined, but we expect it’ll take 6-8 weeks once we start.”

Later — what’s on our radar but not yet planned in detail. Low confidence, no timelines. “We know we’ll need to rebuild the notification system at some point this year. We haven’t scoped it yet.”

This framework gives you permission to be vague about the future without undermining your credibility about the present. And it trains your stakeholders to expect — and accept — that certainty decreases with time. Which is, you know, how reality works.

Communicate uncertainty honestly

Most engineering leaders either over-commit (and then miss deadlines) or refuse to give any timelines at all (and get labelled as evasive). Neither builds trust.

The trick is calibrated confidence. Here’s what that sounds like:

“I’m 90% confident we’ll ship the core features by March 15th. The integration with the legacy billing system is the risk — if that takes longer, we might slip to end of March.”
“This is a rough estimate based on what we know today. I’ll have a tighter range in two weeks once we’ve completed the spike.”
“I’d rather give you a range than a date. We’re looking at 4-6 weeks, depending on what we find when we dig into the data migration.”

Compare that with:

“It’ll be done when it’s done” — tells leadership nothing useful and sounds defensive.
“March 15th, guaranteed” — sets you up to fail.
“Probably Q2 sometime” — so vague it’s meaningless.

Give a range. Name the risks. Explain what would change the range. Update when new information emerges. That’s it.

Update the roadmap when reality changes

Reality changes constantly. A key engineer leaves. A customer escalation reshuffles priorities. A technical assumption turns out to be wrong. A competitor ships something that changes the game.

The worst thing you can do is nothing. If leadership finds out the roadmap has changed because they asked about a feature that’s been silently deprioritised, you’ve just made a massive withdrawal from your trust account.

Here’s the protocol that works:

Acknowledge the change proactively. Don’t wait for someone to ask. “I want to flag that we’ve adjusted our Q2 plan based on [reason].”
Explain the why. Give the business context. “The Acme deal requires SOC 2 compliance by June, which means we need to pull security work forward.”
Show the trade-off. “To accommodate this, we’re moving the reporting overhaul to Q3. Here’s why I think that’s the right call.”
Update the roadmap immediately. Not next week. Not at the end of the sprint. Now. The roadmap should always reflect current reality.

The companies that handle this well treat roadmap changes as a normal part of operating, not as a failure. Because it isn’t a failure. It’s responsiveness.

Connect work to business outcomes

Every item on your exec-level roadmap should answer “so what?” from a business perspective.

Bad: “Migrate to Kubernetes.” Good: “Reduce infrastructure costs by 30% and enable zero-downtime deployments, which eliminates the weekend maintenance windows that are blocking our enterprise sales motion.”

Bad: “Build API v2.” Good: “Launch a partner API that enables our top three integration partners to self-serve, reducing our professional services bottleneck and unlocking £2M in partner-sourced revenue.”

This isn’t spin. It’s translation. Your job as an engineering leader is to help the business understand engineering work in business terms. If you can’t articulate why a piece of work matters to the business, that’s either a communication problem or a prioritisation problem — and both need fixing.

The conversations

With your teams:

“I need your help making our work visible to the rest of the company. Not because they don’t trust us, but because when they understand what we’re doing, they give us more room to operate.”
“When you give me an estimate, give me a range and tell me what the risks are. I’d rather explain a range to the CEO than miss a date.”

With your CEO / exec team:

“I’d like to share a monthly roadmap update — one page, focused on what we’re shipping and why it matters. Would that be useful?”
“Here’s what changed since last month and why. The short version: [one sentence]. Happy to go deeper if helpful.”
“I want to be transparent about uncertainty. Items in our ‘Now’ column are high confidence. ‘Next’ items are planned but may shift. ‘Later’ is directional.”

With your board:

“Engineering is executing against three strategic themes this quarter. Here’s a one-line status on each.”
Keep it ruthlessly simple. If you’re spending more than 90 seconds on engineering during a board meeting, you’re in trouble — either because there’s a genuine crisis, or because you haven’t distilled the information enough.

With Product:

“Let’s co-own the exec roadmap view. You bring the business context, I’ll bring the delivery reality. Together we present a plan that’s both ambitious and credible.”
This is important: the roadmap should never look like an engineering document that product hasn’t seen, or a product document that engineering hasn’t validated. Joint ownership prevents the “engineering says it’ll take twice as long as product promised” dynamic.

Trust-building language:

“Here’s what we committed to last quarter, and here’s what we actually delivered.”
“I got this estimate wrong last time, and here’s what I’ve changed in our estimation process as a result.”

Trust-eroding language:

“We need more time” (with no explanation).
“That’s not what engineering signed up for.”
“The roadmap is aspirational.”

Common failure modes

The Gantt chart delusion. A detailed, task-level Gantt chart that purports to show exactly what every engineer will be doing for the next six months. It’s wrong before it’s finished, and maintaining it becomes a full-time job. Gantt charts are useful for construction projects with known, sequential tasks. Software development is not that.

Audience mismatch. Showing the board your Jira board. Showing your engineers a strategy slide. Every audience needs the right level of detail, and getting it wrong in either direction destroys confidence.

The never-updated roadmap. Created with fanfare in January, never updated again. By March, everyone knows it’s fiction but nobody says so. By June, leadership has lost trust entirely.

Conflating a roadmap with a commitment. If everything on the roadmap is treated as a promise, you’ll either stop putting anything on it (to avoid accountability) or pad everything so aggressively that it’s meaningless. A roadmap is a plan. Plans change. Being explicit about that is strength, not weakness.

Hiding bad news. Burying a missed deadline in a dense update, hoping nobody notices. They always notice. Surface problems early and with a plan for how you’re addressing them. “We’re going to miss the March date by two weeks because of [reason]. Here’s what we’re doing about it” is infinitely better than silence followed by “so, about that feature…”

Solo ownership. An engineering-only roadmap that product hasn’t validated, or a product-only roadmap that engineering hasn’t estimated. Either one is a recipe for credibility damage. The roadmap should be a shared artefact.

Getting started

If your roadmap communication is currently a mess — or nonexistent — here’s how to start this quarter without boiling the ocean:

Create the exec-level view. Just one page. What are the three to five most important things engineering is working on right now? Why do they matter to the business? What’s the expected timeline? This takes an afternoon, not a week.
Send it to your CEO. Not in a formal meeting. Just an email. “I wanted to share what engineering is focused on this quarter and why. Happy to discuss.” You’ll be amazed how much goodwill this generates.
Set a monthly update cadence. Same format, every month. What shipped, what’s in progress, what changed and why. Keep it to one page. The discipline of doing this regularly matters more than the format.
Adopt Now/Next/Later. Start labelling your roadmap items by confidence level. It’ll feel uncomfortable at first — you’re explicitly admitting you don’t know everything. That’s the point.
Track your accuracy. After one quarter, look back: how closely did reality match the roadmap? Not to punish yourself, but to calibrate. If you’re consistently off by 30%, your estimation process needs work. If you’re within 10%, you’ve earned the right to ask for more trust.
Get product to co-own it. The roadmap should be a shared document that both engineering and product stand behind. If product is promising things engineering hasn’t validated, or engineering is building things product hasn’t prioritised, you’ve got a bigger problem than roadmap formatting.

The whole point of a roadmap is not to predict the future perfectly. It’s to give the people who depend on engineering enough information to make their own decisions. When sales knows what’s coming, they can plan their pipeline. When finance knows what’s planned, they can forecast costs. When the board knows what’s happening, they stop asking “what’s engineering doing?”

That’s the job. Help everyone else do their job by communicating yours clearly.

Building Long-term Credibility — consistent, honest roadmap communication is one of the most powerful credibility-building tools you have.
Building Long-term Credibility — tracking your delivery accuracy over time is how you calibrate your roadmap and build trust in your estimates.
Scenario Planning — when reality forces a roadmap change, scenario planning helps you evaluate the options before committing.