Customer master data is a list. Supplier master data is a list. Product master data is a tree.
That structural difference is why product master projects stall where supplier and customer projects ship. The governance patterns carry over. The data model does not. Until the schema handles attribute variance across categories, no amount of workflow or stewardship saves a product master from collapsing into the same flat table the ERP already has.
The attribute explosion problem
A customer record has the same shape whether the customer is a hospital, a retailer, or a freelance consultant. Legal name, tax ID, billing address, payment terms, contact details, a handful of classification flags. Forty fields in a thorough model. Every customer slots into the same schema.
A supplier record has the same shape. Same logic.
Products do not work like that. An office chair has a color, a weight, a material, a dimension profile. A laptop has a CPU, memory, storage, screen size, battery life, operating system, and twenty other attributes a chair does not need. An industrial valve has a body material, a pressure rating, a temperature range, a flow coefficient, a connection thread, and certifications none of the above care about. A bolt has a thread pitch, a grade, a surface treatment, and an application class.
You can force them all into one flat entity with 200 columns. Plenty of organizations did exactly that in MDS. Most of those columns are NULL for any given row. When a category adds a new attribute, every row acquires another NULL column. The schema becomes hostile to both stewards and downstream integrations, search returns mostly noise, and every report has to explain which fields are meaningful for which subset of rows.
What MDS made hard
MDS modeled attributes as properties of a single entity. You could build “Product” as an entity and attach attributes, but those attributes lived on the entity, not on a category within it. Category-specific attributes forced a workaround: one entity per category. Chairs in one entity, laptops in another, valves in a third. Each with its own subscriber views, its own permissions, its own hierarchy, its own audit noise.
That is how organizations ended up with seventy-entity MDS models and no way to query across them. A report asking “show me every product active this quarter, across all categories” had to be rebuilt every time a category was added. The hierarchy handling in MDS made the problem worse, not better.
The design the industry eventually settled on is category-scoped attribute groups. Common attributes live on a shared base: identifier, classification, lifecycle status, core descriptions. Category-specific attributes live on the category, not duplicated onto every child row. The attribute set a row can carry is determined by the category it belongs to. The schema adapts without a migration every time the catalog grows a new branch.
The unique key question — it is not SKU
The SKU is what your ERP calls a product. It is not a master data key. SKUs are operational and negotiable. Different business units use different SKUs for the same physical item. Acquisitions import overlapping SKU ranges that have to be reconciled. A SKU discontinued in 2019 can get reassigned in 2024 to something unrelated, and the ERP is fine with that because the ERP was never responsible for historical integrity.
The stable identifiers are external:
GTIN (Global Trade Item Number, formerly UPC/EAN) for consumer goods. Externally assigned, globally unique, recognized across retail channels.
Manufacturer part number paired with the manufacturer's identifier, for industrial and B2B products. Unique within a manufacturer and stable over the product's life.
System-generated GUID at record creation, for internal configurations and engineered-to-order items where no external identifier exists. Immutable.
The rule is the rule that already applies to every other master data domain: assign the key once, never change it. Every product record created without a stable identifier is a future reconciliation project that gets more expensive every month.
The category hierarchy problem
Product categories are hierarchical. “Office chairs” is a subset of “Seating” which sits under “Office furniture” which sits under “Furniture.” Attributes inherit down the tree: anything that applies to all furniture applies to all office chairs.
Getting the hierarchy wrong is the most common failure mode I see in product MDM. Two patterns break projects:
The hierarchy gets built by marketing for site navigation rather than by operations for data structure. Marketing taxonomies optimize for how customers shop. Operational taxonomies optimize for how attributes cluster. They are not the same, and trying to use one for both leaves everyone unhappy.
The hierarchy evolves without governance. Categories get added ad hoc when new product lines arrive. Attributes get duplicated across branches because nobody reconciled. A year in, the taxonomy is an archaeological record rather than a working tree.
The workable pattern is one operational category hierarchy owned by product data governance, with a separate display hierarchy maintained downstream if the business needs one. The operational hierarchy is stable. The display hierarchy can change every season. They reference the same records but serve different jobs.
The PIM question
If you are publishing product content across multiple sales channels, you probably need a PIM. PIMs handle what marketing owns: images, videos, translations, marketing copy, channel-specific overrides.
Product MDM handles the operational core: the identifier, the classification, the core attributes ERP, warehouse, analytics, and compliance need to agree on. The boundary between the two is not always clean, and the PIM vs MDM distinction is worth reading if you are trying to decide which of the two you need. The short version is that most mid-market organizations only need one, and it is usually the MDM.
The failure mode is running both systems without picking which one is authoritative for each attribute. When the PIM and the MDM both claim to be the source of truth for the same field, one of them has to yield, and the yielding has to be documented. Treating that boundary as an explicit design decision rather than letting it emerge is the difference between a working product master and a turf war.
Pitfalls that keep showing up
| Design choice | What actually happens |
|---|---|
| Flat entity with every possible attribute | Hundreds of NULL columns. Search and reporting become guesswork. |
| One entity per category, no shared base | Cross-category queries impossible. Permissions duplicated endlessly. |
| ERP SKU as the master key | Acquisitions and SKU reuse break the identifier over time. |
| Marketing taxonomy used as the data model | Operational attributes fight with display categories. Both suffer. |
A practical first scope
Full product MDM is a multi-year engagement. A useful first phase is measured in weeks when scoped right.
The pattern that works: pick one category or product family where downstream pain is loudest. Set up the master for that scope. Get the unique key discipline working. Model the category-specific attributes. Identify and train the governance owner. Ship the integration to one downstream system. Then expand.
The three places this fails:
Trying to model the entire catalog in phase one. Nobody in the organization has a complete picture of the attribute variance across every category, so the model that ships will be wrong in places nobody noticed. Scope to what is known.
Deferring the unique key decision because it is contentious. If the key question is not settled before the tool goes live, the tool will not settle it for you. A governance platform enforces decisions; it does not make them.
Treating the project as a migration rather than a governance rollout. Lifting the current SKU table into an MDM tool does not produce a product master. It produces the same mess with a nicer UI. Governance has to be in place before the data moves.
Read the first-domain picking post if you are still deciding whether products should be first. The honest answer: products are the right first domain when attribute variance is already causing cross-system pain. They are a bad first domain when the real pain is duplicate customers or supplier reconciliation, because product MDM is heavier on schema work than either of those.
The domain most organizations underestimate
Product master data is the hardest of the three core domains because the schema has to absorb variance that customer and supplier schemas never encounter. Most organizations that force product data into a flat entity learn the same lesson, usually about eighteen months in, and the fix at that point is expensive.
A product master that ships is one that starts with the attribute model, settles the key question, and picks a first scope narrow enough to finish. Everything else follows from those three decisions.
Common questions
What is the best unique key for product master data?
For consumer goods, the GTIN (UPC/EAN) is the strongest choice — externally assigned, globally unique, and recognized across retail channels. For industrial or B2B products, a manufacturer part number paired with a manufacturer identifier is usually the right answer. When no external identifier exists, assign a system-generated GUID at first record creation and treat it as immutable. The ERP SKU is not a master key — SKUs are operational and negotiable. Mergers and acquisitions overlap them, business units reuse them, and a discontinued SKU can be reassigned two years later to something unrelated.
What is the difference between product MDM and a PIM?
A PIM manages rich product content for multi-channel publishing: marketing descriptions, images, videos, translations, channel-specific overrides. Product MDM manages the operational master record — the identifier, the classification, the core attributes every downstream system needs to agree on. A PIM is optimized for content workflows. An MDM is optimized for governed reference data. Most mid-market organizations running a single commerce channel only need one of the two, and it is usually the MDM.
How do you handle category-specific attributes in a product data model?
The working pattern is category-scoped attributes. Common attributes live on a shared base. Attributes that only apply within a category live on the category, not duplicated onto every child row. When a row is created, the attribute set available is determined by the category it belongs to. Flat entity schemas with every possible attribute as a nullable column produce unworkable models beyond a few dozen categories and make search and reporting almost useless.
Should product MDM and customer MDM share the same platform?
Yes, if the platform supports multi-domain management. The entity structures are different — product is hierarchical with category-scoped attributes, customer is flatter with a fixed schema — but the governance patterns are the same. Running separate tools for product and customer master data recreates the same integration problems at the tool layer that you are trying to solve at the data layer.
One platform for every domain — including products
Primentra supports multi-domain master data management on SQL Server. Configure separate entity structures, validation rules, and approval workflows for products, customers, and suppliers — in one place, no consulting engagement required. The 60-day trial includes everything.