← Back to Resources
nutrād · Product Data Orchestration

No One Owns Keeping Product Data in Sync

Product data changes constantly. The problem is not that people enter the wrong values. It is that one record gets updated while the other copies keep saying what they said yesterday.

Published: September 29, 2026Product Data OrchestrationProduct Data QualityChange Management
Product, operations, and engineering professionals comparing product data across a specification sheet, laptop, and tablet

Pick a product you sell. Any one of them.

Now count the places where it is described. There is the cut sheet or PDF a customer downloads. There is the product page on your website and the item record in your ERP. There is the listing on your distributor's portal, plus another on each marketplace where you sell. If you work in a specification channel, there may be a CAD file or Revit family sitting in an engineer's model. You may still have a printed catalog. And somewhere there is probably a spreadsheet maintained by someone in inside sales that is more current than several of the others.

Every one of those copies may have been correct on the day it was published.

Then something changes. A supplier revises a case pack. Engineering corrects a dimension. A certification is renewed. One system gets updated, while the others keep saying what they said yesterday.

Here is a test that takes about ten minutes. Open three of those records and compare one attribute: a dimension, pack quantity, net weight, or certification number. Do not choose the description. Choose one number or code that should be identical everywhere.

I would be curious how often that comes back clean.

How Product Information Drifts

Nothing went wrong, which is the part that makes this hard to see.

The cut sheet was updated when engineering revised the part. The website was updated during the quarterly content refresh. The distributor feed changed when the distributor requested a new file. The item master was corrected when purchasing needed the right pack quantity for a purchase order. And the CAD file? That one is less clear, and it may be three years old.

Each update was reasonable. Each was made by someone who understood the document they owned and followed a cycle that made sense for it. But every update also left the other copies a little further behind.

That is not bad data in the way people usually mean it. Nobody entered the wrong value. The records drifted because different people maintained them at different times, for different reasons. That is exactly what the organization asked them to do.

The Gap in the Org Chart

Product management owns the specification. Marketing owns the website. Channel operations owns the distributor feed. Engineering owns the drawing. Purchasing owns the item master. Each one has a named owner, a budget line, and somebody whose performance review mentions it.

Agreement between them has none of those things. It is not in anyone's job description or on anyone's dashboard. There is no regular meeting where it comes up, because the meeting would need to span several departments and there is no obvious person to call it.

So the answer to "Who is responsible for keeping our product information consistent?" is usually some version of everyone is, a bit. In practice, that means nobody.

The people involved are already careful about what they own. The problem sits between the things they own, and that space does not have a headcount.

This is why "be more careful" has never fixed the problem and never will. You cannot assign carefulness to the gap between departments.

What It Costs in One Example

A supplier changes a case pack from 6 to 8. It is a routine change, communicated properly in an email that somebody reads.

Purchasing updates the item master because purchasing feels the change first. The purchase orders were wrong, and now they are right.

But a downstream shipping or EDI configuration still has the old case quantity. Six weeks later, a retailer issues a chargeback because the ASN pallet configuration does not match what arrived on the dock.

At the moment of shipment, nobody made a mistake. The failure happened earlier, when the change reached the item master and stopped. No one owned carrying it through every other record and configuration that depended on the same value.

The chargeback is the first alert that the records stopped agreeing. That is a strange way to find out. It is also expensive and completely normal.

A Golden Record Does Not Stay Current by Itself

There is a familiar name for what companies are trying to build: the golden record. It is one clean, complete, authoritative version of each product that downstream systems and channels can trust.

A PIM or MDM system can create and govern that record. But the record remains authoritative only if the files, portals, drawings, listings, and transaction configurations around it stay connected to the same change process.

Publishing a correct record is not the finish line. Product data keeps moving after publication. The real question is whether the next change reaches every place that depends on it.

Staying current is a different job. It requires a way to detect a change, identify the documents and destinations affected by it, carry the update through, and verify that it arrived. Most companies have pieces of that process. Few have one owner or workflow that spans all of it.

Where I Would Start

I would not start with software. I would start with the ten-minute test at the beginning of this article. Pick one product and one attribute, then check it across three records.

If they agree, try a product you launched three years ago.

Then ask the harder question.

Whose job is it, at your company, to notice when two of those records stop agreeing?

Someone, or some process, has to notice the change, trace where that value is used, and confirm that every affected destination received it.

If you have a real answer to that question, I would like to hear it. I suspect most companies do not, and I do not think that reflects badly on anyone. It simply is not a job most organizations thought to create.

See Where Your Product Records Have Drifted

A nutrād Product Data Audit checks a sample of your product records for inconsistencies, missing attributes, and channel-readiness gaps so you can see where routine changes have stopped.

Request a Product Data Audit