Turn your sprints into a roadmap the board reads: now / next / later, with real dates

The sticky-note roadmap looks lovely on the wall and falls apart the moment someone asks "so when does that ship?" Here's how to build a swimlaned now / next / later product roadmap with real dates, release milestones and dependencies — pulled straight from your tracker — then present it as a clean one-pager and share a read-only link.

Every product leader has two roadmaps. There's the one on the wall — three tidy columns of coloured cards, warm and aspirational — and there's the sprint plan the squads actually run against, with dates, dependencies and a delivery date that keeps moving. The board is shown the first. Engineering lives in the second. Nobody reconciles them, and the gap is exactly where "why is this three months late?" lives.

The fix isn't to abandon now / next / later — it's a genuinely good framing for a room that doesn't want a Gantt chart. The fix is to give it a spine: dates that come from the plan, milestones that map to real releases, and dependencies that show which lane blocks which. A roadmap that's true, and still fits on one page.

Why the two usual tools both miss

The reason you have two roadmaps is that the tools force a choice. On one side, the work-OS / card-board tools: beautiful now/next/later views, colour-coded, drag-and-drop — and no schedule underneath. A card doesn't know its own start date, doesn't know it depends on the platform team finishing the API first, and can't tell you the quarter is already oversubscribed. It looks like a plan; it's a mood board with deadlines attached later.

On the other side, the heavyweight schedulers: real dates, real logic, real critical path — and completely wrong for a roadmap. Nobody wants a 400-line resource-loaded network to answer "what are we shipping this half?" The engine is right; the picture is unreadable, and licensing it to the exec who just wants the one-pager is absurd.

The roadmap you actually want sits between them: the rigour of a schedule with the legibility of a card board. Import the dates so they're real, present them as swimlanes and now/next/later bands, and keep it to one page anyone can open.

Build it in five steps

Take a typical product org: three squads — Platform, Growth and Mobile — each running fortnightly sprints, with a couple of releases a quarter and a hard dependency where Mobile can't start payments until Platform ships the billing API. Here's the roadmap that keeps all of that true.

1. Import from your plan — or build it. Export your tracker to MS Project XML, or an Excel/CSV dump of epics with start and target dates, and drag it onto the app. It parses in your browser — nothing is uploaded. With CSV you map columns (Item → Activity, Squad → outline, Start / Target → dates, % done). No plan yet? Type the epics straight in; a roadmap is only a few dozen rows.
2. Swimlane per squad. Group by team so each squad becomes its own section band — Platform, Growth, Mobile — with its epics nested underneath and an automatic summary bar spanning each lane. Give each lane its own shade so the board reads ownership at a glance. This is the swimlane view: one horizontal band per stream, dated.
3. Mark the releases. Promote each shipping date to a milestone — v2.0, the beta gate, the payments launch — as diamonds or flags on the axis. Use conditional symbology so a release that's slipped past its target renders red automatically, driven by the date column. Draw the cross-lane dependency (Platform billing API → Mobile payments) so the blocker is visible, not buried in a ticket.
4. Band it now / next / later. Add curtains for the three horizons — a "now" band over the current quarter, "next" over the following one, "later" beyond — so the familiar framing sits on top of the real timescale. Anything a card board would put in "later" now has to actually land in the later band, or it visibly doesn't fit. Add a data date and a status/progress line so in-flight work reads ahead or behind.
5. Present and share. Add your header, footer and logo, pick a theme, and export a landscape PDF or PowerPoint one-pager for the deck — print matches screen exactly. Or send a read-only link: the whole roadmap travels encrypted inside the link and rebuilds in the recipient's browser, no install, no login. Next planning cycle, Refresh from the updated plan and it shows you what changed before you accept it.

Swimlanes are where ownership becomes visible

The single most useful move is grouping by squad. A card board mixes everyone's work into three columns, so no one can see that Growth is quietly carrying four epics into "next" while Mobile is blocked and idle. Put each stream in its own swimlane band and the imbalance is instant: full lanes and thin lanes, on the same dates.

Because each lane's summary bar spans its children automatically, you also get a free sanity check. If Platform's lane runs to July but you told the board "platform work wraps in Q1," the picture argues with you before the board does. That's the point of dates: they don't flatter.

Now / next / later, without lying about "later"

The honest tension in every roadmap is "later." On a card board, "later" is a graveyard — anything inconvenient gets dragged there and forgotten. Band it over a real timescale and "later" becomes a claim you can check: the item has to fit in the later window, after its dependencies, or it visibly overflows. You keep the friendly framing the board likes, and you lose the fiction.

The same applies to "now." When the data date and progress line sit on the roadmap, "now" isn't just the current column — it's what's genuinely in flight and whether it's ahead or behind. A red slipped-release diamond, driven by conditional symbology off the date column, says more in one glyph than a paragraph of status prose.

Primavera and P6 are trademarks of Oracle Corporation; Microsoft Project is a trademark of Microsoft Corporation. Sketchedule is an independent product and is not affiliated with, endorsed by or sponsored by Oracle or Microsoft. Figures are illustrative, drawn in Sketchedule; Fig 2 is a faithful redraw of a product-roadmap example built in the app.