Why Product Data Problems Keep Returning After Governance Initiatives

May 29, 2026

Product data governance framework alongside recurring product data issues including taxonomy drift, missing attributes, invalid values, and manual corrections.
Product data governance and recurring data quality issues across commerce and product information systems.

If you have ever pulled a product readiness report ten days before a major launch and discovered the data is not where it needs to be, you would find this blog insightful.

Forty percent of SKUs with attribute gaps. Three new product subcategories created during the past quarter are classified differently across the PIM, the ERP, and the commerce system. The digital team is using one taxonomy value while the merchandising team is using another, and neither matches what two of the retailers require in their submission templates.

The next ten days get spent correcting this manually. A spreadsheet appears. Teams work through it in parallel, overwriting each other's corrections without realising it. The launch happens, probably on time, with most of the data close enough to pass.

And somewhere in the back of most people's minds is the same quiet thought: we already fixed this.

Most organisations that experience this pattern have run a governance initiative at some point. They aligned on taxonomy, defined ownership, and built the framework. The work was real.

This pattern tends to repeat because of a structural gap between what governance initiatives are designed to deliver and what sustained product data quality actually requires. Understanding that gap, and where it shows up most in day-to-day operations, is what we have highlighted ahead.

Why Product Data Problems Persist After Governance Initiatives End

A governance initiative has a defined lifecycle. A working group forms, workshops run, a framework gets produced, and leadership signs off. The project closes. 

The operational environment the framework was meant to govern keeps running. 

New products enter the catalogue, retailer requirements shift, and channels expand. Suppliers send data in formats that sit outside the agreed taxonomy. Someone in the regional team creates a product classification that fits the submission deadline better than the approved option does. These situations arise constantly, in every commerce organisation, at a pace the governance project never accounted for. 

This is not an unusual outcome. Gartner projects that 80% of data and analytics governance initiatives will fail by 2027. The explanations that come up most often, including executive sponsorship, change management, and organisational silos, point at real contributing factors, though they tend to describe what happens rather than why it keeps happening. 

Governance initiatives produce outputs: 

  • A taxonomy framework 
  • A data ownership model 
  • Quality standards 
  • A stewardship structure 

These outputs are produced in a project environment, during a defined period, with stakeholders engaged specifically for that purpose. When the project ends, the outputs exist. The operational environment continues on its own terms. 

The Gap Between What a Governance Initiative Delivers and What It Changes Operationally

What Governance Initiatives Typically Produce 

A governance initiative produces tangible, valuable outputs: 

  • A taxonomy document with agreed classifications 
  • An ownership matrix with named stewards and defined scope 
  • A data dictionary establishing shared definitions 
  • Quality thresholds for completeness and accuracy 
  • A process for escalating and resolving data conflicts 

Getting to these outputs requires genuine work. The conversations involved, about ownership, classification standards, and quality definitions, are difficult to have in most organisations. The initiative produced something meaningful. 

The harder question is whether any of it changed how product data gets created and maintained once the project team dispersed. 

Why Operational Workflows Continue Unchanged After Governance Projects 

Here is what tends to happen in practice: 

  • The product manager creating a new record in the PIM selects a category based on what looks right, working from memory or habit 
  • Supplier data arriving through the portal moves into the system before anyone checks it against the quality thresholds 
  • The merchandising team building a seasonal catalogue creates new attribute values for a promotional range without a stewardship review 

None of this reflects carelessness. People operate at the speed the commercial calendar demands. A governance document sitting in a shared folder, rather than embedded in the system as a validation rule, a required field, or a workflow step, becomes something teams consult in a crisis rather than something shaping daily decisions. 

The framework was delivered and the workflows continued as before. That distance between the two is where product data problems find room to grow back. 

Why Taxonomy Drift Keeps Returning After Data Governance Cleanup

When taxonomy drift reappears after a governance initiative, the instinct is often to treat it as a compliance failure. The standard was set. Teams moved away from it.

Drift builds through individually rational decisions made under operational pressure:

  • A product manager receives a new range from a supplier that sits outside the existing category structure. They find the closest fit or create something workable for the submission.
  • A regional team faces a retailer requiring a classification their internal taxonomy does not support. They build a local solution that gets the feed accepted.
  • A campaign goes live using attribute tags the approved taxonomy was too broad to accommodate. Someone creates what the promotion requires.

