Roadmaps vs Timelines vs Deadlines — what do all these things mean anyway?

When talking about roadmaps, the inevitable question of “when will this be done?” always comes up. Product managers are always under stress to communicate when things will be ready, when the majority of the context that we work with revolves around why things should be ready.

Over the years, roadmaps have evolved to become more descriptive around the work that we do. They’ve become much more representative of communicating what, why, and for whom, and how things tie back to our objectives.

This has of course made roadmaps more accessible, shareable, and comprehensible across teams — but the pesky little question still remains: how do you communicate time?

As always, I like to tackle questions in short and long form, so here we go:

Should product managers be using timelines?

Short answer: lol, no. Stop, drop, and roll — and let that timeline set itself on fire.

Long answer: It’s a lot more complicated than that, because the question itself comes with certain implications.

Timeline haters of the world, don’t worry, I’m not about to advocate for them at all. It is important, however, to address where this need comes from and how to appropriately deal with them.

TLDR

• Roadmaps, timelines, deadlines and timing are all different things.
• Product managers are forced to use timelines even when arbitrary.
• Product managers do have to follow certain regulatory deadlines in certain industries.
• Communicating deadlines on roadmaps is possible.
• Don’t drop the ball — make sure you have internal team transparency with sprint kick-offs, reviews, and roadmap presentations!
• Unblock work with Kanban boards on the release level.
• Roadmaps vs Timelines — can you really drop the timeline entirely?

Definitions

Before we move forward, I thought it important to acknowledge and establish what all of these terms mean in order to set a baseline for this conversation.