Skip to content

Roadmap & Delivery

A roadmap that connects up to strategy and down to the work

Most roadmaps are a list of features detached at both ends: nothing ties a feature up to the strategy that justifies it, and nothing ties it down to the work that delivers it. So prioritisation turns into politics and scope turns into a guess. UPG types the whole span, from the need a feature addresses and the key result it drives, through epics, stories, tasks, and the cross-team dependencies between them, up to the release that ships and the roadmap theme that realises a strategic bet. Both ends of the roadmap resolve to an answer the graph already holds.

01Feature Traceability

What connects a feature back to the strategy

A featurefeatureA product capability or feature carries edges in both directions. It addresses a needneedA user need, pain, desire, or constraint and a jobjobJob To Be Done: what the user is trying to accomplish, it drives a key resultkey_resultA measurable result tied to an objective, and it tests a hypothesishypothesisA testable belief about a solution. Those are typed links back into discovery and strategy, so the roadmap connects to the why behind each feature, not only the what.

That makes prioritisation legible. A feature with a clear need and a key result behind it sorts to the top; a feature with neither shows up as a candidate to cut. RICE, MoSCoW, and Now-Next-Later read as lenses over these links rather than another list to keep in sync.

Verified metrics dashboardanchor
featurefeatureA product capability or feature
addressesfeature_addresses_need
Users distrust in-product numbers
needneedA user need, pain, desire, or constraint
addressesfeature_addresses_job
Decide without exporting to a spreadsheet
jobjobJob To Be Done: what the user is trying to accomplish
drivesfeature_drives_key_result
70% of weekly-active teams open a dashboard
key_resultkey_resultA measurable result tied to an objective
testsfeature_tests_hypothesis
Verified numbers raise dashboard trust
hypothesishypothesisA testable belief about a solution

Prioritisation becomes a property of the graph. A feature points back to the need it addresses and the key result it drives, so a feature with neither stands out as a candidate to cut. RICE, MoSCoW, and Now-Next-Later are lenses over exactly these links, not separate spreadsheets.

02The Breakdown

How a feature decomposes into shippable work

A featurefeatureA product capability or feature is decomposed into an epicepicA large body of work that can be broken into stories, an epic is specified by user storyuser_storyA structured story statement capturing a user's goal and the value they expect to receive, in the "As a… I want… So that…" format. nodes, and the feature also decomposes into the tasktaskA unit of work within a story or epic nodes an engineer picks up. Each level is a typed node, not a heading in a doc.

So scope is a traversal. The question of what a release contains walks epic to story to task; the question of what is left on an epic counts its open tasks. The breakdown lives in one place instead of being re-entered in a tracker that drifts from the spec.

Verified metrics dashboardanchor
featurefeatureA product capability or feature
decomposed intofeature_decomposed_into_epic
Dashboard framework
epicepicA large body of work that can be broken into stories
specified byepic_specified_by_user_story
As an admin, I see verified metrics so I trust the report
+ acceptance_criterion
user_storyuser_storyA structured story statement capturing a user's goal and the value they expect to receive, in the "As a… I want… So that…" format.
decomposes intofeature_decomposes_into_task
Build the verification badge component
tasktaskA unit of work within a story or epic

A feature breaks down to the smallest unit an engineer can pick up, every level a typed node. Scope is a traversal, not a guess: ask what a release contains and the graph walks epic to story to task, with acceptance criteria attached where the work is defined.

03Stories & Acceptance

How the graph records when a story is done

The user storyuser_storyA structured story statement capturing a user's goal and the value they expect to receive, in the "As a… I want… So that…" format. is the unit of agreement. An epicepicA large body of work that can be broken into stories is specified by the stories that make it concrete, and each story is verified by the acceptance criterionacceptance_criterionA condition that must be met for a story to be done nodes that say when it is done.

So “is this finished?” resolves to a checklist the graph already holds rather than a debate in review. The acceptance criteria written when the story was shaped are the same ones QA checks against, because they are the same nodes.

Dashboard frameworkanchor
epicepicA large body of work that can be broken into stories
specified byepic_specified_by_user_story
As an admin, I see verified metrics
user_storyuser_storyA structured story statement capturing a user's goal and the value they expect to receive, in the "As a… I want… So that…" format.
As an admin, I can trace a number
user_storyuser_storyA structured story statement capturing a user's goal and the value they expect to receive, in the "As a… I want… So that…" format.
One story, made unambiguous by its acceptance:
verified byuser_story_verified_by_acceptance_criterion
Badge shows on every verified metric
acceptance_criterionacceptance_criterionA condition that must be met for a story to be done
verified byuser_story_verified_by_acceptance_criterion
Tooltip names the source and time
acceptance_criterionacceptance_criterionA condition that must be met for a story to be done

