Main idea

Roadmap and backlog look alike because both contain topics and both are ordered. They do not answer the same question. The roadmap selects: which major topics deserve the company's attention at this horizon. The backlog organizes: how the work on already selected topics is broken down.

Granularity makes it visible. "Automate the entry of paper documents" is a roadmap initiative; in the backlog it becomes problems, features, technical tasks, design tickets, acceptance criteria, dependencies, tests, iterations. The backlog is finer because it is operational: it is there to deliver. The roadmap is coarser because it is there to align.

Two objects, two functions, and two audiences: you do not read a roadmap to know what to do tomorrow morning, you do not read a backlog to understand where the product is going.

Why it matters

It prevents the costliest confusion of the two: treating the roadmap as a product database, where you would end up filing everything the company could possibly do. A roadmap that descends to task level loses its alignment function without gaining the delivery one.

It also gives the right direction of travel: a topic goes from selection to breakdown, never the other way. A backlog does not naturally rise into a direction.

Nuances and limits

The boundary is not always clean for small topics, which enter straight at the breakdown level without ever having had a selection card — and that is legitimate.

And separating the two objects assumes they are held by the same people, or at least that those people talk to each other: two separate tools entrusted to two different functions produce two prioritizations that diverge.

Open questions

• At what size does a topic stop deserving a selection card and enter the breakdown directly?