Project Management for Product Roadmaps

A roadmap is a bet on capacity, not a wish list

Most roadmaps are written the same way: someone lists what the company wants built over the next two quarters, orders it by what matters most to them, and calls it a plan. It reads well in a slide. It has almost no relationship to how much the team can actually deliver, so somewhere around week six it quietly becomes fiction, and the next roadmap conversation starts from a defensive position instead of an honest one.

The fix isn't a better slide template. It's a different input: what the team has actually finished, sprint over sprint, projected forward instead of guessed at. That number is usually smaller than anyone wants to hear, and less impressive than the optimistic version. That's exactly why it's the one worth planning against.

This is also a different zoom level from sprint planning, worth being explicit about. Sprint planning decides which ticket an engineer picks up on Monday. A roadmap decides where a theme lands relative to the themes around it, several sprints out: close enough to be useful, far enough out that the individual tasks underneath it haven't all been written yet. Confusing the two is how a roadmap review turns into a ticket-level argument, or a sprint planning meeting turns into a strategy debate nobody scheduled time for.

ShipSprint builds the roadmap view from the same sprints, releases and forecasts already running underneath it. There's no separate roadmap tool with its own data to keep in sync. What changes is the altitude, not the source, which is the whole point: a roadmap theme's forecast is only as honest as the sprint data feeding it, so keeping them the same system is what makes the roadmap trustworthy in the first place.

What velocity-based forecasting actually buys you

The honest version of a roadmap forecast gets less precise the further out it looks. That's true of any forecast built on real data rather than a fixed date, and it's worth saying plainly rather than promising false precision. What it does reliably is direction: whether a theme is tracking, slipping, or has already slipped in a way the plan hasn't caught up to yet.

That's a different kind of usefulness than a Gantt chart drawn at the start of the quarter. A Gantt chart is confident on day one and wrong by day thirty. A velocity-based forecast is less confident on day one and gets more accurate as the quarter runs, because it's updating against what actually happened rather than what was planned to happen.

The practical result: a roadmap review stops being a ritual where someone explains why last quarter's plan didn't hold, and becomes a conversation about which theme to protect now that the numbers say something has to move.

Building a roadmap from real numbers

A few habits separate a roadmap that holds up from one that gets quietly rewritten every quarter:

• Base next quarter's commitments on the last three sprints' completed velocity, not the target velocity from the kickoff deck
• Put each theme's dependencies on the board so a slip in one is visible before it delays the next
• Let stakeholders subscribe to the Monday digest instead of asking engineering for a written update
• Revisit the roadmap when velocity changes, not only at the scheduled quarterly review

One subscription, one roadmap everyone can read

A roadmap usually needs input from outside engineering: sales wants to know when a feature ships, support wants to know what's about to generate tickets, finance wants the release that unlocks a contract. Engineering, HR, marketing and operations each get their own templates and vocabulary on one subscription, so a sales lead can check a release date without learning sprint terminology to do it.

ShipSprint also connects to Claude and ChatGPT, so a question like "what's landing in Q3 for the mobile theme" can be asked in plain language by someone who has never opened the board.