How to build a product roadmap as a Gantt chart
Build a product roadmap as a Gantt chart: group work into themes, show real dependencies, mark releases as milestones and keep durations coarse, so the roadmap communicates direction without promising dates.
A roadmap in Gantt form shows which pieces of work depend on others and where the releases fall. Used carefully, it explains the order of the work. Used carelessly, it becomes a set of dates nobody can keep.
The short version
- A roadmap states intent; do not present bars as commitments unless they are.
- Plan initiatives and themes with coarse lengths, not features and tickets.
- Show only real dependencies: what truly cannot start before something else.
- Releases are milestones that depend on the initiatives they ship.
- Leave start dates unpinned so the roadmap re-flows when estimates change.
A roadmap is a plan, not a commitment
A product roadmap and a project schedule are different things. A schedule commits a team to dates; a roadmap says what you intend to build, in roughly what order, and why. Drawing a roadmap as a Gantt chart gives it a time axis and shows dependencies, which is valuable, but it also invites readers to treat every bar as a promise. Decide before you share it whether you are showing intent or making commitments, and say which on the chart.
Start with themes or initiatives, not features. Each initiative becomes a task with a coarse length, measured in weeks and expressed in working days, and the true dependencies between them become links: the platform work that other work builds on, the payments project that must wait for it, the redesign that follows performance work. Releases go in as zero-length milestones that depend on the initiatives they ship.
If you prefer a now, next, later view, the Gantt form is a different tool. Now, next, later deliberately avoids dates and durations, which makes it harder to over-promise. A Gantt roadmap is better when the sequence and dependencies are the message, for example when explaining to engineering leads why one initiative cannot start until another is done. Keep durations rough, round them up, and expect them to change.
QueryChart schedules in whole working days from the day the chart is created, so dates are an output of the plan, not an input. Leave start dates unpinned and the roadmap re-flows when you change a length. The example below is a roadmap with four releases, stage by stage.
A product roadmap with four releases
Fourteen tasks. Open the spreadsheet panel to see how the initiatives and releases connect.
Platform work that others build on
"API v2 foundation" takes 40 working days. "Single sign-on" starts 20 working days after the foundation starts, a start-to-start overlap, and "Performance work" (30) waits for the foundation to finish.
Growth initiatives
"New onboarding flow" (35 working days) leads into "Referral programme" (30). "Self-serve payments" (40) starts 5 working days after "API v2 foundation" finishes, so it depends on the platform work as well.
Experience and mobile
"Search redesign" (40 working days) follows "Performance work". "Mobile app refresh" (60) follows the foundation, and "In-app help" (20) waits for the onboarding flow.
Releases as milestones
"Release 1: foundation", "Release 2: growth", "Release 3: experience" and "Release 4: mobile" all have a length of 0. Each depends on the initiatives it ships, and Release 4 also waits for Release 3.
Close the loop
"Annual roadmap review" (10 working days) is the last task. A roadmap is revisited, and putting the review in the chart is a reminder that its dates will change.
How it works
Decide what the roadmap promises
Write down whether it shows intent or commitments, and put that in the chart title or a note. The rest of the choices follow from it.
List initiatives, not features
Add one task per initiative or theme, with a coarse length in working days. Use the Group field for themes so they draw as bands.
Add only the dependencies that are real
Link an initiative to another only if it genuinely cannot start or finish without it. Use a start-to-start link with a lag where one can begin partway through another, for example 1SS+20.
Add releases as milestones
Create zero-length tasks for each release and make them depend on the initiatives they contain. The chart then shows which initiative is holding a release back.
Light the critical path
View, Critical path shows the chain that decides the final date. On a roadmap it tells you which initiative to protect or descope first.
Share it as a link, and revisit it
Share the chart as a link, or export a PDF. Revisit the lengths regularly and adjust; because dates are calculated, the rest of the roadmap moves with them.
Mistakes to avoid
Showing dates as promises
Bars with precise dates read as commitments. Keep lengths coarse, round them up and label the chart as a plan.
Linking everything to everything
A tangle of dependencies hides the few that matter. Link only what cannot be reordered.
Planning features instead of outcomes
A roadmap of individual features is long, stale quickly and invites debates about detail. Plan initiatives.
Pinning start dates
Fixed starts stop the roadmap re-flowing when an estimate changes. Pin one only where an external date really is fixed.
Open the roadmap template
Open the product roadmap as your own chart, replace the initiatives and releases with yours and share it.
Related guides
Frequently asked questions
Is a Gantt roadmap better than now, next, later?
They suit different jobs. Now, next, later avoids dates, which protects against over-promising. A Gantt roadmap is better when sequence and dependencies are what you need to explain.
How long should roadmap tasks be?
Weeks to a few months, entered in working days. If a task is shorter than that, it is probably a feature or a ticket.
How do I show a release?
Add a task with a length of 0, which draws as a diamond, and make it depend on the initiatives it ships.
Can I show uncertainty or confidence?
There is no confidence field. Use the Notes field, or split the roadmap by group so near-term items are separate from later ones.
Can I compare the roadmap with what actually happened?
No. There are no baselines or planned-versus-actual views. You can record progress as a percentage.
