Product data governance: Data, Process, People, then Tooling

What is product data governance?

Product data governance is the set of decisions, rules and roles that keep product data correct, complete and fit for each channel. It defines what each attribute means, who owns it, how it changes and how its quality gets measured. The What is a PIM system pillar treats governance as the first half of any PIM decision.

A PIM is a governance discipline first and software second. Software can enforce a validation rule, route a workflow task and block an incomplete export. Software cannot decide which department owns the net weight, which classification standard to follow, or when a product counts as ready for sale.

Most PIM selections fail before the first demo, because buyers compare software before they have defined their data model. PIMvendors therefore applies governance in a fixed sequence:

1. 1DataThe model, the attributes and who owns each attribute group
2. 2ProcessHow products are created, enriched, approved and published
3. 3PeopleOwners, data stewards and the capacity to do the work
4. 4ToolingThe platform that runs the first three

1. Data: the data model, definitions, identifiers and standards.
2. Process: the lifecycle, workflows, approvals and change requests.
3. People: owners, stewards, contributors and the steering group.
4. Tooling: the PIM and the systems around it, selected last.

Each layer constrains the next. Workflows depend on the data model, roles depend on workflows, and tooling requirements depend on all three.

What belongs in the data layer?

The data layer defines what the company knows about a product and how that knowledge is structured. It produces four artefacts that later become PIM requirements.

• A data model: product families, attribute groups, attributes, data types, units and variant axes.
• An attribute dictionary: one definition, owner, source system and validation rule per attribute.
• An identifier policy: which system issues SKUs and GTINs, at which packaging level.
• A classification choice: internal category tree plus external standards such as ETIM, ECLASS or GS1.

Start with two or three representative product families, including the most complex one, because they expose the hard modelling decisions early. Variants, kits, spare parts and regulated attributes show up there first.

Regulation now adds attributes that did not exist in most data models. PPWR applies from 12 August 2026 and introduces packaging data obligations. The GPSR requires manufacturer details and warnings on online offers. Each new obligation needs an owner and a source before it needs a field.

The product data quality guide shows how the attribute dictionary turns into measurable quality rules.

How should the product data process work?

The process layer defines how a product moves from idea to retirement, and who acts at each step. A clear lifecycle prevents half-finished products from reaching channels.

A typical lifecycle has six states:

1. Created: base item received from ERP or PLM.
2. In enrichment: tasks assigned per attribute group.
3. In review: owners approve their groups.
4. Ready: completeness and validation rules pass for at least one channel.
5. Published: syndicated to channels.
6. Phased out: removed from channels, retained for service and spare parts.

Each transition needs a rule. A product moves to Ready only when the channel's completeness threshold passes. A product moves to Phased out only after the owner confirms that no open orders or service obligations remain.

Change requests need the same discipline. A new attribute, a changed definition or a new channel follows a lightweight request with an owner decision. Without that route, the data model drifts within a year of go-live.

Who should own product data?

Business roles should own product data, and the product data team should steward it. Ownership sits with the people who answer for the consequences of wrong data.

The FTE figures are PIMvendors estimates and vary with range complexity and automation. The pattern matters more than the numbers. Every attribute group has exactly one owner, and the owner has time allocated.

The selection team and RACI guide uses the same roles to staff the selection itself. The people who will own the data should help write the requirements.

How do you start product data governance in 90 days?

Start with a narrow scope, a small team and three deliverables, and expand once the first product families run under the new rules. A first version of product data governance takes 8 to 12 weeks in PIMvendors engagements (PIMvendors estimate).

A workable 90-day plan has three phases:

1. Weeks 1 to 4, scope and inventory: pick two or three representative product families, list every attribute in use and record where each one lives today.
2. Weeks 5 to 8, definitions and ownership: write the attribute dictionary for those families, name an owner per attribute group and agree the lifecycle states.
3. Weeks 9 to 12, measurement and rules: set completeness targets per channel, define the validation rules and run the first quality baseline.

Each phase ends with a steering group decision, so the scope cannot drift silently. The deliverables stay in spreadsheets and documents during this period. That keeps the effort focused on decisions instead of configuration.

The baseline from week 12 becomes the reference point for the business case. It also gives vendors something concrete to demonstrate against later in the selection.

Where does tooling fit in governance?

Tooling comes last because it should enforce decisions that already exist. A PIM selected before the first three layers forces the implementation partner to make governance decisions under project pressure.

When the first three layers are in place, tooling requirements become specific and testable:

• The data model requirement names your representative product families and their variant axes.
• The workflow requirement names your six lifecycle states and the approval rule for each.
• The permission requirement names your owner and steward roles per attribute group.

PIMvendors cross-checks those requirements against a 4-domain checklist of 400+ requirements: data model and quality, process and governance, integration and syndication, and platform and vendor. Governance work feeds the first two domains directly.

The five-level product data maturity model places governance at level 3. Companies at level 2 buy a PIM to reach level 3, and governance work decides whether they get there. Governance after go-live covers how the discipline continues once the PIM runs.