Product Data Governance: Roles, Rulesand a Framework That Holds

Ask a catalog team who owns the "material" attribute and watch what happens. One person says the product manager, another says the supplier, a third says "whoever touched it last". Nobody is wrong, and that is exactly the problem. The value on the product page is the result of a negotiation nobody organized.

Product data governance is how a company organizes that negotiation once, so it does not happen again on every product.

What is product data governance?

Product data governance is the set of roles, rules and routines that decide who owns each piece of product information, what "good" means for it, and how a change is approved before it reaches a customer. It covers attributes, descriptions, assets, identifiers, classifications and translations, across the whole data lifecycle, from the moment a product is created to the moment it is published on a channel. It is not a tool and not a document: it is a set of decisions that people apply every day.

One clarification, because the two get mixed up. Product data governance is about the information that describes what you sell, one of the few data assets every customer actually sees. It is not about personal data, privacy, data security or GDPR, which are different disciplines with different owners. Both belong in a company's wider data governance program, but they answer different questions.

Product data governance vs product data management

Product data management is how teams manage data day to day: creating products, filling attributes, translating, attaching images, exporting to channels. Product data governance decides who does that work, by which rules, and who has the last word when two teams disagree. For the daily side, see how product catalog management works day to day.

It is like the difference between driving and the traffic code. You can drive without knowing the code, and on an empty road nothing happens. Put a few hundred drivers on the same crossroads, with suppliers, translators and marketplaces all coming from different directions, and the code is the only thing that keeps the traffic moving.

What does product data governance decide?

A governance framework that holds answers a small number of questions, written down and known by everyone who touches the catalog:

• Ownership. Who owns each attribute group (marketing content, technical specifications, regulatory data, logistics data, assets) and who can change it.
• Source of truth. Which system is the master for each attribute: ERP for the item code and logistics data, the PIM for enriched content, a DAM for images, and so on.
• Data definitions and standards. What each attribute means, its format, unit, naming convention, value list and identifier rule. What a valid value looks like, before anyone types one.
• Validation. What "ready to publish" means per channel and per locale, and who approves it.
• Change requests. How a new attribute, family or value list gets requested, assessed and added, so the data model does not grow by accident.
• Data quality metrics. What gets measured, how often, and who looks at the result.
• Traceability. Who changed which value, when and why, so a wrong value can be traced back to its source and data integrity can be checked. Data teams call it data lineage; in a PIM it is the change history.

If one of these is missing, the gap shows up somewhere else. No ownership turns validation into a debate. No change request process turns the data model into a drawer where everyone adds a column.

Why ownership comes before tools

In a content workshop at a global petcare brand, the six pain points raised were about governance, ownership and source of truth (fragmented content, seven tools, no single source for product claims), not missing features. Seven tools is another way to say data silos, each with its own version of the truth. Nobody in the room asked for a new button. They asked, in different words, the same question: who decides?

Research on master data points the same way. In a study of two master data management projects in a municipality, followed over 32 months, Vilminko-Heikkinen and Pekkola (2019) in the International Journal of Information Management report that data ownership had an impact on how the development proceeded and on how roles and responsibilities evolved. Different sector, same lesson: ownership is not an admin detail you settle after go-live, it shapes the project itself.

Product data governance roles

Titles change from one company to another, responsibilities do not. Here are the roles I find in almost every catalog that works:

Two remarks. A data owner is a business role, not an IT role: IT runs the system, it should not decide what "waterproof" means for a jacket. One person can hold several roles in a small team. In a larger company, these people form the governance team. What matters is that each role has a name next to it.

A RACI for core product data activities

Roles become real when they are attached to activities. A RACI matrix says, for each activity, who is Responsible (does the work), Accountable (has the final say, one person only), Consulted and Informed. Here is a starting point for five activities that every catalog has:

Adapt it, but keep one rule: one Accountable per row. When two people are accountable for validation, nobody is, and products wait in a queue that nobody feels responsible for.

The rules: data standards a PIM can enforce

Rules are where governance stops being a slide and becomes a field in a form. Good rules are concrete enough that a system can check them:

• Value lists instead of free text for anything a customer filters on: color, material, size, compatibility.
• Units and formats fixed per attribute: grams or kilograms, never both.
• Mandatory attributes per channel and per locale, not one global list for everything.
• Naming conventions for product titles, families and attribute codes.
• Identifier rules, such as one GTIN per sellable item, following GS1 standards.
• Data access rights per role, category and locale, so a translator can edit the Korean description but not the weight.

The identifier rule deserves its own sentence, because it is the most expensive one to fix late. In a global petcare catalog, 67% of products shared a duplicated barcode, caused by product versioning and low GS1 maturity. Fixing it meant warning distributors for about 4,000 references. An identifier is a promise to the outside world, and the cheapest moment to get it right is the first one.

