Skip to main content
Roadmap connects two different models:
  • Demand: the product problems customers experience, represented by Insights and recurring Themes
  • Delivery: the work a product team may plan or ship, represented by Features and Initiatives
Keeping demand separate from delivery helps teams validate the problem before committing to a solution.
The current app calls recurring product-problem clusters Themes. Some older URLs and MCP tool names still use Opportunities for the same general concept.

​
The Roadmap objects

Connections between these objects show whether customer demand is already represented in planned work. The Product map’s feature-level demand and the Features view’s delivery work are different models. One organizes discovered demand; the other represents work the team may deliver.

​
Start with the problem, not the requests

Several requested solutions can be symptoms of one incorrect product assumption. For example, customers might separately ask for mobile submission, different onboarding, bulk import, and new reporting. Looking only at requests creates four roadmap items. Investigating the evidence may reveal one underlying workflow: a single administrator completes the whole process in a monthly batch. The stronger Roadmap decision starts from that workflow problem. The requested features remain evidence, but they do not define the solution.

​
Covered and uncovered Themes

The Themes view distinguishes between:
  • Uncovered: no Roadmap work addresses the Theme’s evidence
  • Covered: at least half of the Theme’s product insights match a Feature synced from your product management source, a Feature was created from the Theme, or a team member linked the Theme to an Initiative
Coverage is recomputed by the weekly Roadmap pipeline from the insights themselves, not from how similar a Theme sounds to a project name, so a change on your Roadmap can take up to a week to show as coverage. A covered Theme shows the Initiative it is linked to when one exists; an uncovered Theme may show its closest Initiative as context, which is not coverage.

​
Correct coverage by hand

Open a Theme and use the Coverage actions to override the automatic result:
  • Not covered: the Theme reads as uncovered, whatever the automatic check finds
  • Covered by…: choose the Initiative that addresses the Theme
  • Reset to automatic: return the decision to the automatic check
A manual choice is marked set manually and the weekly pipeline does not overwrite it. The automatic check keeps running underneath, so resetting shows its current result. If two Themes are later merged into one, only the surviving Theme’s choice is kept. Coverage answers whether the Roadmap addresses the demand. It does not prove that the planned work solves the problem.

​
RIC informs priority

RIC combines Reach, Impact, and Confidence to rank items within their respective views. Compare Themes with other Themes and Features with other Features; do not treat scores across those levels as directly comparable. RIC does not include engineering effort, strategic fit, technical risk, sequencing, or opportunity cost. The product team must add those judgments.

​
What each Roadmap view is for

Features and Initiatives depend on a connected product management source or workspace feature availability. Themes remain useful without either.

​
Where the decision happens

ClosedLoop AI can show the problem, evidence, affected customers, relative priority, and existing Roadmap coverage. People still decide whether to build, experiment, defer, reject, or investigate further.