2.112 min read

Product Offering vs Specification

Two Sides of Every Product

In TM Forum catalog modeling, a product has two fundamental representations: the Product Offering (what you sell) and the Product Specification (what it is). This distinction is one of the most misunderstood concepts in telco, yet it is absolutely fundamental to catalog-driven architecture.

The separation exists because the same underlying product can be sold in multiple ways: different names, prices, bundles, markets, and channels — all pointing to the same technical specification underneath.

Product Offering vs Product Specification -- many offerings can reference one specification

Figure 2.1 — Product Offering vs Product Specification relationship model

Product Offering

Product Offering (PO)

A Product Offering represents a sellable entity as presented to a specific market or channel. It includes pricing, terms, eligibility rules, promotions, and bundling. The PO is what appears in the online shop, what the sales agent quotes, and what the customer orders. TM Forum: TMF620 Product Catalog Management API.

Product Offerings are commercial constructs. They can be created, modified, and retired by product managers without changing the underlying technical definition. A Product Offering always references one or more Product Specifications.

Product Offering Attributes

Attribute	Description	Example
Name	Commercial name shown to customers	"SuperFibre 200 Home"
Description	Marketing description	"Lightning-fast 200Mbps broadband for the whole family"
Validity Period	When this offering is available for sale	2024-01-01 to 2025-12-31
Channel	Which sales channels can sell this	Online, Retail, Telesales
Market Segment	Target customer segment	Residential, Mass Market
Pricing	Price plans attached to this offering	$89/month recurring + $49 one-time setup
Bundled Items	Other offerings included in a bundle	Includes: Router rental, WiFi app

Product Specification

Product Specification (PS)

A Product Specification defines the structure, characteristics, and service linkage of a product type. It describes what the product IS — its configurable attributes, its relationship to services (CFS), and its composition rules. The PS is technology-facing and relatively stable compared to offerings.

Product Specifications are structural definitions. They change less frequently than offerings and define the shape of a product: what characteristics it has (speed, quota, features), what services underpin it, and what constraints apply.

Product Specification Attributes

Attribute	Description	Example
Name	Technical/internal name	"Fixed Broadband Access"
Characteristics	Configurable parameters	downloadSpeed, uploadSpeed, dataQuota, technology
Service Linkage	Which CFS specifications this product requires	CFS:Internet-Access, CFS:WiFi-Management
Composition Rules	Mandatory, optional, and mutually exclusive components	Router is mandatory; Static IP is optional
Lifecycle State	Design-time lifecycle	Draft → Active → Deprecated → Retired

How They Relate

The relationship between Offering and Specification is many-to-one (typically) or many-to-many (in complex scenarios). Multiple offerings can reference the same specification, and a single offering can reference multiple specifications (in a bundle).

Example: Same Specification, Multiple Offerings

Product Specification "Fixed Broadband Access" defines a broadband product with configurable speed characteristics. From this single spec, product managers create multiple offerings: "SuperFibre 100 Home" ($69/month, 100Mbps), "SuperFibre 200 Home" ($89/month, 200Mbps), "SuperFibre 200 Business" ($129/month, 200Mbps with SLA), "Back to School Broadband" ($59/month promotional, 100Mbps, 12-month contract). All four offerings use the same specification — only the commercial attributes (price, name, eligibility, contract terms) differ.

Separating Offering from Specification enables independent lifecycle management:

Product managers can create new offerings without technical changes
Pricing changes don't affect service design
Promotional offers can be launched and retired quickly
The same technical product can serve multiple market segments
Specification changes (e.g., adding a new characteristic) automatically apply to all offerings that reference it

Bundle Offerings

A Bundle Product Offering is a special type of offering that groups multiple offerings together. The bundle itself may reference a bundle specification, and each component offering references its own specification. This enables complex packages like "Home Triple Play" (Internet + TV + Voice) where each component has its own technical specification.

Intermediate

Product Offering Hierarchy

Offerings can be structured hierarchically: a parent bundle offering contains child component offerings. Each component can be mandatory, optional, or part of a choice group (pick 1 of N). This hierarchy is what CPQ systems navigate to build valid quotes.

