Roadmapping Without Dates: Build Yourself A Better Strategic Plan
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.
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.
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.
Thanks for the tips. Can you offer your template as a download?
You can create the roadmap within ProdPad and export it as a PNG or PDF.
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 that would not be appropriate for customers.
Thanks for the inspiration! This led to a post I just wrote on progressively less granular roadmaps here: https://johnpeltier.com/blog/2013/01/27/product-roadmap-without-dates/
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 point and it can be shown. Beyond the horizon line I have a couple of possibilities that get clearer as we get closer.
We swap projects in front of and behind the horizon line frequently based on the changing winds of the business. I am less concerned about meeting dates as getting features implemented in a timely manner. Having a flexible roadmap is a great tool to put in front of exec’s. I have them make the tradeoffs. “You want this sooner this has to move out.” Often they forget the in-flight items and when faced with reality it can be sobering.
This is only possible because we are an Agile shop. In the past I would use longer time frames and quarters but that was waterfall and a different era.
Thanks for the alternate point of view.
Hi,
Am I missing the point or is this just another “Kanban” ?
Damian
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 high-level view of the long-term vision for the product.
A Kanban board offers a much more detailed view of what’s going on day-to-day with your product development, giving an overview of what work is in progress. (For anyone else who might be wondering, here’s my favourite explanation of Kanban in software development: https://blog.crisp.se/2009/06/26/henrikkniberg/1246053060000)
You should have no problem using this format of roadmap in conjunction with your Kanban board, if that’s what your team is used to seeing.
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?
The sales team always wants solidity as that is how they make commission 🙂 I found that bringing in the sales team early in the roadmapping process discussing their priorities and what they are hearing from clients is a great way to get them engaged in the process and with that engagement they get greater understanding of the process of taking an idea from a sketch to a product.
It is when the product management process is a “black box” to outsiders that the demand for fixed time frames, prices and packages arises as it is the only way they can exert control over the process.
Try to find out why they need specific dates, packages and prices. Dig into the underlying reason and it will help you sell a time-horizon based roadmap.
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 the strategy.
This roadmap, without cadence, should at least have some kanban metrics to give some value as a tool for planning, estimating and improve. I sincerely cant see it tranquilize my CEO. That being said, I really believe you guys found someway to address those concerns that we product managers have to deal in our beloved work.
Abraços
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?
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 cards are about Integrations
– etc.
If you want to see a live example with a legend for the colors, take a look at our own roadmap here: https://www.prodpad.com/our-roadmap/
As for how many cards to include in a roadmap, this is ultimately up to you… But remember that your roadmap is a communication tool (not a detailed planning tool) so to make it easier on the eyes and brains of your stakeholders who have to read and understand the roadmap, I recommend only having as many cards as reasonably fits in a page or two when you’re scrolling down the page – ie. as much above the fold as possible.
I hope this helps!