Roadmap Item

Origin & evolution

The roadmap item inherited its default shape from the timeline roadmap, where each entry was a feature with a date. That shape is what made roadmaps brittle. As LogRocket describes the shift, a feature item like "add notifications" or "improve search" says nothing about why it matters, so the roadmap becomes a list of commitments disconnected from impact, and the company reads the list as a contract.

The outcome-oriented item answers a different question. It names the change to pursue, framed as "increase activation by 20%" or "reduce time-to-first-value", leaving the build unspecified and the team free to discover which feature delivers it. ProductPlan's account of outcome-driven roadmaps ties this to the diagnosis that feature roadmaps ship everything on time while the metrics🔢MetricStrategyA unified metric that measures progress, health, or behaviour across the productView reference → drift, because the items were never accountable to a result. Product Roadmaps Relaunched formalised the broader unit as the theme, an outcome-framed area of work that holds candidate features beneath it as options, none of them yet a commitment.

Mironov adds a further dimension: the same item reads differently depending on how far out it sits and who is reading it. Items in the current quarter carry roughly 90% probability of delivery, next-quarter items roughly 70%, and confidence deteriorates further the more distant the horizon — so a roadmap is not a uniform list of commitments but a probability gradient. The practical danger is that sales teams read any named feature as a contractual menu item and use its presence to make account-level promises, while product teams intend it as a current best guess subject to change. Mironov's argument, developed across his consulting and writing, is that roadmaps should communicate intent and relative prioritisation within constraints🔒ConstraintStrategyA limit, requirement, or ceiling the product must respect, whether a self-imposed principle or an externally imposed boundaryView reference →, not binding commitments, and that protecting this distinction requires explicit governance: without it, account-driven demands crowd out market-driven strategy one escalation at a time.

The field has not abandoned feature items entirely. A Now-horizon item is often a committed feature in flight, because work close to delivery is specific by necessity. In practice, feature-shaped items sit in the near horizon and outcome-shaped items further out, so that distance from delivery matches looseness of commitment.

How it works in practice

A subscription🔂SubscriptionSales & RevenueA recurring subscriptionView reference → product carries two items. The first, in Later, reads "lift trial-to-paid conversion", with a baseline of 12% and a target of 18%, and no feature attached yet. The second, in Now, reads "ship in-app upgrade prompt", a specific feature already in build.

Both are valid items, and the difference is deliberate. The Later item is accountable to a number, so when discovery surfaces three candidate features, pricing clarity, a guided trial, and the upgrade prompt, the team can compare them against the same target before committing. The Now item is a feature because it has already won that comparison and entered delivery. When a stakeholder🧑‍💼StakeholderTeam & OrganisationA person with influence over the productView reference → asks for the upgrade prompt to be promoted, the PM checks whether it serves the conversion outcome, treating the request as a candidate to weigh, not a queue position to honour. The outcome item governs; the feature item executes.

Roadmap item vs. its neighbours

• Feature: a feature is a specific capability💪CapabilityStrategyAn ability that enables value deliveryView reference → the product offers, a buildable unit with acceptance criteria. A roadmap item is a placement of a bet in time, and it may be a feature in the near horizon or may stay an outcome that several features could satisfy. One feature can sit under several items across versions of the roadmap.
• Initiative🚀InitiativeStrategyA large coordinated effort to achieve a strategic goalView reference →: an initiative is a larger strategic effort that spans multiple teams and quarters and usually contains many features. A roadmap item is a single line on the plan; a big initiative might appear as one outcome-framed item, but the initiative itself lives in strategy, not on the roadmap grid.
• Backlog entry: a backlog story is granular, estimated, and pulled into a sprint. A roadmap item is coarse and strategic, and it never carries the implementation detail a backlog story must.

In the graph

In the Unified Product Graph, a roadmap_item is a leaf in the Product & Delivery region. It belongs to its plan through roadmap_contains_roadmap_itemRoadmapcontainsRoadmap Itemhierarchy, and when it has resolved into a concrete build it points to the capability through roadmap_item_references_featureRoadmap ItemreferencesFeaturecross-domain. Keeping the item and the feature as distinct nodes joined by an edge is what lets the graph hold an outcome-framed item that has not yet chosen its feature, and lets one feature be referenced by items across successive roadmaps without duplicating it.