The roadmap has exactly three stages. They're deliberately coarse — the goal is what your customers see, not granular project tracking. Use Linear for the latter.
The three stages
Planned
You've committed to building this. It's queued, scoped, and somewhere on the team's radar.
What customers see: "We're going to build this."
When to use it:
- A feedback theme has accumulated enough votes / customer weight to merit action.
- A leadership-driven priority lands and you want it visible.
- A specific Linear issue has been triaged into a near-term cycle.
In Progress
Active engineering work. Someone is writing code, designing, or running a beta.
What customers see: "We're working on this right now."
When to use it:
- Work has actually started.
- A Linear issue is in In Progress (if you have two-way sync, this happens automatically).
Shipped
Released to customers. Public.
What customers see: "This is live, you can use it now."
When to use it:
- The feature or fix is in production.
- You're ready to notify the customers who voted for the linked feedback.
Important: Dragging to Shipped fires customer notification emails. See Shipping and customer notifications.
What's not on the roadmap
- Triage / Backlog. These live in your feedback list, not on the roadmap.
- Cancelled. When you decide not to build something, mark the linked feedback as Cancelled in the feedback list. The roadmap card itself can be deleted.
Target windows (optional)
A roadmap item can have an optional target window — a quarter, a month, or a custom date range. This is metadata. It shows on the public roadmap as "expected by Q3" or similar.
We deliberately don't make this required. If you don't know when, don't promise.
Mapping to Linear
If you have bi-directional Linear sync (Pro+), Conclude maps roadmap stages to Linear states:
| Conclude | Linear |
|---|---|
| Planned | Todo / Backlog (configurable) |
| In Progress | In Progress |
| Shipped | Done / Released |
The mapping respects your Linear workflow — you don't have to rename your states.