Writing

A Data Team Without a Roadmap Is a Ticket Queue

Data teams are unusually prone to becoming reactive. The requests come from everywhere, and each one is legitimate: a VP wants a number by Thursday, sales needs a dashboard, finance found a discrepancy, product wants a model. Say yes to all of them in the order they arrive and the team becomes a ticket queue — busy, useful, and completely invisible as a strategy. A roadmap is what stops that. But most data roadmaps are a slide from last quarter that nobody believes, which is worse than having none, because now the team looks like it has a plan and doesn’t.

The fix is not a bigger planning tool. It’s a small, opinionated process with a few rules that keep the roadmap honest enough that people actually read it.

Why data teams drift into the queue

Three things make data work especially hard to keep on a roadmap.

The intake is unbounded and every requester is a real customer — you can’t just route them to a backlog and forget it. The deliverables are fuzzy: a metric definition, a pipeline, a model, and a “quick pull” can each hide a week or an hour, and they look the same going in. And a lot of the most important work is invisible — a quarter spent hardening the platform so the next year of analytics is trustworthy shows up to a stakeholder as nothing at all.

Put those together and, absent a spine, the loudest request wins and the team’s strategy becomes whatever landed in the inbox that week.

What the roadmap is actually for

A roadmap does two jobs, and neither of them is “list the work.”

Outward, it sets expectations and gives you a way to say no that isn’t personal: that’s Later, here’s why, here’s what it’s behind. Inward, it’s a spine — the team knows what matters this month, and the invisible platform work has a place to live where it can be defended.

But the real output of a roadmap isn’t the board. It’s trust. Leadership funds and protects a function it can see thinking ahead. A roadmap that turns out to be wrong buys the opposite — once it lies once, people stop reading it, and you’re back to the queue with extra steps. So the entire craft is keeping it honest. Everything below is in service of that.

Horizons, not dates

Sequence the work into Now / Next / Later (plus Parked for the deliberately deferred and Released for the shipped). Not dates.

Data work is too uncertain to promise dates you’ll miss, and every missed date is a withdrawal from the trust account. Horizons communicate intent and order without the false precision. “This is Next” is a commitment you can keep; “this ships March 14th” is usually a fiction everyone silently discounts.

One line per epic

The grain of the roadmap is the epic — one roadmap line is one meaningful outcome. The tasks underneath it live on the team’s execution board and roll up; they never appear on the roadmap itself.

A roadmap you can see individual tickets on communicates nothing to a VP — it’s noise. Ten epics arranged by horizon communicate a strategy at a glance. If someone needs the task detail, that’s a different view for a different conversation (more on that below).

Done means released

This is the rule that does the most work, and the one teams skip. The moment an epic ships, it leaves the live horizons and moves to a Released log — immediately, every time.

Skip it and Now quietly fills with finished work. The roadmap stops describing the present and starts describing the past, and that’s the exact moment it becomes a lie. Moving shipped work to Released also gives you something valuable for free: a running, dated record of everything the team has delivered. That log is your credibility trail the next time someone asks what the data team has been doing.

Cap what’s in “Now”

Put a hard limit on how many epics can be Now at once — two or three per initiative.

A roadmap where everything is “Now” is just a list; it communicates no priority, which means it communicates nothing. The cap forces the prioritization you were avoiding: if a fourth thing genuinely has to be Now, something else stops being Now, out loud, and the person whose project just slipped hears it from you instead of discovering it in three weeks.

A scope fence

Name the handful of initiatives the team owns — the four or five themes that all real work rolls up into. Anything that doesn’t fit one of them isn’t roadmap work; it’s a favor or a polite no.

The fence is how you say no without it being about the person asking. “That’s a good idea and it’s outside what this team is chartered to own this year” is a much easier sentence to say — and to hear — than a judgment call made fresh under pressure each time.

Two views of one source

The same board has to serve two audiences that want opposite things. Leadership and cross-functional partners want the business view: epics grouped by horizon, no detail — what’s coming and roughly where it sits in the sequence. You and the people doing the work want the planning view: status, owners, dependencies, and how far each epic’s sub-work has actually progressed — the detail you need to run the thing, and to have a real conversation with your exec sponsor about trade-offs.

The mistake is to build those as two documents. The instant they’re separate artifacts they drift, and the drift always surfaces in the meeting where it hurts most. Build them as two views of one underlying board instead — same epics, same truth, filtered differently for who’s looking. The weekly review below is what keeps that single source honest enough to serve both.

The weekly reconciliation

A roadmap is a forward-looking claim, and it rots the moment the work diverges from it. Nothing above survives contact with a busy month unless there’s a standing ritual that reconciles what you planned (the roadmap) against what actually happened (a simple work log the team keeps).

Once a week, produce a diff:

• Shipped — anything the log shows delivered flips to Released.
• Moved — horizon or status changes since last week.
• Stale — open epics untouched for two weeks: decide or drop them.
• Orphaned — epics missing an owner or an initiative; every line needs both.
• New intake — fresh requests triaged into an epic, Parked, or a no.
• WIP check — any initiative with too much in Now.

Then you review it by exception — you only look at what moved, stalled, or is new, never the whole board — and it produces a short status note you send out: what shipped, what’s in flight, what’s next. That weekly note is half the value of the whole system. It’s the drumbeat that keeps the function legible to everyone who doesn’t sit inside it.

This is a job worth handing to an agent

Look at that weekly review again: pulling the board, reading the log, matching shipped work to epics, flagging what’s stale, formatting the diff and the status note — almost all of it is mechanical. The only part that needs a human is the deciding: is this stale thing dead or just slow, does this request become an epic or a no.

That split is exactly where agent assistance pays off. The agent compiles the state, proposes the diff, and — once you’ve decided by exception — applies the updates and drafts the note. It turns a review that a stretched lead would quietly skip into a fifteen-minute standing ritual that actually happens. And a process you don’t run isn’t a process; it’s a document.

The takeaway

The roadmap’s output was never the board. It’s a data function leadership can watch think ahead, and trust because what’s on the board matches what’s true. Horizons over dates, one line per epic, done-means-released, a cap on what’s in flight, a fence around what you own, and a weekly reconciliation to keep the whole thing honest. Run that, and the team stops being a queue and starts being a function with a strategy — which is the only version of a data team that gets to decide what it works on next.

← All writing