Back

Should you use Gantt charts for your product roadmap?

Created on by Till Quack (guest post)


Image Should you use Gantt charts for your product roadmap?
Photo by Kolleen Gladden

Gantt charts are one of the most common ways to visualize project plans. Hence they are also frequently used for product roadmaps, and most roadmapping tools offer Gantt chart views. But are Gantt charts the appropriate way to plan and visualize your product roadmap? This article explores alternative ways to show your product roadmap, and how to use Gantt charts without creating conflict with modern approaches such as Agile or outcomes over output.

Estimates versus commitments

Independent of how a plan is visualized, the most important factor for success is if there is a common understanding in your organization of how to interpret a plan. Is a plan perceived as a plan that can and will change, or a hard commitment to hit deadlines? Considering von Moltke’s famous quote “No plan of operations extends with any certainty beyond the first contact with the main hostile force”, any longer-term plan should be seen as a continuously updated best guess of the future actions. And not as a hard commitment(1).

Being composed of bars with a defined start- and end date, Gantt charts are naturally tempting to interpret plans as commitment. However, as long as in our organization there is a common understanding that a Gantt type plan is “just” a plan, they can still be useful to experiment with and visualize plans.

Of course, communicating some expectations on when something will ship are essential to keep teams aligned, in particular for cross-functional collaboration. Think of marketing and PR teams, who need to prepare product release materials and announcements, for example. Again, as long as there is consensus on that dates might change, and the plan simply reflects the latest known state, things should work out.

A final point to consider is the granularity of the Gantt charts you use. Are you planning for exact dates, or on a more granular level such as weeks, months, or sprints? Just moving to coarser dates implicitly removes hard deadline commitments. Saying “this item will be done in week 52 or in one or two sprints” rather than “this will be done on Oct 23” inherently carries the uncertainty of planning much better.

Priorities vs deadlines

Am alternative to planning with durations and deadlines is planning by priorities. Your plans become simple lists of stack-ranked priorities. What’s higher on the list is a higher priority and should be worked on and shipped first whenever possible. This approach works particularly well when working with organizational goal frameworks such as OKRs, which are often applied in a quarterly rhythm. You can split your product roadmap into calendar quarters, and tracks or business units. Each calendar quarter simply has a set of stack-ranked priorities. This simple approach can be an easy and incredibly effective way to plan and share product roadmaps.

Below we show an example of the shipit roadmap, once as stack ranked list and once with Gantt-style chart visualization. While the Gantt chart is often visually more appealing and allows to express the duration of items in sprint granularity, the stack-ranked priority lists are simple and effective.

Gantt style view of product roadmap
Priority list type view of product roadmap

In summary

Gantt charts can be an effective way to visualize your product roadmap, but it is important that your organization is aligned on how to interpret the meaning of a Gantt item’s duration and deadline: as an estimate or as a commitment. An alternative to Gantt charts are simple stack-ranked priority lists. These focus the discussion on the priority of efforts, rather than deadlines. They also can be nicely combined with OKRs and quarterly planning processes.

(1) A commitment of a deliverable covering a short period of time, such as a two-week sprint, can be made without contradiction: the shorter the time period the less uncertainty in estimating.