Move Items on Roadmap: What are your suggestions for product leads when they need to efficiently explain that an item on the roadmap needs to move because some other item has become more important?

Moving items in priority on the roadmap is going to happen. This is especially true if you are required to have a long-term roadmap. However, even with short-term roadmaps, it will happen. While I don't know the exact reasons why your company requires you to write long docs and create decks to explain this, I believe that the general intent is probably to make sure that everyone knows why things moved, what the impact is, and how it will help the company as a whole. I think that there are a few things that you can do to help alleviate the pain product managers in your company are experiencing.

1. Make prioritization decisions based on data as much as possible.

   1. If you are making decisions based on gut instincts, it is going to be extremely hard to communicate and defend your decisions.

   2. Use some sort of prioritization framework for deciding what to prioritize when planning your roadmap. This will help to minimize how often this happens to your roadmap. When it does inevitably happen, though, you will have the framework to use as a defense. Personally, I like to use the RICE model. It allows you to efficiently and effectively show why you prioritize certain things. But, find something that works for you and your company, but shows exactly why you are making the decisions.

2. Create a template for the collateral you need to produce.

   • Using the information you are required to document and present, have a standard doc and presentation template that all PMs use. This should save you a lot of time by only needing to fill in the justifications, rather than making each product manager come up with it on their own. Of course, the exact structure is going to depend on what you are required to explain, but my suggestion would be to include the following sections:

   1. What is the decision that was made?

      • Be brief and specific. "We have moved X feature out by X months in order to prioritize development on Y feature."

   2. Why was the decision made?

      • Be clear on what made you moved things around. "After conducting more research on the impact of the two features, we came to the conclusion that Y feature will have a greater impact on ARR if we can deliver it sooner. Here's why."

      • Establish your goal in making the decision. You are all in the same company, executing on the same vision, and wanting the same outcome (for your company to be successful). How does your decision support the vision of the company?

      • Provide the data you used to make the decision. Show why prioritizing the new feature will be best for the company. Whether the reason is ARR, a new regulation, a security vulnerability, a shift in the market, a new competitor's feature, etc., you will be able to defend your decision. Be transparent, even with customers (as much as is legally allowed).

   3. What is the impact of the decision?

      • Show that you understand what the change means to your company and customers. You didn't make the decision in a vaccuum (I hope), so you should be very aware that some customers were relying on the feature that you moved further out on your roadmap. Be empathetic to what this means to them, the sales people in your company, and the marketing and executive teams that may have been promoting the upcoming feature.

   4. What is the new timeline for the feature you moved out?

      • Make sure that everyone understands that if you moved the feature out, you are still planning on implementing it. If you removed the feature from the roadmap completely, make sure to be very specific about why you removed it.

3. Document decisions as you go.

   • You should already have the work you did with the prioritization framework. That is your main supporting work for your decision.

   • Figure out the new timeline for the feature you moved out and make sure that is documented somewhere before the decision is final.

Again, I don't know any of the specifics for your company or the cases that happen there, so I hope that some of this will help out with efficiently communicating your decision. However, in my opinion, if you do all of this, none of the information needed in the doc or presentation should take you very long to produce. If you made your decision based on data, most of your work has already been done. At that point, it is down to getting the information communicated in a format that is acceptable for your company. Having an established template for presenting that information should help with the time it takes to create the collateral.

A straightforward formal approach is better when recommending changes to the roadmap. Its important to cover both the urgency and the impact on previous priorities. To convey changes you may focus on following :

• Provide Context: “We’ve identified a critical priority that requires immediate attention due to recent developments. Here’s why it necessitates a reordering.”

• Link to Strategic Goals: “This shift aligns with our strategic objectives, supporting our growth targets and enhancing value delivery to our customers.”

• Emphasise the Value: “Advancing this new item is expected to increase retention, revenue, and our competitive position—making it a timely addition.”

• Acknowledge the Impact: “We recognise the effort invested in [original item] and appreciate your work. Although it’s being deprioritised temporarily, it remains a part of our roadmap.”

• Outline Next Steps: “A revised timeline will follow. In the meantime, please reach out with any questions, and thank you for your adaptability as we work towards our shared goals.”