Roadmap Theme

Origin & evolution

The roadmap theme was popularised by C. Todd Lombardo, Bruce McCarthy, Evan Ryan, and Michael Connors in Product Roadmaps Relaunched (2017). Their argument was that feature-based roadmaps over-promise specific outputs and disconnect the work from the customer problems behind it. They proposed organising the roadmap around themes, defined as customer problems to be solved in service of the product vision🔭VisionStrategyA long-term aspirational statement of the future stateView reference →, with features demoted to possible solutions discovered later.

McCarthy's worked illustration became the standard teaching example. A customer asks for an invoice💳InvoiceSales & RevenueAn invoice for billingView reference → dashboard🎛️DashboardData & AnalyticsAn analytics dashboardView reference →, but the underlying theme is "ensure unpaid invoices get paid for accounting users," which opens the door to solutions better than the dashboard the customer happened to request. Framing the work as a problem rather than an output gives the team room to find a stronger answer and protects the roadmap from becoming a contract over specific features.

The theme sits in a wider shift toward outcome-based roadmapping, which traces to the same period and overlaps heavily with continuous-discovery practice. Theme-based and outcome-based roadmaps are close cousins; a theme tends to describe a focus area or problem, while a pure outcome attaches a target metric🔢MetricStrategyA unified metric that measures progress, health, or behaviour across the productView reference →. Most teams use them together, with themes as the readable spine and outcomes as the measurable commitment underneath.

Cagan's Inspired (2nd ed.) supplies a complementary argument for why the shift matters. His case is that teams should be given problems to solve rather than features to build, and that any candidate solution must clear four risks🎲RiskComplianceA risk to the product or businessView reference → before it earns a place on the roadmap: value (will customers buy or use it?), usability (can they figure out how to use it?), feasibility (can the team build it?), and business viability (does it work for the business?). A feature-list roadmap pre-empts that evaluation by committing to solutions before the risks are understood; a theme-based roadmap holds the problem open long enough for discovery to answer them. By that reading, the theme is not merely a presentational choice but the structural prerequisite for the kind of empowered, discovery-led product work Cagan advocates.

How it works in practice

A project-management tool plans its next two quarters. The old roadmap listed "Gantt view," "calendar sync," and "mobile notifications." The new one lists one near-term theme: "Help distributed teams know what changed while they were offline." It is deliberately solution-free.

The reframing changes what gets built. Under the old feature line, the team would have shipped mobile notifications and called it done. Under the theme, discovery surfaces that the real pain is returning after a weekend to a wall of unread updates, so the team builds a digest that summarises changes since last login, a solution that was nowhere on the original list. Stakeholders🧑‍💼StakeholderTeam & OrganisationA person with influence over the productView reference → accept the theme on the roadmap because it commits to a problem and a timeframe without locking the team into a feature that might turn out to be wrong.

Theme vs. its neighbours

• Strategic theme🧵Strategic ThemeStrategyA high-level strategic focus area for a planning periodView reference →: a strategic theme is a portfolio🧸PortfolioPortfolioA grouping of products by strategic axisView reference →-level direction the whole organisation invests behind for a year or more. A roadmap theme is a product-level customer problem grouping features for a release🚢ReleaseProduct SpecificationA shipped version of the productView reference → horizon. One lives in strategy and funds bets; the other lives in delivery and organises the build. The Unified Product Graph keeps them as separate entity types for exactly this reason.
• Feature: a feature is a specific shippable solution. A theme is the problem several features might address. The theme comes first and outlives any single feature chosen to serve it.
• Epic📜EpicProduct SpecificationA large body of work that can be broken into storiesView reference →: an epic is a large unit of buildable scope that decomposes into stories. A theme is a semantic grouping by problem, not a containment hierarchy; a theme can span work that lives in several epics and feature areas📁Feature AreaProduct SpecificationA grouping of related featuresView reference →.

In the graph

In the Unified Product Graph, roadmap_theme🎨Roadmap ThemeProduct SpecificationA customer problem used as the organising unit of a roadmap is a container in the Product & Delivery region, explicitly flagged as a semantic spanner rather than a containment parent. It reaches work through roadmap_theme_groups_featureRoadmap ThemegroupsFeaturehierarchy and roadmap_theme_spans_feature_areaRoadmap ThemespansFeature Areasemantic, and the roadmap connects via roadmap_categorised_by_roadmap_themeRoadmapcategorised byRoadmap Themehierarchy. Keeping roadmap_theme🎨Roadmap ThemeProduct SpecificationA customer problem used as the organising unit of a roadmap distinct from the strategy region's strategic_theme🧵Strategic ThemeStrategyA high-level strategic focus area for a planning periodView reference → preserves the altitude difference the two concepts demand: the roadmap theme groups delivery by customer problem, while strategic themes sit upstream allocating investment. The spanner role matters because a customer problem rarely respects the feature-area tree, and the graph lets a theme cut across it.

Not to be confused with: a strategic theme, the company-level bet on where to concentrate this horizon. A roadmap theme is the customer problem your roadmap is organised around, with features grouped beneath it.