Roadmap

The roadmap plans work that matters beyond a single todo. Roadmap items are usually Initiatives or Ongoing Work.

Replacing Aha!, Productboard, or another roadmap tool? Move projects, epics, and product bets into initiatives first. Using Linear, Jira, or another issue tracker? Keep issues there and use initiatives to explain the product, customer, or goal context those issues support.

What belongs on the roadmap

Put work on the roadmap when it should stay visible beyond today: features, projects, epics, customer-impacting work, and cross-team efforts.

Defects and incidents belong in Bugs. Small personal follow-ups belong in Todos.

Plan initiative work

Roadmap initiatives can be nested under parent initiatives, grouped by owner or taxonomy, filtered by team or taxonomy, and assigned to people. Hierarchy keeps child work visible under one parent when an initiative is large.

For spec-driven development, the roadmap initiative carries the intent behind the implementation. Keep the initiative brief current before work moves into delivery.

Add Taxonomy where it improves planning or reporting; skip it for small items that do not need it.

Use the Related, Journal, and Changes tabs below the brief to inspect initiative hierarchy, completed work, and linked code activity. Tab details and breadcrumb behavior are covered in Initiatives.

Review priority

Open Priorities when the team needs to explain what matters next. Open Stack Ranking when initiatives need an explicit, filterable order for review.

When work starts moving, use Roadmap Progress to see whether completed work is supporting the intended initiatives.