In TMF620, this is modeled through BundledProductOffering relationships. The bundle PO has bundledProductOffering entries, each with minQuantity and maxQuantity. A minQuantity of 1 makes the component mandatory. A group of components with a shared bundleGroupId and maxQuantity of 1 creates a choice group. This structure drives the entire CPQ validation engine.

TMF620 Product Catalog Management

TMF620 is the TM Forum Open API for Product Catalog. It defines the REST API for managing Product Offerings, Product Specifications, and their relationships. Key resources: /productOffering, /productSpecification, /catalog, /category. The API supports full CRUD plus complex querying for eligible offerings.

Source-of-Record Ownership

A critical question in catalog modeling is: who owns what? Product Offerings and Product Specifications are managed by different roles, through different processes, with different change velocities. Getting ownership wrong leads to governance failures — commercial teams changing technical structures, or engineering teams blocking product launches.

Catalog Entity Ownership

Entity	System of Record	System of Engagement	System of Reference	Notes
Product Offering	Product Catalog (BSS)	CPQ, Online Shop, Retail POS	Billing, Order Management, CRM	Owned by Product Management. Changes driven by commercial decisions (pricing, promotions, market entry). High change velocity — weekly or monthly.
Product Specification	Product Catalog (BSS)	Catalog Management Tool	SOM, Service Catalog, Billing	Owned by Product Architecture / Solution Design. Changes require impact analysis across all referencing offerings and linked CFS. Lower change velocity — quarterly or less.
CFS Specification	Service Catalog (OSS)	Service Design Tool	SOM, ROM, Service Inventory	Owned by Service Architecture. Defines technology-neutral service structure. Changes require coordination with both Product Catalog (above) and Resource Catalog (below).
RFS Specification	Service Catalog (OSS)	Service Design Tool	ROM, Resource Inventory, Activation	Owned by Network / Platform Architecture. Technology-specific. Changes may require network element configuration updates.
Resource Specification	Resource Catalog (OSS)	Resource Design Tool, Network Planning	ROM, Resource Inventory, Capacity Planning	Owned by Network Engineering. Defines physical/logical resource types, attributes, and allocation rules.

Lifecycle Governance

Both Product Offerings and Product Specifications follow a design-time lifecycle that governs when they can be used, modified, or retired. Understanding this lifecycle — and the constraints it imposes — is essential for catalog governance.

Design-Time Lifecycle: Offering vs Specification

State	Product Offering	Product Specification
Draft	Being configured. Not visible to channels. Pricing, eligibility, and bundling rules are being defined.	Being designed. Characteristics, CFS linkages, and composition rules are being defined. Not yet available for offering creation.
Active	Available for sale through configured channels. Can be ordered. Pricing is live.	Available for reference by offerings. CFS decomposition rules are active. Can be used by fulfilment systems.
Deprecated	No longer available for new sales, but existing subscriptions continue. Renewals may or may not be permitted.	No new offerings should reference this spec. Existing offerings and active subscriptions continue to reference it.
Retired	Fully withdrawn. No new orders, no renewals. Existing subscriptions must be migrated or terminated.	No offerings reference it. All instances have been migrated to a successor specification or terminated.

The Version Skew Problem

A common governance failure: Specification v2 is activated while Offering A still references Specification v1. If v2 is a breaking change (removed characteristic, changed CFS linkage), Offering A silently breaks. Governance must enforce: (1) Non-breaking spec changes increment the minor version — existing offerings continue to work. (2) Breaking spec changes create a new major version — existing offerings must be explicitly updated and retested. (3) Active product instances are immutable against their creation-time spec version — they do not auto-upgrade.

Key Takeaways

Product Offering = what you sell (commercial: name, price, channel, eligibility)
Product Specification = what it is (structural: characteristics, CFS linkage, composition)
Multiple offerings can reference the same specification (reuse and flexibility)
Separating them enables independent lifecycle management for commercial vs technical
Bundles are offerings that group other offerings, enabling complex packages
TMF620 standardizes the catalog API for both offerings and specifications
Product Offerings are owned by Product Management (high change velocity); Product Specifications are owned by Product Architecture (low change velocity)
Both follow a Draft → Active → Deprecated → Retired lifecycle that must be governed independently
Specification version changes must be classified as breaking or non-breaking — breaking changes require explicit offering updates