Skip to main content

Roadmapping Without Dates: Build Yourself A Better Strategic Plan

January 24, 2013

3 minute read

You may have noticed that roadmaps in ProdPad don’t have any dates on them. Instead, you’ll only find the column headings “Now”, “Next” and “Later.”

We have a very good reason for that.

It’s roadmapping for the way product managers work

Product leaders like Martin Eriksson have been arguing against dates on roadmaps for years.

As Martin has pointed out, product managers can’t do more than make an educated guess around when a project might be completed. After all, there are so many variables that you can’t factor into a long-term roadmap: team capacity, market changes, quarterly budgets and so on.

So why bother communicating dates and deadlines on your product roadmap at all? So we made a pretty radical change: we ditched dates altogether. 

The original version of our roadmap template was like a cross between a Gantt chart and an Excel spreadsheet.

It was one of the first parts of ProdPad we built, until we realized that if we could design a much better roadmap if we ditched the dates. It would would give product managers a level of flexibility to focus on the bigger picture: product strategy and vision.

Related: How to build a product roadmap everyone understands

A product roadmap to show off your strategic plans

After we worked through a version for some clients, we added the only structure you’ll find on our roadmap: three columns called Now, Next and Later.

Public version of a ProdPad roadmap
An original view of ProdPad’s roadmap.

This brought us a lot closer to what product managers actually need: a tool to communicate their long-term product plans and strategy.

We threw out deadlines and replaced them with broader time horizons that help you show off the ranking order of your priorities.

Each card represents a theme (or “problem to be solved”) rather than a single granular idea, and cards get more and more defined as they move to from the right to left. This made strategy and priorities much clearer and easier to understand.

We’ve gotten a lot of great feedback on this – we’ve purposely left it simple and non-prescriptive, yet clear enough to help you structure a long-term product direction around.

Example of a lean roadmap

It turns out that so much more is possible when you keep dates off your roadmap. It frees you up to think about the bigger picture. What kind of product do you want to build? Who should we build for? How steps should we take to meet those goals?

Watch: The guide to product roadmapping

My co-founder Janna Bastow gave an excellent talk on our approach to roadmapping at ProductTank. I highly recommend it!

Sign up to our monthly newsletter, The Outcome.

You’ll get all our exclusive tips, tricks and handy resources sent straight to your inbox.

How we use your information

Inline Feedbacks
View all comments
January 26, 2013 5:01 pm

Thanks for the tips. Can you offer your template as a download?

February 20, 2013 2:12 am

I usually leave dates very general (quarters or half years) but I do give some kind of range because if I don’t, I find the first question I get is, “when is [feature that caught my eye] due out? What’s more helpful, I find is to be vague on the specifics of the deliverables than on the time-frames. Keeping deliverables to themes (as you have somewhat done here) such as “mobile access” or “improved notifications” allows me the necessary wiggle room to accommodate change. I do really like the status and dependencies readout on the right of the slide, though… Read more »

March 13, 2013 12:14 am

Thanks for the inspiration! This led to a post I just wrote on progressively less granular roadmaps here:

March 13, 2013 3:39 am

My future is too unstable and it discourages me (and others) to have items sitting there without working. It also call credibility into account. The instability is outside of my control (founder issues). In order to provide some coherent direction yet allowing for a diversion I’ve recently altered my roadmap to include a horizon line. I can say with a high confidence those things within the next quarter +/- a month. That is what I drive to. I am always looking to some point on the horizon. The path is less important as long as progress is made towards that… Read more »

May 22, 2013 1:59 pm


Am I missing the point or is this just another “Kanban” ?


May 27, 2013 8:04 pm

Hi Damian, thanks for pointing that out! It’s not really Kanban, although it does certainly use one of the mechanisms (measuring progress in deliverable-based chunks, not time-based chunks). I’m a big fan of Kanban as a development methodology, and think it fits well with this kind of roadmapping. The roadmap is primarily designed to communicate a sense of direction and the product vision. (ie. what areas are we going to address at various stages as we move forward?). An important distinction is that your roadmap shouldn’t include the granular items and dev tickets that your Kanban board will. It’s a… Read more »

Steve Brock
February 28, 2014 2:08 am

Your discussion and example of roadmap without dates is interesting. I can definitely see how it provides “wiggle room” to make adjustments as various requirements (market, customer, etc.) change. How do you answer your sales team who is trying to forecast a pipeline of products when they ask for specific dates, packages and prices?

March 13, 2014 5:28 pm

As you wrote on the post, the RoadMap is definitely a vision tool, where the Product team, other teams and, in some cases, clients as well, can participate (even if kind of in a passive mode) and understand the road the product is heading too. But one great value of the roadmap came in establishing a cadence and continuous planning culture in the product team. It it so close to the benefits that you can extract from using sprints in the daily development. I consider it a way to translate the Agile development culture of working in constant cadence to… Read more »

January 23, 2016 12:10 am

What do the colours of your cards indicate? In the first screenshot the text is cut off. What’s the rest of it say? (May change based on…). Do you have suggestions as to how many cards to put on the board?

January 26, 2016 2:06 pm
Reply to  Daniel

Hi Daniel, The screenshot is actually incomplete, as it was just a quick example of how an exported product roadmap might look in your own board slides. However, as an example, your roadmap might change based on the following things (or more!): – changes in the market or competition – things you’ve learned from previous product launches – availability of resources, time and team members The colors in the picture don’t mean anything, as it’s just an example, but you could imagine explaining them such as: – green cards are about Revenue – blue cards are about Growth – purple… Read more »