Product data governance: who owns what

Product data governance is the set of owners, rules and routines that keep product data complete, correct and current. In practice every attribute has a named owner, every product passes agreed checks before it goes live, and someone reviews quality on a fixed rhythm. Without it, a new PIM decays within a year of go-live.

We see this pattern again and again. Our centre of excellence in Hyderabad has delivered over 50 PIM projects, and the software is rarely the reason a catalogue falls apart. The reason is that nobody agreed who owns what, so nobody fixes anything.

What is product data governance?

Product data governance is data governance applied to one domain: the products you sell. DAMA International describes data governance as the discipline that “establishes accountability, policies, and decision rights to ensure data is managed properly“. That holds for product data. If you want the wider discipline first, our glossary entry on what data governance is covers it.

Product information governance differs from enterprise data governance in three ways. Enterprise programmes usually sit with a central data office and focus on customer, finance and risk data. Product data is different:

• Much of it comes from outside. Suppliers create most of the technical facts, in their own formats.
• It changes every week. New lines, range reviews, discontinued products and supplier updates never stop.
• Customers judge it in public. A missing voltage on a product page is a lost sale today, not an audit finding next year.

So product data governance has to be operational. It lives with buying and ecommerce teams, inside their daily work, not in a policy document. It covers four things:

• Attributes: the facts that describe each product, from dimensions to material.
• Content: titles, descriptions, feature bullets and channel copy.
• Assets: images, drawings, datasheets, certificates and video.
• The model itself: the taxonomy, attribute definitions, value lists and the rules for changing them.

The model is the one most teams forget. If anyone can add an attribute, you end up with “Width”, “Width (mm)”, “W” and “Overall width” holding the same fact in four places.

Who owns product data?

Nobody owns “the product data”. Ownership works at attribute level, because different facts come from different people. The buyer knows the range role and the pack quantity. The manufacturer knows the dimensions. The ecommerce team knows what converts on the product page. Compliance knows what must appear by law. Ask one team to own all of it and you get a bottleneck, or a team signing off data it cannot check.

Ownership by attribute

This is the product data ownership grid we start with on most projects. Adjust the detail to your catalogue, but keep the shape.

Attribute group	Examples	Usual owner	Source
Commercial attributes	Brand, range role, lifecycle status, pack quantity, selling unit	Buying or category team	Buying decisions and ERP.
Technical facts	Dimensions, weight, material, voltage, power rating	Supplier, checked by the category team	Supplier files and datasheets.
Channel content	Titles, descriptions, feature bullets, search keywords, image order	Ecommerce team	Written or enriched in-house.
Regulated fields	Hazard information, safety data sheets, certification marks, country of origin	Compliance or technical team	Supplier evidence, checked internally.
Classification and model	Category, attribute definitions, value lists	Product data lead	The data model.

Two rules make the grid work. First, one owner per attribute, not per product. Second, the owner is a role, not a person, so it survives holidays and leavers. Record the owner inside the definition of each of your product attributes, next to its data type and unit. Then nobody has to ask.

The product data lead

Someone has to hold the whole picture. That is the product data lead. The role owns the data model and the standards, runs the change process, chairs the quality review and settles disputes between teams. It is the business owner of the PIM, not its system administrator.

Where it sits matters. We have seen it work inside ecommerce and inside the trading function, close to the buyers. It struggles in IT. IT can enforce a rule, but it cannot judge whether a product description is right. In a business with 5,000 SKUs this is part of one person’s job. With 50,000 SKUs from hundreds of suppliers, it is a small team.

The lead does not have to do the keying. Product data stewardship, the daily work of onboarding supplier files, enriching and fixing errors, can run through a managed product data operations team. The decisions stay with the lead.

What suppliers are responsible for

Suppliers own the facts about their products. Put their duties in the supplier agreement or onboarding pack, not in an email thread. They should:

• Send technical attributes in your template, using your units and your value lists.
• Provide evidence: datasheets, certificates and safety documents.
• Tell you when a product changes or is discontinued, before it happens.
• Correct errors at source when you flag them.

Suppliers do not own your taxonomy, your channel copy or your commercial attributes. Do not ask them to classify products into your category tree. They will pick the nearest category, and it will often be wrong.

What rules does product data governance need?

Owners need rules to apply. Keep them short, written and specific. Five types cover most catalogues:

• Data standards. Each attribute has a definition, a data type, a format and an owner. “Width: overall external width, number, millimetres” is a standard. “Width” is not.
• Value lists. Any attribute with a finite set of answers, such as material or finish, gets a controlled list. Free text here is how filters break.
• Units. One unit per attribute per market. Let the system convert, not the person keying.
• Completeness by channel. Define what “ready” means for each category on each channel. Your website, a marketplace and a trade catalogue will need different attributes.
• Approval workflow. Decide who checks what before a product goes live. Enrichment, technical check, commercial sign-off, publish. Keep the steps few, or people will route round them.

Each rule should map to one of the dimensions of product data quality, such as completeness, accuracy or consistency. If a rule does not protect a dimension you care about, drop it.

What routines keep it working?

Rules decay without routines. Three keep governance alive.

Quality measures on a fixed rhythm. Review a short set of numbers every month with the attribute owners in the room. Completeness by channel, error rate, time to live for new products and the number of products blocked in workflow. Each owner sees the numbers for their own attributes. The checks behind these numbers belong in your product data quality assurance process, so the review is about trends and causes, not counting.

Supplier scorecards. Score each major supplier every quarter. How complete was the first submission? How many errors needed rework? How long did they take to fix them? Share the scorecard with the buying team. Data quality then becomes part of the commercial conversation, which is where suppliers listen.

Change control for the data model. New attributes, new categories and value list changes go through a short request. Who needs it, for which channel, who will own it and what it replaces. The product data lead approves and batches changes. Monthly is usually enough. Without this, the model grows a new attribute every time someone has a question.

How does a PIM enforce governance?

PIM governance is where your decisions become automatic. A good PIM gives you four tools:

• Roles and permissions: who can edit which attribute groups.
• Workflows: the approval steps a product passes through before it is published.
• Validation rules: formats, ranges, mandatory fields and value lists checked on entry.
• Completeness scores: how ready each product is for each channel.

The PIM enforces decisions. It cannot make them. Permissions need to know who owns what. A completeness score needs someone to have decided what complete means. We regularly see PIMs configured on assumptions because the business had not decided, and the settings rarely match how the teams actually work.

So settle the ownership grid and the rules before configuration starts. Then your PIM implementation configures agreed decisions instead of guesses, and go-live is the start of governance rather than the end of the project.

Signs product data governance has failed

Failed governance looks the same in almost every catalogue we review.

The PIM is half empty six months after go-live. Completeness stalls at whatever the migration loaded. New products go live with the minimum, because nobody owns the gaps.

Spreadsheets are back. The buying team keeps its own range file. Ecommerce keeps another for marketplace feeds. The PIM becomes one more copy instead of the master.

The same fix is made twice. Someone corrects a product title on the website or a marketplace. The next sync from the PIM overwrites it. The error was fixed downstream, not at source, because nobody knew who owned the source.

The reset is not a new system. Name a product data lead, build the ownership grid for your top categories, and start the monthly review. Most catalogues recover faster than teams expect once someone owns each gap.

Frequently asked questions