Roadmapping Without Dates: Build Yourself A Better Strategic Plan

January 24, 2013

ProdPad Labs

You may have noticed that roadmaps in ProdPad don’t have any dates on them. Instead, you’ll only find the column headings “Current”, “Near-Term” and “Future.”

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 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 Current, Near-Term and Future.

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.

ProdPad 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!

 

Simon Cast is a product expert and Co-founder of ProdPad - building great product management software, and of Mind the Product, a global community of product managers. He has 14 years experience in building products, ranging from satellite control software to online social capital tools, and also spent time in the Australian Army. In 2010, he co-founded ProductCamp London with Janna, and he now organizes ProductTank events and the Mind the Product Conference.

12
Leave a Comment

avatar
9 Comment threads
3 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
10 Comment authors
Janna BastowDanielDiegoSimon CastSteve Brock Recent comment authors
Maximus
Guest
Maximus

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

Bruce McCarthy
Guest

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 »

John Peltier
Guest

Thanks for the inspiration! This led to a post I just wrote on progressively less granular roadmaps here: http://johnpeltier.com/blog/2013/01/27/product-roadmap-without-dates/

lmckeogh
Guest

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 »

Damian
Guest
Damian

Hi,

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

Damian

Janna Bastow
Admin

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
Guest
Steve Brock

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?

Diego
Guest

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 »

Daniel
Guest
Daniel

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?

Janna Bastow
Admin

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 »

Related articles