An epic is specified by the user stories that make it concrete, and each story is verified by the acceptance criteria that record when it is done. The definition of done is held on the graph as a list of acceptance criteria attached to the story.

04Tasks & Dependencies

How a cross-team blocker is typed on the graph

Work decomposes to the smallest pickup-able unit: a tasktaskA unit of work within a story or epic implements a user storyuser_storyA structured story statement capturing a user's goal and the value they expect to receive, in the "As a… I want… So that…" format. and has subtasks. The thing that holds it up is itself typed: a dependencydependencyA cross-team or system dependency depends on one teamteamA cross-functional team and blocks another.

So a cross-team blocker is a node with edges, visible the moment it is created. Asking what is blocked, and on which team, is a traversal rather than a round of the status meeting.

Build the verification badgeanchor
tasktaskA unit of work within a story or epic
implementstask_implements_user_story
As an admin, I see verified metrics
user_storyuser_storyA structured story statement capturing a user's goal and the value they expect to receive, in the "As a… I want… So that…" format.
has subtasktask_has_subtask
Wire the reporting API
tasktaskA unit of work within a story or epic
And the blocker is typed, not buried in a thread:
Reporting API v2
dependencydependencyA cross-team or system dependency
depends ondependency_depends_on_team
Platform
teamteamA cross-functional team
blocksdependency_blocks_team
Growth
teamteamA cross-functional team

Work decomposes to the task an engineer picks up: a task implements a story and has subtasks. A dependency between teams is itself a typed node: it depends on one team and blocks another. The cross-team blocker is recorded on the graph as a node and its two edges.

05Releases & Milestones

How a release records what shipped and the milestone it served

A milestonemilestoneA key date or achievement marks a moment of strategic significance and triggers the releasereleaseA shipped version of the product that meets it. The release contains the featurefeatureA product capability or feature nodes that ship together and is documented in a changelogchangelogA record of changes shipped in a release the team and customers read from the same source.

So the changelog is generated from what the release actually contains rather than written from memory at the end of the sprint. What shipped, and the milestone it served, are both one traversal away.

First 1000 teams
milestonemilestoneA key date or achievement
triggersmilestone_triggers_release
v3.0 Trusted Reportinganchor
releasereleaseA shipped version of the product
A release is what it contains, and what it tells the world:
containsrelease_contains_feature
Verified metrics dashboard
featurefeatureA product capability or feature
containsrelease_contains_feature
Provenance drawer
featurefeatureA product capability or feature
documented inrelease_documented_in_changelog
v3.0 release notes
changelogchangelogA record of changes shipped in a release

A milestone marks a moment of strategic significance and triggers the release that meets it. The release contains the features that ship together and is documented in a changelog. The features in a release and the milestone it meets are both reachable by traversing from the release node.

06Roadmap Themes

How a roadmap theme realises a strategic theme

A strategic themestrategic_themeA high-level strategic focus area for a planning period is realised by a roadmap themeroadmap_themeA customer problem used as the organising unit of a roadmap, which groups the featurefeatureA product capability or feature nodes that deliver it and spans the feature areafeature_areaA grouping of related features they live in. This is the edge most planning tools leave implicit.

So the roadmap is the strategy projected onto the work. Every theme on the roadmap names the strategic theme it serves, and every feature under it inherits that line of sight all the way up to the vision.

Trust the numbers
strategic_themestrategic_themeA high-level strategic focus area for a planning period
realised bystrategic_theme_realised_by_roadmap_theme
Reporting the team can trustanchor
roadmap_themeroadmap_themeA customer problem used as the organising unit of a roadmap
The roadmap theme gathers the work that delivers the strategy:
groupsroadmap_theme_groups_feature
Verified metrics dashboard
featurefeatureA product capability or feature
groupsroadmap_theme_groups_feature
Provenance drawer
featurefeatureA product capability or feature
spansroadmap_theme_spans_feature_area
Reporting
feature_areafeature_areaA grouping of related features

A roadmap theme connects strategy to shipped work. A strategic theme is realised by a roadmap theme, which groups the features that deliver it and spans the feature area they live in. The roadmap is a projection of the graph along these edges, not a separate list to maintain.

07Where To Go Next

Delivery sits between the strategy that justifies it and the engineering that ships it. Follow a thread in either direction: