post

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Customer

How behavioral economics can improve product strategy

Product Roadmap

Why most product roadmaps fail: Phil Hornby (Product Leadership Coach) – ProductTank Porto

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

Join us at #mtpcon London in 2025 – mark your calendars

Connecting fans to creators at Spotify (Dariusz Dziuk, Product Lead, Spotify)

Why teams often struggle with OKRs: A conversation with Jeff Gothelf

Deep dive: Crafting your product vision and mission

5 ways to invent and simplify as an AI/ML product manager

Emily brings nearly 15 years of product management experience to her role as Managing Director for Mind the Product. While she has worked across a variety of industries, she will always have a soft spot for the travel industry where she spent most of her early career building software for airlines and developing a leading consumer travel app, TripCase. Emily is passionate about the craft of product management and loves talking about new ways to make products people love.

Managing Director

Emily Tate

<p>We all know product roadmaps shouldn’t be timelines with lists of features. But in many organizations, that&#8217;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.</p>
<h2>The product roadmap debate</h2>
<p>If you want to incite a debate among product managers, just say the word “<a href="https://www.mindtheproduct.com/category/product-roadmap/" target="_blank" rel="noopener">roadmaps</a>”. 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.</p>
<p>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.</p>
<h3>The rulebreaker’s secret: dates on roadmaps will not kill your product</h3>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<h3>“Now, next, later” in disguise</h3>
<p>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.</p>
<p>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.</p>
<p>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:</p>
<ul>
<li>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.</li>
<li>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.</li>
<li>If it’s on the roadmap for six months out or later&#8230;it’s a thought experiment. Don’t tell a customer it’s on the roadmap for this year, don’t even <span style="font-style: italic;">think</span> about trying to give a timeframe. It’s pure fiction at this point to see what our roadmap <span style="font-style: italic;">could</span> look like if nothing changes, and give us direction as we shape our future research and experimentation.</li>
</ul>
<p>Now = &lt;3 months. Next = 3-6 months. Later = 6+ months.</p>
<h3>Show your stakeholders that your roadmap is not static</h3>
<p>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.</p>
<p>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.</p>
<h3>Leadership support will be required</h3>
<p>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<span style="font-style: italic;"> will</span> 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”.</p>
<p>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.</p>
<h3>Breaking the rules well takes skill</h3>
<p>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.</p>
<p><strong>Discover more <a href="https://www.mindtheproduct.com/category/product-roadmap/" target="_blank" rel="noopener">Product Roadmap</a> content.</strong></p>

core/freeform

Placing product bets on your roadmap by Indicative

Perfecting product roadmaps with Janna Bastow

Why roadmaps don’t matter (that much) by Stephen Culligan

Lessons learned in building product roadmaps by Jen Taylor

A designer, a product manager, and an engineer walk into a bar…by Karishma Irani

How to avoid turning your product into a feature factory by Ravi Kumar Sapata

How to adapt to unforeseen circumstances that influence your product by Patryk Pawlikowski

Roadmaps: Break the rules without breaking the principles

Emily Tate

Read more

Comments