Roadmap template
A roadmap answers three questions: what are we building, in what order, and why that order. Ask your agent to draft it and share a link — stakeholder comments land on the exact initiative, not scattered across Slack threads.
The hardest part of a roadmap isn't the structure — it's getting everyone reacting to the same version. Most roadmaps die in a PowerPoint deck that gets emailed around, spawns a chain of "can you update slide 4?" replies, and becomes outdated before anyone acts on it.
Draft it with your agent
Paste this into Claude, Cursor, or any agent — it drafts the roadmap and publishes it as a Drafty link:
See it on a real one
What goes in a roadmap template
- Vision — one sentence: what success looks like in 12–18 months. Not a feature list, a direction.
- Goals — three to five measurable outcomes for the next planning horizon. If a goal doesn't have a metric attached, it's a wish.
- Initiatives — the themes of work that move the goals. Group by outcome, not by engineering team or sprint. This is where most roadmaps go wrong: they list features when they should list the problem each cluster solves.
- Timeframe — Now / Next / Later is usually better than a calendar for early-stage products; quarters work when you have a release cadence. Avoid specific dates unless you have real commitment behind them — a roadmap date becomes a promise the moment it's read by a stakeholder.
- Open questions — the named unknowns that could shift priorities. Leaving these off doesn't make them go away; it just means they surface as surprises.
The section most roadmaps leave out
Most templates stop at features and timelines. The useful addition is a short "not doing" list — initiatives that came up and were deliberately parked. It saves the meeting where someone asks "but what about X?" when X was already considered and deprioritized for a reason.
When to share it
A roadmap is a communication tool, not a planning artifact. Draft it in private, but publish it the moment it's good enough to react to — not when it's perfect. Waiting for it to be final means the first feedback arrives after decisions are locked.
Share the Drafty link with engineering and design for inline comments on specific initiatives. Share a version with leadership or customers that focuses on goals and themes, not dates. The comments anchor to the exact item — "what does 'improve onboarding' mean here?" lands on that line, not floating in an email.
FAQ
What's the difference between a roadmap and a project plan?
A project plan is a delivery schedule — tasks, deadlines, dependencies, owners. A roadmap is a direction statement — goals, themes, and rough timing. You might have a project plan for every initiative on the roadmap, but the roadmap itself stays at the "why and roughly when" level. When someone asks for a roadmap and gets a Gantt chart, they usually needed a roadmap.
How far out should a roadmap look?
Six to eighteen months is the standard guidance. For an early-stage product, Now / Next / Later (roughly this quarter / next two quarters / later) works better than specific dates — it communicates priority without implying false precision. For a mature product with regular releases, quarterly is more useful.
What's the difference between a product roadmap and a project roadmap?
A product roadmap covers the ongoing evolution of a product — features, themes, and user outcomes over multiple cycles. A project roadmap covers a bounded piece of work — phases, milestones, and deliverables with an end date. Same format; different lifespan. A product roadmap is never "done." A project roadmap is done when the project ships.
Should a roadmap include specific dates?
Only if there's a real commitment behind them — a launch event, a contract, a regulatory deadline. Otherwise, dates on a roadmap become promises the moment a stakeholder reads them, and you'll spend more time managing date expectations than doing the work. Quarters or phases communicate timing without locking you in.
How do I share a roadmap with stakeholders who want more detail?
Build a shared base — vision, goals, themes, rough timing — and layer detail on request. Leadership usually wants goals and outcomes; engineering wants initiative breakdown and dependencies; customers want to know what's coming without caring why one thing comes before another. One Drafty link with inline comments lets each person react to what's relevant to them without needing separate versions.
How often should I update the roadmap?
After each planning cycle (quarterly is common) and whenever a major priority shifts. The bigger mistake is leaving a stale roadmap up — nothing erodes trust faster than stakeholders discovering the roadmap doesn't reflect current priorities. When something significant shifts, update the link, don't send a new file.