Should Product Roadmaps Have Dates?

Product Roadmaps in a Nutshell

To start with, let’s briefly recap what a product roadmap is. A roadmap is a high-level plan that states how a product is likely to evolve over the next six to 12 months. An effective, modern product roadmap focuses on the outcomes and benefits a product should provide. In other words, it is outcome-based and goal-oriented. This differs from a traditional approach, which maps features onto a timeline.

For more advice on working with outcome-based product roadmaps, watch the following video.

---

Why Dates on Roadmaps Are Beneficial

Stating dates and specific time frames on a product roadmap can be helpful for two main reasons: They allow you to state deadlines and check if your plan is realistic and actionable.

Capture Deadlines

Some products must obey deadlines or a specific window of opportunity to achieve success. Take, for example, seasonal products like games and smartphones, whose main sales tend to take place before Christmas. Having the products ready on time is essential, as a delay would have a significant revenue impact. But even non-seasonal products can be subject to deadlines. For instance, in the case of imaging healthcare devices, a working prototype usually has to be available at the RSNA’s annual meeting to announce and then be able to launch the product, as far as I know.

Similarly, I’ve experienced hard deadlines for internal, supporting products like a supply line management application that had to be released at a specific date to achieve the desired benefits. Sometimes it even makes sense to employ a release train and timebox major product releases, for example, to coordinate different products or regularly offer improvements to the users.

Ensure the Roadmap is Realistic

Even if your product is not affected by any deadline, it may be helpful to consider dates or time frames when developing a product roadmap, as this allows you to understand if the plan is realistic. A handy tool for this job is the Iron Triangle shown below.

The version of the triangle depicted above takes into account goal attainment, date or time frame, and budget. Quality as the fourth factor that influences product success is placed in the middle to indicate that it should be fixed. Please note that one of the triangle’s vertices must always stay flexible and act as a release valve to account for unforeseen events, also known as Sod’s Law. To decide which vertices can be flexed, perform an informal impact analysis. Ask yourself if it would it be better to:

• Stick to the goal but take more time to reach it or increase the budget by adding more people (if that’s helpful and possible)?
• Or should you adjust the goal to make it less ambitious but adhere to the date or time frame and the budget?

Considering these questions makes it more likely to create a product roadmap that can be actioned and it sets the expectations of the stakeholders. (For more information on the Iron Triangle and how you can determine dates and budget, please refer to my book Strategize.)

---

Why Dates on Roadmaps Are Not Helpful

Using dates on product roadmaps can create unrealistic expectations and expect teams to commit for unacceptably long timeframes: Users, customers, and sales people may regard target dates as a firm promise or commitment and insist that these are adhered to—no matter how fast the development progress is.

This can create a significant amount of pressure for the person in charge of the product and the development team; it can result in an unhealthy work environment and unsustainable pace where teams work long hours or product quality is compromised. In the worst case, a severely compromised product is shipped, a product that doesn’t properly address the user needs and is full of bugs making it expensive and difficult to enhance and adapt it.

---

Now What?

Dates on a product roadmap are neither good nor bad per se. As with many other things, it depends on how you use them and the context you are in.

Whenever you work with an external, customer-facing product roadmap, I recommend not showing any specific dates. Instead, use timeframes that are big enough, so you don’t experience a death-march situation as described above. For example, you might want to choose six-months timeframes, or even more coarse-grained, annual ones like “this year” and “next year”.

But when you work with an internal product roadmap that aligns development team and stakeholders, I would encourage you to consider stating dates or narrow timeframes, as this helps you ensure that the plan is realistic and clearly express deadlines (if applicable).

In either case, make sure that creating a product roadmap is a collaborative exercise that involves the development team and stakeholders, preferably in form of a joint roadmap workshop. This ensures that everyone has the opportunity to contribute to the plan and that people are aware of their mutual concerns and interests. What’s more, it creates stronger support for the product roadmap and better alignment of the dev team and stakeholders.

Last but not least, don’t forget to regularly review and adjust your roadmap together with the development team and stakeholders—at least once every quarter, as a rule of thumb. A product roadmap is a living document; it has to be regularly updated to account for the development progress, user data and feedback, and changes in the overall product strategy.