How to plan and present a product roadmap on a canvas
Plan a product roadmap on a canvas: gather the bets, group them into themes, lay them out as now, next and later, then present it as a short path.
Most roadmaps start life as a spreadsheet. Rows of features, columns of quarters, a colour for every team. Then someone has to present it, and the spreadsheet goes on a slide at a size nobody can read.
A canvas gives the roadmap room to be a picture first. You can see the themes, the dependencies and the gaps before anyone argues about dates.
Here’s a way to build one, and walk people through it.
Decide what kind of roadmap this is
Roadmaps do different jobs for different rooms. Pick one before you start.
| Audience | What they need | Level of detail |
|---|---|---|
| Leadership | Direction and trade-offs | Themes, not features |
| Product and engineering | What’s being built, and in what order | Features and dependencies |
| Sales and support | What’s coming that customers will ask about | Outcomes, rough timing |
| Customers | Where the product is heading | Themes, no firm dates |
Write the audience at the top of the canvas. It stops the board growing in every direction at once.
Dump the bets
Start wide. Put every candidate on the canvas as its own note: features, fixes, experiments, technical work, open questions.
Pull them from wherever they live.
- requests from customers and the sales team
- findings from research
- known technical debt
- ideas from the team
- commitments already made
Don’t sort yet. A messy board of forty or fifty notes is a normal starting point.
Cluster into themes
Now drag related notes together. Name each cluster as an outcome, not a category.
| Category label | Outcome label |
|---|---|
| Onboarding | New teams get value in their first day |
| Reports | Managers stop exporting data to spreadsheets |
| Performance | Large accounts load without waiting |
Outcome labels make the roadmap about why, not just what. They also make it easier to say no. A note that doesn’t serve any theme is a candidate to drop.
Aim for a handful of themes. Three to five is easy to remember.
Lay it out as now, next, later
Dates invite arguments. Horizons invite conversation.
Draw three wide columns:
- Now. Being worked on, or about to be.
- Next. Likely soon, once now is done.
- Later. Direction, not commitment.
Run the themes as rows across all three. Place each note where it belongs. The result is a grid you can read from a distance: which themes are busy now, which are waiting, which are mostly ideas.
If your organisation needs dates, add them only to the Now column. Further out, a rough quarter is honest enough.
Show what depends on what
This is where a canvas earns its place.
Draw arrows between notes that depend on each other. “Single sign-on” before “enterprise trial”. “New data model” before “custom reports”.
Step back. You’ll often spot a note in Later that blocks three things in Next. Move it, or have that conversation now.
Use colour sparingly. One colour for committed work, one for exploration, and grey for everything parked. That’s usually enough.
Make the trade-offs visible
A roadmap is as much about what you won’t do as what you will.
Keep a small frame on the canvas called Not now. Move the notes you’ve decided against into it, with a one-line reason.
- “Offline mode: few customers asked, high effort.”
- “Second language: after the onboarding work lands.”
When someone asks “what about…?”, you can point at the frame instead of reopening the debate.
Turn the board into a path
You won’t present the whole grid at once. Plan a short route.
- Open wide. The full board, briefly, so people see its shape.
- The themes. One frame per theme: the outcome, and the two or three bets that matter most.
- Now in detail. What’s happening first, and why.
- Dependencies. The one or two that change the order.
- Not now. Briefly, so the trade-offs are clear.
- Back to the whole. End where you started, with the full picture.
For a leadership audience, that might be six or seven frames. For a team planning session, you might stay on the canvas and move around it freely.
Keep it honest
Roadmaps go wrong when they promise more than anyone knows.
- Label exploration as exploration.
- Avoid exact dates beyond the near term.
- Say plainly when something moved, and why.
- Keep every theme tied to something you’ve actually heard from users or the business.
If the roadmap will be shown outside the team, check what you’re allowed to share before it travels.
If your team works in sprints
A roadmap and a sprint board are cousins. The roadmap shows direction; the board shows this fortnight’s work.
You can keep both on the same canvas: the roadmap at the top, a small sprint area below it, linked by arrows from the Now column.
Keep the canvas alive
A roadmap is a snapshot. Review it on a steady rhythm, such as once a month or once a quarter.
Each time, move what’s done off the board, pull Next into Now, and check that the themes still hold. Keep the old version as a frame off to the side, so anyone can see how the plan changed.
For turning the themes into a single page leadership can carry around, see how to present a strategy on one page. For the planning method underneath all this, there’s how to plan a visual presentation on a canvas. CanvasDeck lets you plan the roadmap and present it from the same canvas.