Product Offering vs Specification
Last updated 14 Oct 2026
At a glance
A catalog describes every product twice. The Product Offering is what you sell: name, price, channel and eligibility. The Product Specification is what it is: its characteristics and how it is realised. Keeping them apart lets the commercial side move quickly without touching the technical definition.
The picture
Product Offering vs Product Specification — many offerings can reference one specification
SuperFibre 100 Home
Product Offering
SuperFibre 200 Home
Product Offering
Business Fibre 200
Product Offering
Fixed Broadband Access
Product Specification
CFS: Internet Access
Customer Facing Service
CFS: WiFi Management
Customer Facing Service
How it works
Two representations of one product
Every product in a catalog-driven architecture has two representations. The same underlying product can be sold in several ways (different names, prices, channels), and every one of those offerings points to the same specification underneath.
Many offerings, one specification
The relationship is many-to-one: several offerings reference the same specification. Product managers can launch a new offering with no technical change, and a change to the specification reaches every offering that references it.
Where the price lives
In TMF620 the price hangs off the offering as a ProductOfferingPrice, never off the specification. That is what lets one specification carry a different price in each offering it appears in.
Bundles
A bundled Product Offering groups other offerings, such as "Home Triple Play" (internet, TV and voice). Each component keeps its own specification. Components can be mandatory, optional, or part of a choice group (pick one of N).
Offering and specification side by side
| Product Offering | Product Specification | |
|---|---|---|
| Answers | What is sold, to whom, through which channel, at what price | What is delivered and how it is realised |
| Carries | Name, ProductOfferingPrice, channel, eligibility, validity dates | Characteristics, composition rules, link to CFS specifications |
| Typical owner | Product management / marketing | Product or service architecture |
| Change rate | Weeks | Quarters or longer |
| Read by | Channels, CPQ, COM (at order capture) | Order decomposition (product to CFS) |
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Product Offering | Product Catalog | CPQ / digital channels | COM | Versioned. An order references the offering version it was sold under. |
| Product Specification | Product Catalog | — | COM | Linked to CFS specifications held in the service catalog. |
| Product Offering Price | Product Catalog | CPQ | Billing | Billing usually holds its own copy for rating, which is a common source of drift. |
| Product (the customer’s instance) | Product Inventory | CRM / self-care | — | TMF637. Records both the offering and the specification it was created from. |
In practice
Catalogs built inside CRM or CPQ tools often merge the two: one "product" record carries price, eligibility and technical attributes together. That works until a second brand or channel needs the same product sold differently. The product is then copied, and the copies drift apart.
TMF620-conformant catalogs model both entities. What separates estates in practice is whether the specification is actually linked to CFS specifications in the service catalog. Without that link the separation exists on paper, and order decomposition still depends on hard-coded mappings from product codes.
The trade-off
What it solves
Product teams can launch, reprice or rebrand an offering without a technical change, and one technical definition can serve many brands, channels and segments.
What it does not solve
- Poorly modelled specifications. If every offering gets its own specification, the split exists but reuse never happens.
- Price drift between the catalog and billing, which usually hold separate copies.
- Legacy products that were never modelled this way.
What it adds
- Two entities to version, with rules on which offering versions may reference which specification versions.
- Governance: someone must own the specifications and refuse near-duplicates.
- Orders and installed base that still reference retired offering versions.
Architecture decision
Should a new product variant be a new offering or a new specification?
New offering, same specification
Choose when only commercial terms differ: price, name, channel, eligibility or contract term.
New specification
Choose when what is delivered differs: a characteristic, a CFS, or how the network realises it.
Breaks if technical differences are hidden in offerings ("Fibre 200 Business" quietly needs a static IP). Decomposition then has to read offering names, and every new offering becomes a technical change.
Takeaways
Key Takeaways
- Product Offering = commercial wrapper (name, price, channel)
- Product Specification = structural definition (characteristics, CFS linkage)
- Many offerings can reference one specification, which is where reuse comes from
- Price sits on the offering (ProductOfferingPrice), so specifications stay stable
Check yourself
Marketing wants a student version of Fibre 200 at a lower price, sold online only. New offering or new specification?Show answerHide
A new offering that references the existing specification. Price, channel and eligibility are all offering attributes; nothing about what is delivered changes.
Where does price live in TMF620, and why there?Show answerHide
On the Product Offering, as ProductOfferingPrice. Price is a commercial decision that varies by offering. Putting it on the specification would make every price change a technical change.
A catalog has 400 offerings and 390 specifications. What does that tell you?Show answerHide
The separation is nominal. Nearly every offering has its own specification, so reuse is not happening, and specifications are probably carrying commercial differences.