Myth busting: Why are date-driven roadmaps not roadmaps?

Date-driven roadmaps have been standard practice – but that doesn’t mean that it’s best practice. At ProdPad, we were the pioneers in dropping dates entirely and looking at what roadmaps should really communicate – strategy. We’ve written about this extensively, too:

• How to build a product roadmap everyone understands
• Roadmaps vs Release plans
• How to sell your boss on roadmaps without timelines

Industry leaders like Teresa Torres and Jared Spool have also written about it quite a bit. There’s even an entire book about it by C.Todd Lombardo and Bruce McCarthy! And yet every few months, there’s a flurry of tweets as product managers come together to trash-talk roadmaps! You’ll see tweets covering how they’re useless and how they should never be used again… and so the poor roadmap gets a bad rep again.

But, every day more product managers are seeing the light. They have found objective-led roadmaps and can’t wait to talk about them, even if they think it’s a new methodology and aren’t aware of the wealth of knowledge available online to support this! (hint hint, you guys, check out ProdPad!)

Here’s the thing though it’s not that roadmaps are useless, it’s that the idea that roadmaps should be date-driven makes them useless – by continuing to use dates we as product managers are perpetuating the problem.

So let’s try to nail this once and for all.

Understanding Product Development

There are two parts to product development: strategy and execution.

1. Strategy = what and why (product management)
2. Execution = when and who (development)

The key to a successful product roadmap is to focus on the strategy of the future of your product, rather than how fast you will be building features.

Keep this in mind, before something is even worked on you need to figure out a few things first:

• Your product vision
• Your objectives
• Problems you are solving
• Gather feedback, research, test, and iterate

Once you have planned what objectives will drive your vision and the problems you will solve, you can then map out how that strategy will work out in the short and long term. A timeline will not reflect that, at least not accurately. This is because deadlines are too prescriptive. Being locked into deliverables at the strategy phase means you are less flexible and adaptable to change, making it harder to pivot your roadmap.

Instead of focusing on timelines, focus on time horizons: Now-Next-Later. Some people like to break this down into quarters, but I think that’s a bit short-sighted and you’re limiting yourself to the current year alone (think big!) All you need are these looser markers to give you enough structure to work, without limiting your product vision:

• Now = stuff that’s keeping you busy right now
• Next = stuff that you plan on prioritizing next
• Later = stuff you’d like to do after that, but still researching the possibilities

As you can see, the image above doesn’t have a timeline or a set release date. It’s not meant to. Your current work will take the amount of time it takes, and considering all the external factors that come into play for something to be delivered – from team growth to customer feedback – those expected release dates will shift.

This is where another little handy document comes into play: your release plan. This should include dates (sprints, release dates) to help ensure your team has the right workload so that you’re achieving those objectives you set in your product roadmap.

The big question is, why can’t you just use one document?

1. They serve different purposes
2. They’re meant for different audiences
3. They’re two parts to the puzzle: strategy and execution

But leadership wants a date-driven roadmap!

Leadership will always want to see release dates, it’s natural. You should show them your release plan, but you should show them your strategy first. If you go in all timelines blazing you’ve rushed to the end of a conversation before it’s started. What your leadership team doesn’t understand is the scope of the work, leaving them with release dates to go on. It’s a double-edged sword.

Both docs are important and should be presented together. Talk about what’s coming up for development and the expected release for those items. As a product manager it is your job to ask questions, and you need to let your leadership know how you are doing that in your strategy-led roadmap:

• What are you working on?
• Why?
• What objectives are you reaching for?
• Are your hypotheses being tested?
• What are the results of these hypotheses, and is your roadmap pivoting because of the outcome?

These big-picture questions can’t be answered with features laid out on a timeline.

It’s a little bit like telling someone you’re going from point A to point B in two weeks with no additional details. If that’s all you’re telling them, they’ll probably imagine you’ll take the quickest and easiest route, like flying first class with full lounge treatment.

In reality, the journey is going to be affected by different factors. Reframe the conversation to explain that to get from point A to point B there will be certain factors to consider along the way, such as weather changes, gas refills, bathroom breaks, switching from a camel to a motorbike because that didn’t work out as you planned, etc., This level of transparency helps your team become a bit more understanding when things come up and your estimated delivery dates are off slightly delayed.

Remember – just because something has always been done a certain way, it doesn’t mean it’s the right way. There is always room for innovation and improvement. Agile shook the waterfall world, it’s time for product roadmaps to be relaunched.