Do you use dates on your product roadmaps?

If the answer is yes, do you use detailed dates or date ranges? What's your reasoning for the choice?

11 Replies

Dates in roadmaps are an illusion. 

Even date ranges can be difficult. When I say "2Q", you heard, "We plan to finish by June 30, barring unforeseen circumstances" but your executives heard, "Without a doubt, we will deliver no later than April 1 ." And sales people heard, "Start closing deals on February 15"—since they plan to pre-sell it and will need new pricing, collateral, and a canned demo.

Many teams create a roadmap comprised of every story with planned delivery dates —dates which are often aggressive. Meaning, “this is when we hope we’ll deliver it,” without taking into account velocity or bandwidth or other priorities. These types of roadmaps have two problems: they overcommit your available resources and they leave little room for adjusting your plans based on new commitments.

Johnson’s Rule of Resourcing: We’ve allocated 100% of our resources to the roadmap. We’ll use the other 100% for special requests.

We’ve taken a different approach. My recommended roadmap is a report of your actual plans, not a graphic of dreams. Our roadmap format shows items that were recently delivered, those that will be released soon, items we’ll work on next, and those planned for the future.

[Source: Under10 Playbook at]

The great part about a roadmap report is it always reflects your current plans so it’s never out of date. And you don’t have to scramble to prepare it—since it’s a report, it’s always ready.

The roadmap is a key deliverable in product status or vision presentations. Communicate what you know but limit the details on your stretch goals.

This is brilliant, Steve - simple, clear, with date flexibility built in. Assembling my own right now.

I typically use time estimates but not dates -- so 3 months, but not July 1st. This gives me license to move different roadmap pieces around and change the order but overall stay on track.

Depends on the roadmap type and audience.

My roadmaps for analysts and investors tend to be high level and theme oriented, laid out over the next 1-2 years. They explain the product position and vision.

For me, Customer roadmaps are more for the next 6-12 months and are laid out in themes and initiatives, with indications of what's committed vs working plan. Steve's example is one way to work this. This lets you explain your priorities and agile manage your individual projects and adapt to all the usual uncertainties of market feedback, undiscovered technical challenges, and emerging requirements. As more and more customers are Agile oriented themselves, I see less and less of the kinds of conversation traps you fell into with old roadmaps.

You should be able to tell customers what your priorities and what kinds of features you are working on for the market, without committing to specific dates and features. It's a useful discipline to put together a roadmap and collect feedback from customers. It aligns the org and gives the PM opportunity to get market validation for the product's direction.

I have several PPT templates I keep recycling that explain the product vision and get fuzzy toward the end of the planning horizon.

We had a good thread going on this topic over here:

Check out the resources there.

Hey Jenny!

Great question! At Receptive we typically recommend not using exact dates on your roadmap. This can cause a lot of pressure if you're unable to meet the deadlines for whatever reason, especially if you make your roadmap public (which is a whole other debate!).

A good idea is to use quarters (Q1, Q2, Q3, etc.) which gives you enough time to play around with deadlines without committing too much.

Hope that helps!


Agree @ the public roadmap, Joe! Seems like there's a lot more pressure these days from customers and even the media to share your company's plans.

Yep, customers are definitely holding us all more accountable! But that's not necessarily a bad thing!

I work on a horizon 2 product so we are discovering market needs as we develop and the roadmap is highly volatile. However, our internal stakeholders still have expectations around delivery so we do our best to estimate dates for the quarter (which you may consider more project planning than roadmap). Beyond that it is a list of current perspective on priorities. Luckily we have a mature organization and changes in schedule and priorities do not cause stress or undue pressure as long as the changes were made for the right reasons.

Externally we only share general priorities for roadmap.

We use the following categories for our product roadmap:

  • Current (1-3 mths)
  • Next (3-6 mths)
  • Future (>6 mths)
  • Completed

It's really a rolling list of features that we want to complete within the category time frame. Sometimes a feature will remain in the Current list for 4-6 mths, this doesn't change the fact that we're currently working on the feature and it needs to be complete before starting a 'Next' feature.

This way I can very quickly communicate what we're currently working on and what we're going to work on to our stakeholders and customers.

Depending on the level of maturity I might or might not use end dates. When I do this I will always take care to evaluate the team's feedback on required time considering that there's always underestimation and unforseen circumstances. Even then end dates are given including a buffer. But generally I prefer date ranges which when accepted can allow for leeway (especially market timing) and possible optimizations. This way my worst roadmap was 1.5 weeks off

We got quarterly priorities and it's on us to deliver anytime within a quarter. Those are must haves and we usually deliver lost of other stuff. We don't set strict deadlines, that would push dev team under heavier pressure. We trust each other and know that we work as fast as possible. Just push a bit to complete sprints and move only minimum issues to the next sprint.

Separation of epics into small tasks (usually 1-2 days effort) and smart prioritization gives us clear estimates on completion dates. So even without dates we can predict what will be finished when for the next month or two, with accuracy of +-1 week. Planning behind a quarter isn't very useful as priorities often change. But with +-1 month we could go up to half a year.

One more thing - having estimates of completion dates doesn't automatically mean the we publish it widely. Sales and customers would put us under pressure and we would lost the freedom to reflect on new ideas and changes. Instead we prefer to communicate estimates that will be reached if nothing has changed.