Plans vs Roadmap

Two terms that confuse new users: Plan and Roadmap. They're different tools for different jobs.

Roadmap

The strategic view. Which initiatives you're shipping when, across all products.

• Audience: CEO, board, stakeholders, sales, customer success
• Question it answers: "What are we shipping this quarter?"
• Granularity: initiative-level (high-level)
• Date precision: weeks-to-months
• Update cadence: weekly status updates

Plan

The execution view. How you'll actually deliver one initiative.

• Audience: engineering manager, designers, the team building it
• Question it answers: "How do we get this shipped?"
• Granularity: task-level (detailed)
• Date precision: days-to-weeks
• Update cadence: daily/sprint-level

When to use each

Scenario	Use
"We're committing to launch v2 in Q3"	Roadmap (initiative)
"Here's how we'll launch v2" (30 tasks, dependencies, owners)	Plan
Showing the roadmap at a board meeting	Roadmap
Running standups with the engineering team	Plan
Answering "is this slipping?" in 5 seconds	Roadmap
Coordinating cross-functional dependencies	Plan

Linked together

Most teams link a plan to its parent initiative on the roadmap:

Roadmap initiative: "Launch mobile app v2"
   ↓
   linked to
   ↓
Plan: "Mobile app v2 launch"
   ↓
   contains
   ↓
35 tasks across 5 phases (Spec, Design, Build, QA, GTM)

Status updates flow up: a plan slipping bumps the linked initiative's status to At Risk.

Don't conflate

Common mistake: treating the roadmap as a project plan with 100 tasks. The roadmap becomes unreadable, stakeholders stop opening it, you lose the strategic view. Common mistake: treating a plan as the roadmap. The CEO opens the plan and sees 47 tasks across 12 phases — they wanted the high-level "what's shipping when" view, not the engineering breakdown.

Keep them separate. The two views are different artifacts for different audiences.

Next steps

• Creating a Plan
• Plan templates
• Linking plans to initiatives