Skip to content
Unified Product GraphBeta
Get Started
Unified Product Graph

The open specification for product knowledge.
312 types. 36 domains.
MIT Licensed

Understand
The SpecBlog
Explore
Graph ExplorerEntitiesEdgesLifecyclesFrameworksPlaybooksApproaches
Adopt
MCP ServerSDKCLISkillsIntegrationsGitHub ↗
© 2026 Unified Product Graph · MIT License · Privacy · TermsBuilt by The Product Creator
‹
Reference/Product Specification/Feature Area2/12
›
📁

Feature Area

A coherent grouping of features that share an outcome, persona, or part of the product surface.

Product Specificationcoretype: 'feature_area'interface: BaseNode
View in Graph

Description

A coherent grouping of features⭐FeatureProduct SpecificationA product capability or featureView reference → that share an outcome🏆OutcomeStrategyA desired business or user outcomeView reference →, persona🎭PersonaUserAn archetype representing a user segmentView reference →, or part of the product surface.

See moreSee less

Purpose

Feature areas give product teams a unit of ownership and coherence above the feature level. In UPG, they sit at the top of the Product & Delivery stack and connect downward to features, epics📜EpicProduct SpecificationA large body of work that can be broken into storiesView reference →, and stories.

In the graph (v0.4)

In v0.4, the Product & Delivery region holds this entity. The region's internal topology is a *layered DAG (top of stack)*.

Key edges from this type: feature_area_contains_featureFeature AreacontainsFeaturehierarchy, feature_area_owned_by_team.

This entity carries Beat 6 of the Unified Product Graph manifesto: Frameworks as Views, Extensions Without Forking.

Properties

Type-specific fields on BaseNode

scope_summarystring

One-line scope description. Disambiguates from sibling areas at a glance.

owning_teamstring

Team identifier or slug. Free-form display. Canonical relationship is the `team_owns_feature_area` edge.

feature_countnumber

Approximate feature count under this area. Snapshot; `feature_area_contains_feature` edges are the source of truth.

ownerstring

Area owner (handle or email)

prioritystring

Importance to the product overall

maturitystring

Maturity. `nascent` = newly-formed grouping. `mature` = established surface. `legacy` = being phased out for a successor.

area_statusstring

Status in the product structure

Inherited from BaseNode (6 fields)
idstringrequired

Unique identifier (UUID)

typeNodeTyperequired

Discriminator for the entity type

titlestringrequired

Display name

descriptionstring

Optional detailed description

statusstring

Lifecycle status

tagsstring[]

Freeform tags for filtering

Lifecycle

3 phases — initial: planned

PlannedActiveDeprecated
All lifecycles

Relationships

9 edge types connected to this entity.

Parents

Entities that can contain this type
Productproduct_organises_into_feature_areaOrganises
Feature Areafeature_area_contains_feature_areaBelongs to

Children

Entities this type can contain
Featurefeature_area_contains_featureContains
Feature Areafeature_area_contains_feature_areaContains

Cross-References

Contextual links across the graph
Outcomeoutcome_delivered_via_feature_areaDelivered via
Themetheme_spans_feature_areaSpans
Bounded Contextbounded_context_contains_feature_areaContains
Serviceservice_powers_feature_areaPowers
Feature Requestfeature_request_in_feature_areaIn area

Graph Position

2parents
|
📁Feature Area
|
2children
|
5cross-ref

Related Entities

3 entities share semantic territory with this type.

⭐Featurecore

A distinct piece of product functionality that delivers value to users. Features are the building blocks of the product experience.

🙏Feature Requestcore

A specific capability requested by users or customers, tracked with vote count and priority.

🪀Product Areacore

A major functional area within a product. The subdivision that typically maps to a team or squad.

On this page

DescriptionPropertiesLifecycleRelationshipsGraph PositionRelated Entities

Usage Guidance

Use feature areas to scope team ownership and roadmap🛣️RoadmapProduct SpecificationA strategic plan of features and milestonesView reference → coherence. Keep them coarse enough that the team can be accountable for the whole area, fine enough that the surface is identifiable.

Think of it as...

Like a neighbourhood on a city map — features⭐FeatureProduct SpecificationA product capability or featureView reference → within a feature area share context, ownership, and a sense of belonging.

Anti-Patterns

Creating one feature area per feature⭐FeatureProduct SpecificationA product capability or featureView reference → (defeats the grouping). Drawing feature-area lines along team org-chart fault lines rather than user-facing coherence. Letting feature areas become permanent silos.

Examples

Collaboration area

Groups commenting, mentions, sharing, and presence into one feature area, so roadmap🛣️RoadmapProduct SpecificationA strategic plan of features and milestonesView reference → and ownership decisions⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference → can be made about collaboration as a whole rather than feature⭐FeatureProduct SpecificationA product capability or featureView reference → by feature.

Billing & subscriptions area

Collects the plan picker, invoicing, payment methods, and dunning flows under a single area owned by one team, making dependencies⛓️DependencyTeam & OrganisationA cross-team or system dependencyView reference → and gaps visible at a glance.

Related Reading

•
The UPG Manifestoby Faheem Hasan
•
Beat Frameworks as Views, Extensions Without Forking: extension-without-fragmentation-upg-architecture