Why You Need a Product Roadmap Without Dates

Through my consulting work at ThoughtWorks, I see a lot of product roadmaps. I’ve seen many different approaches, but one format I’ve seen one to many times is the timeline roadmap. These roadmaps, which are full of features and delivery dates, still seem to be standard practice – but they are far from best practice. By continuing to use dates, we as product managers are setting our teams up for failure.

The Problem with Dates

To include dates in your roadmap you will need to know three things for every item. When you will start, how long it will take and when you will finish. I’ve never worked with a product team who knew all of these with any certainty, but I’ve worked with plenty who’ve guessed. To guess you have to make a whole lot of assumptions:

Firstly, you assume you know how long everything in your roadmap will take. This is probably a bad assumption since people are fundamentally bad at estimation. You might have some idea about the near-term work, but it gets harder and harder the further out you plan.

Next, you assume the future will be the same as the present. I promise you it won’t be, but I have no idea how it will be different either. People are pretty bad at anticipating the future. The only thing we can be sure of is there will be change all around you.

You’re also assuming that everything you build is going to work as soon as you finish it. The reality is it probably won’t. There will be bugs, there will be teething problems, and there will be rework. I’ve never worked with a team that got everything right the first time, and I doubt I ever will.

Lastly, probably the biggest of the assumptions is that you should build everything in your roadmap. Most likely you shouldn’t, but when you assign a product initiative a delivery date, you’re subconsciously committing to deliver it. This commitment removes your ability to adapt based on the learning from delivering previous initiatives.

As you can see a product roadmap with dates is a collection of assumptions that suggest nothing is going to change. The problem is, things do change, and I think it’s dangerous to pretend they won’t. So what should you do instead?

How to Create a Product Roadmap Without Dates

Your product roadmap should provide a high-level map to show your team and stakeholders where you are going and how you hope to get there, but it should not give them the false certainty that comes with features and dates. Here’s an alternative approach:

Define outcomes instead of features: Instead of using your roadmap to define what you are going to build, explain what you want to achieve. Rather than features, make product bets with a measurable outcome that will directly contribute to your companies objectives. Provide a sequence instead of a date: Remove the timeline and instead focus on prioritising your product bets. You can use categories, like now, next and later to help with this. These categories help you separate the near-term product bets that you understand most from the less certain bets in the future. Make time to review and adapt – In many ways, your roadmap is the output of an ongoing discovery process, with each iteration building on what you learned from the previous. Having time to review what you learned and adapt the roadmap accordingly is essential if you are to navigate the uncertainty of product development. Ultimately it is the process of developing a roadmap that is more important than the roadmap itself. The process will enable you to deal with the uncertainty of product development and the risks that come with it.

I think it’s important to highlight that it won’t necessarily be easy to remove the dates from your roadmap. Dates bring a feeling of certainty and a lot of company leaders like that. They often perceive risk in moving from a safe and predictable feature roadmap, but ironically not doing so opens them up to the higher risk of not learning and adapting. If you face objections, don’t let it put you off. Listen to them and try to show, rather than tell them the benefits of another approach.

Removing the dates from your roadmap isn’t a step into a less certain future. It’s a sign of good product leadership and organisational maturity. Coming clean and admitting that we were all making the dates up means we can have more honest conversations with stakeholders, deal with the real product challenges and adapt to the changes in the future.

Awesome, I hope to see less timeline roadmap’s in the future!