The barcode clean-up with distributors is part of the petcare brand case study on PXM and Akeneo governance.

Data quality dimensions for product data

You cannot govern what you do not measure. The UK Government Data Quality Hub recommends six data quality dimensions, as defined by DAMA UK: accuracy, completeness, uniqueness, consistency, timeliness and validity (Government Data Quality Hub, 2021). They translate well to a product catalog:

• Completeness: every attribute required for a given channel and locale is filled.
• Accuracy: the value matches the real product. The weight on the page is the weight in the box.
• Consistency: the same fact has the same value across every channel and locale. "Navy" in one locale and "dark blue" in the filter of another is a consistency problem.
• Timeliness: the data is ready when it is needed, before the launch, not the week after.
• Validity: the value respects the expected format, unit and value list.
• Uniqueness: one product, one record, one identifier. No duplicates.

A warning from the field: a metric only means something if the data model is right. On a European DIY retailer's catalog built on 1,324 flat families copied from a supplier classification, completeness meant nothing and the dashboard was green or red for the wrong reasons (how that catalog was rebuilt). Fix the model, then trust the score.

How to build a product data governance framework, starting small

The frameworks that fail are often the most complete ones on paper: every category, every channel and every role on day one, then the catalog moves on and the document stays behind. Starting small works better:

1. Pick one scope. One product family or category, on one channel, ideally one where errors cost something visible.
2. List the attribute groups for that scope and write one owner next to each. One name, not a department.
3. Write the rules for those attributes: formats, value lists, mandatory fields per locale.
4. Define "ready to publish" for that channel, and who validates it.
5. Choose one or two metrics to improve data quality, such as completeness for that channel and the number of products waiting for validation, and look at them every week.
6. Open a change request process, even a simple form, before someone adds an attribute "just for this campaign".
7. Review after a few weeks, fix what did not work, then extend to the next family.

The same logic applies when AI enters the catalog: one domain, one owner, one metric, one gate, as explained in AI without data governance is noise. AI amplifies the data quality you already have, good or bad. On a European DIY retailer's catalog, 200 AI configurations and 950 rules filled 150 previously empty attributes with 80% coverage and an error rate below 5%, because prompts were forced to pick from existing attribute options and never invent values. Those value lists existed because someone had governed them first.

Benefits of product data governance

The benefits rarely show up as one big number. They show up as fewer stops: fewer products blocked because nobody knows who validates them, fewer debates about which value is right, fewer corrections after a channel rejects a feed.

• High-quality data customers can trust, because every value has an owner and a rule.
• Faster launches, because "ready to publish" is defined before the product exists.
• Fewer data silos, because each attribute has one source of truth that other systems read from.

Efficiency is not only speed. It is how often you have to stop and fix things.

Governance is a daily habit, not a document

It is like someone who buys a gym membership, frames the training plan on the wall and never goes. The plan is fine. Nothing changes. Governance works the same way: the value is in the repetition, the weekly review, the rejected product that goes back to its owner with a clear reason.

On a luxury jewelry catalog, governance meant roles, rights per locale and category, translation workflows and training for merchandising teams in the US and regional teams in South Korea. None of it was spectacular. All of it was daily. When a certificate, a stone or a carat value is wrong in luxury, the problem is not a typo, it is trust, and trust is built by people who know exactly which field is theirs.

The case study on governance for a luxury jewelry house describes how those roles and rights were set up by locale and category.

And the reason it matters is not internal comfort. Bad product data is a customer problem first: the shopper who cannot find a product with the right filter, or receives one that does not match the page, never sees your governance model. They only see its absence.

Common product data governance mistakes

• Writing governance policies nobody opens. If a rule is not in the workflow or the validation, it is a wish.
• Making IT the owner of everything. IT owns the platform. The business owns the meaning.
• Measuring completeness on a broken model. A green score on attributes nobody needs is not quality.
• Letting supplier data in without rules. Supplier data needs checks at the door, not corrections after import. See why supplier data is where PIM projects fail.

Start with one name next to one attribute

Product data governance sounds like a large program. The reality is that it starts with a very small act: writing one name next to one attribute group, and making that person's decision visible in the tool. Everything else, the RACI, the rules, the metrics, is that same act repeated with discipline.

If you want help to set it up, I work as an independent PIM consultant. We can start with a PIM audit of your catalog and ownership today, or with training for the teams who will live with the rules. You can also simply get in touch.

Sources: Vilminko-Heikkinen, R. and Pekkola, S. (2019), Changes in roles, responsibilities and ownership in organizing master data management, International Journal of Information Management, 47. Government Data Quality Hub (2021), Meet the data quality dimensions.