In each situation, the person made a reasonable call given what the governance standard had not anticipated.

Over time, these decisions layer on top of each other. The taxonomy develops inconsistencies that look systematic on audit, though they arrived one reasonable decision at a time.

The governance framework captured the data environment as it existed during the project. The business kept generating complexity the model never anticipated. Drift is the natural result of that distance.

Why Governance Initiatives Are Designed to End When Data Quality Problems Are Not

Research from Harvard Business Review and Bain, published in 2024, found that only 12% of large-scale transformation programmes produce lasting results. That figure has remained flat for two decades. The organisations that do sustain meaningful change share a common practice: they treat the change as continuous and embedded into how the organisation operates, rather than as a programme with a defined scope and completion date. For product data governance, that distinction matters considerably. An initiative that produces a framework and closes is structurally different from a discipline that operates continuously alongside the business.

Governance initiatives are almost universally designed as projects. There is a budget, a timeline, a set of deliverables, and a point at which success gets declared. Success is measured against delivery of the output, rather than against whether that output influenced operational behaviour six months later.

This pattern shows up consistently at scale. In McKinsey's research on operating model transformations, leaders describe programmes that became "marginalised into something that has barely affected how the company operates." The programmes hit their milestones. The operational reality they were meant to address stayed largely the same.

For product data governance, the challenge goes a layer deeper. Data quality requires continuous maintenance against real operational conditions:

  • New products added to the catalogue without complete enrichment 
  • New channels with attribute requirements the existing data does not meet 
  • Supplier data arriving in inconsistent formats 
  • Team members making data decisions without full awareness of the governance standards 

A framework addresses the data as it existed when the project ran. Most organisations invest in building the framework and expect the results that only an ongoing operational discipline can sustain.

What Organisations With Sustained Product Data Quality Do Differently

Organisations where product data governance holds over time tend to share one observable characteristic. It is less about the sophistication of the framework they designed and more about where that framework sits relative to daily operational decisions.

In practice, embedded governance tends to look like:

  • The taxonomy is a controlled vocabulary field in the PIM. Product managers select from approved classifications rather than entering free text, so the standard applies without requiring active recall of a document.
  • The attribute standard lives as a validation rule. Records with incomplete fields get flagged before activation, so quality issues surface at the point of creation rather than at the point of submission.
  • Data ownership is a workflow step. Before a record in a given category goes live, a review is triggered automatically, making stewardship part of the process rather than an optional escalation.

When governance is built into the system this way, operational behaviour shifts because the system shifts. A product manager joining six months after the initiative closed follows the governance standard without knowing it came from an initiative. The fields the system requires do the work.

Embedding the framework into the operational environment is the work that follows the initiative, and it rarely receives the same investment because by the time it matters most, the initiative has already closed.

The Question to Ask Before Launching Another Product Data Governance Initiative

Before scoping the next governance programme, one question is worth sitting with. 

If the framework produced by the last governance initiative were removed tomorrow, the documents archived and the stewardship roles dissolved, would the operational behaviour of your product, commerce, and data teams change in any meaningful way? 

If the answer is yes:

  • The governance has become embedded in how the work gets done
  • The taxonomy holds because the system enforces it
  • Ownership has real operational weight because the workflow requires it

If the answer is no:

  • The governance lives primarily in documentation
  • Operational decisions are being shaped by deadline pressure and team habits more than by the standards the initiative established
  • The next launch will likely surface the same gaps as the last

Organisations running governance programmes periodically and rediscovering the same taxonomy drift and enrichment gaps and ownership confusion each time are usually already aware of this, at least in private. The initiative was executed well. The governance held for a period. Then the operational environment kept moving and the framework stayed where it was.

The organisations that make progress are usually the ones that stopped treating governance as a separate initiative and started building the actual standards into how product data gets created, reviewed, and updated every day.

If the patterns feel familiar, the starting point is usually not another governance initiative. It is understanding where the existing framework stops influencing day-to-day decisions and where operational teams have been forced to work around it.

That is the gap ThoughtSpark helps enterprise data and commerce teams identify and address: the distance between governance as it was designed and governance as it actually operates.