Roadmaps: Break the rules without breaking the principles

We all know product roadmaps shouldn’t be timelines with lists of features. But in many organizations, that’s what executives and stakeholders want, or even require. So, if you can’t win the battle on roadmap structure, this post will take a look at ways to stay true to the principles of a flexible roadmap.

The product roadmap debate

If you want to incite a debate among product managers, just say the word “roadmaps”. As our practice has matured, we have moved away from accepting that product roadmaps have to be lists of feature requests with dates attached, and have developed principles that help us to align conversations, focus on the outcomes we’re trying to achieve, and maintain the flexibility we need to respond to new information and research. These ideas are sound, but we often get caught up in the dogma of how they are presented.

While flexible-by-design formats like “Now, Next, Later” are great, the harsh reality is that many product managers don’t work in organisations that are prepared to accept this level of fuzziness. In trying to force a different format, we can end up alienating our stakeholders and derailing the real conversations a roadmap is intended to drive: how can we best provide value for our customers? But forfeiting the format battle doesn’t mean you have to abandon the principles altogether. You just have to be very intentional about how you break the rules.

The rulebreaker’s secret: dates on roadmaps will not kill your product

Rule #1 of a roadmap to many product thought leaders is “No dates on your roadmap”. The reason for this is that our dates are pure fiction. Humans are terrible at estimating time. Your 10-minute walk is likely 20 minutes, and every recipe that claims it takes 30 minutes to cook is downright lying. So when we put out a roadmap in January that claims to know what will happen in October, we fully set ourselves up for failure.

Our stakeholders, on the other hand, love dates. It gives them an illusion of certainty that they can use to plan. And this is where the friction lies: our insistence that we can’t give even a vague timeline of activities makes life incredibly difficult for our colleagues. By holding too tightly to this concept, we become the thorn in the sides of people we need to collaborate with, and in the worst case, we may just get overruled and forced to make a date-based roadmap.

So if you find yourself in a position where you argue more about the fact that you aren’t giving any dates than you are about the actual items on the roadmap… maybe just put dates on it.

“Now, next, later” in disguise

Once you put dates on your roadmap, the challenge becomes how you give people the comfort of dates without the implied commitment of delivery. My secret is to treat my date-based roadmap as a “now, next, later” roadmap in disguise. This can be tricky, and you definitely need leadership support to make this work. But it is possible.

Think about a roadmap that shows January, February, and March with a good amount of detail, then shows Q2 with slightly less detail, and then Q3-4 at a high level. Congratulations, you’ve just created a flexible roadmap! And by only showing full detail on the next three months, you have ensured that you will have to revisit the roadmap regularly, as you add more detail to the later quarters.

Let’s take this a step further: how do you work with a roadmap that is built out 12 months at a time? It’s possible to treat it the same way, but it requires you to be an over-communicator. You have to consistently and constantly reinforce your message of your confidence levels, and how the roadmap is to be used. When I had a 12-month roadmap, I became a broken record to anyone who might have an interest in my product:

• If it’s shown in the next three months, it is in work and we know a lot by this point. It’s pretty likely it will happen within a few weeks of what we expect, and we will communicate if anything changes.
• If it’s three to six months out, we intend to work on this and it will likely happen, but the timing is really uncertain. As we learn new information, have a shift in priorities, or if other things take longer than we expect, there is a good chance that timing will shift. You can talk about this as something we’re looking at, but don’t try to guarantee timing.
• If it’s on the roadmap for six months out or later…it’s a thought experiment. Don’t tell a customer it’s on the roadmap for this year, don’t even think about trying to give a timeframe. It’s pure fiction at this point to see what our roadmap could look like if nothing changes, and give us direction as we shape our future research and experimentation.

Now = <3 months. Next = 3-6 months. Later = 6+ months.

Show your stakeholders that your roadmap is not static

You can’t create a date-based roadmap once a year, tell people it’s not a commitment, and then not touch it for another year. In order to make it work, you have to actively revisit, and regularly recommunicate your roadmap. You also need to show that there are regular changes; mostly because there will be changes (let’s be honest), but also to reinforce that this is a living document and people shouldn’t get too attached to it.

I would generally revisit a date-based roadmap every month to see if things still feel valid, and if any items in the “now” range have changed. Then every quarter, I do a bigger reshuffle: pull things in the “next” range forward, defer the items that aren’t really moving to “now”, and probably take some things off of the later or reorder things. Most importantly, I make sure everyone is aware of the changes. When your stakeholders will eventually understand how the roadmap is used when they see enough movement.

Leadership support will be required

Particularly if you are just beginning to try to hack your date-based roadmap into a flexible roadmap, you need to make sure your leaders are aligned from the outset. Even if you do everything right — you constantly explain how your roadmap should be used, make regular changes, and communicate those changes—I can guarantee you that someone will come back in the first year and try to say “but it was on the roadmap for October and this customer won’t sign if we can’t deliver it then”.

If your leadership is not on board and overrules you (or if you’re the leader and overrule the team), that will become the new playbook for how to get something built. But if, the first time it happens, the response from whoever they escalate to is, “Well that sounds like a really difficult conversation with that customer. We should start talking about how we can provide value for them with what we have today, and paint a vision for where we’re headed”, those loophole-style conversations will eventually go away.

Breaking the rules well takes skill

It is easy to break the common rules of roadmapping, especially when it makes your executives happy. It is very difficult to do it well, and to not let it take you down the path to becoming a feature factory. But if you really understand the problems you’re trying to solve in a flexible roadmap, you can find ways to achieve your goals without adhering to the “perfect” format. As long as you stay true to the underlying principles, your roadmap will still be a good alignment tool… even if it happens to have dates.

Discover more Product Roadmap content.