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.

• Roadmap: At its very core and with much simplicity involved in this definition, a roadmap is a document that communicates the goals that the company (or product) wishes to achieve. That’s it. That’s the line.
• Timeline: A timeline visual sequencing of chronological events, with start and end dates.
• Deadline: The due date for a project or event.
• Timing: In product, timing is the strategic moment when you decide to look at something — be it kicking off discovery, or executing on it.

With that in mind, we can very easily state the following:

• A roadmap is not represented by a timeline.
• A roadmap does not have beginning and end dates.
• A roadmap is not a delivery plan.
• Adding objectives to a timeline does not communicate your goals (it simply communicates when you think the start and end to a goal is, based on your current outputs.)
• Timeline and timing are two very different things.

The last one is really important, as many people tend to mix up the two.

Knowing when to excute on something is not the same as knowing when the final result will be ready.

This is where a lot of negotation happens for product people, as it’s crucial to understand what you are giving up when choosing to focus on something new. Just every day product management things, you know?

Product managers and timelines

But wait up — if we all know that roadmaps are not based on timelines, why are so many product managers using them?

I actually did some research around this, but here’s the TLDR:

• Timelines are used to communicate with stakeholders outside of product (primarily C-Level executives, VCs and board members.)
• Product managers are forced to give timelines for things, no matter how arbritraty those may be.
• Product managers work in industries where deadlines are necessary.

The first two points I think most PMs can relate to. Having to provide timelines, even if we know they’re not true, just to appease a conversation, and deal with the blowout of things later.

The last point, however, is a painpoint that not all product managers have to deal with on a daily basis. Industry-set deadlines may not necessarily exist in SaaS, but they do exist in industries like FinTech, HealthTech, and GovTech.

Now keep in mind I said deadline, not timeline.

There’s a crucial difference here, as product teams that work in these industries have to abide by deadlines set by regulations, but at no point did anyone say they had to provide the exact date by which they were planning on starting every single project they had.

Communicating deadlines on a roadmap

I’m sure you’re sitting there thinking: is this really a thing? Can I communicate a deadline on a roadmap, when roadmaps are meant to communicate goals?

Of course you can.

Let’s not confuse the two. A roadmap still communicates goals and outcomes, but some outcomes may need to be reached by a certain regulatory deadline.

Here’s the thing: nobody said you couldn’t do that.

Just because some items on your roadmap have deadlines, doesn’t mean that all items on your roadmap have deadlines.

And that is where your roadmap still serves as an artifact of direction, intention and communication, while still being able to be transparent about deadlines that have to be met for strategic purposes.

And it is literally as simple as showing the due date on your product roadmaps, like this:

Above you can see part of my Now/Next/Later roadmap, of which one item has a due date of January 28, 2022, while the other items around it do not.

This provides the insight necessary to the viewer to understand that this one initiative does link back to a very specific deadline, but the rest still remain open to the process.

Communicating Progress

I want to be very clear when I say that just because some items on your roadmap do not include a due date, does not mean that you shouldn’t still communicate progress on them.

Part of being a product manager is being a good communicator, and constant shared understanding and transparency is key for any successful team.

Make sure that you’re still updating your team on how work is progressing, be it through your release plans or sprint kick offs and reviews.

And on the topic of release plans….

If you must, your release plans can be put on a timeline, although I still generally advise against that.

At the end of the day, all timelines really communicate are the start and end date of things.

Timelines rarely communicate all the other things that matter for teams to really be able to collaborate with each other, such as:

• Actual progress of work.
• Capacity of team members to take on new work.
• Blocking/unblocking workflows.

For product managers doubling as project managers that still have to plan releases, I’d recommend tapping into the power of a Kanban board instead.

In rare occasions, and only where strictly necessary, you can layer a timeline over your Kanban board, but at that point I dare you to ask yourself, what problem is that solving, really?

Dropping Timelines Entirely

Removing the concept of timelines is completely and entirely possible.

You can supplement a lot of that communication around deadlines with a roadmap that focuses on providing all the information necessary — including due dates and strategic initiatives, without having to put things on a timeline.

For those that feel that dropping a timeline is impossible because your c-level executives just won’t go for it, I completely understand.

Unfortunately in the real world, one must sometimes adapt to the harsh reality that while some companies may want digital transformation, they’re not entirely ready to embrace the changes that comes with.

So I propose the following: on top of that timeline you have to show, layer an actual roadmap with your outcomes, objectives, and any (necessary) deadlines that need to be reflected.

Remember, a roadmap is about communicating your goals. A timeline is about your outputs on those goals. They both support each other, but just don’t silo yourself into using just one. Use both to tell your product’s story, and see how people respond.

Originally written for airfocus.