Month: June 2026

What would you do if your data quality score improved by twelve points over two quarters and your retailer rejection rate did not change at all?

Most data and commerce leaders have been in that room, where the dashboard looks healthy, the governance programme is showing results, and leadership is satisfied, while somewhere in the background the commerce team is still building the same correction spreadsheet they built last quarter and the quarter before that, before the same seasonal submission deadline.

The score improved while the operation kept running exactly as it had before.

That is a measurement gap, and it tends to be one of the most expensive gaps in a commerce operation because it creates confidence in a situation that deserves scrutiny.

Most organisations tracking product data quality invested in measurement for the right reasons, including visibility, accountability, and a way to demonstrate that governance work was producing results.

The metrics most organisations use measure the condition of data inside their systems against internal standards, and they rarely extend to whether that data performs reliably in the operational environment it was actually created for.

That distinction is where the false sense of progress lives, and understanding where that gap comes from and why it tends to grow quietly over time is what this blog covers.

Why Data Quality Scores Improve While Operational Problems Persist

A completeness score measures whether a field has a value, leaving aside whether that value is correct for the channel the product is being submitted to.

An accuracy score measures whether data matches an internal reference, leaving aside whether that reference reflects what a specific retailer, marketplace, or syndication partner actually requires.

A data quality dashboard aggregates scores across thousands of records and surfaces a number representing average performance against internally defined thresholds, and it rarely surfaces the forty SKUs that will fail tomorrow’s submission because their taxonomy classification does not match what a specific channel accepts.

The score goes up while the operational problem continues, because the score is measuring something real, just not what determines whether the data performs when it reaches the channel.

The Data Quality Disconnect: reported scores rising while operational performance declines 

That gap has a financial consequence that most organisations have never attributed to their measurement framework. Forrester’s research found that more than one quarter of global data and analytics professionals estimate their organisations lose over $5 million annually due to poor data quality, with 7% estimating losses of $25 million or more. These are organisations with measurement frameworks in place. The measurement is not preventing the loss because what is being measured and what is actually going wrong are two different things.

“More than one quarter of global data and analytics professionals estimate their organisations lose over $5 million annually due to poor data quality. These are organisations with measurement frameworks already in place.”

— Forrester Research

The Three Measurement Gaps That Create False Progress

What the metric measures vs. what determines performance

Gap 1: Internal Standards vs Channel Requirements

Most product data quality frameworks define standards based on what the internal system requires, so a record is considered complete if the mandatory fields in the PIM are populated and accurate if it matches the master data reference.

The operational environment is not the internal system. It is the retailer portal, the marketplace listing, the syndication feed, and the customer-facing product page, each of which has its own requirements that can change without notice, are often more granular than the internal standard, and sometimes require attribute combinations that the internal completeness check never evaluates.

A product record that scores 100% complete internally can still fail a retailer submission because a required channel-specific attribute was never part of the internal completeness definition.

Gap 2: Populated Fields vs Usable Values

Completeness metrics count whether a field has a value, and they rarely evaluate whether that value is usable for the purpose the field serves.

A product description field containing “TBD” is technically complete, and so is a category field populated with a legacy classification that no current retailer accepts, and so is a weight field containing a value in the wrong unit for the destination channel.

In each case the completeness score counts the field as populated, even when the value it contains is not fit for the purpose the field was created to serve, which is why the score can show improvement while the correction sprint still runs before every submission.

Gap 3: Snapshot Quality vs Continuous Quality

Data quality scores are typically calculated at a point in time, whether that is a weekly report, a monthly dashboard, or a quarterly review presentation, and product data does not stay static between those measurement points. 

New products are added, existing records are updated by different teams following different working assumptions, and supplier data arrives in formats that pass the ingestion check and then drift from the taxonomy standard over time, which means a record that scored well on last month’s report may have been modified three times since then by three different people. 

The score reflects the state of the data at the point of measurement, which is rarely the same as the state of the data at the point of execution, and that gap is where feed rejections tend to originate.

Why Organisations Keep Measuring the Wrong Things

Understanding why this measurement gap persists is more useful than simply identifying that it exists.

The metrics most organisations use were designed to be measurable rather than comprehensive, because completeness is straightforward to calculate, accuracy against an internal reference is easy to automate, and a dashboard that aggregates those scores and shows a trend over time is something leadership can understand and act on.

The metrics that would actually reflect operational performance are harder to build and harder to present, because feed acceptance rates by retailer, attribute compliance rates by channel, and the percentage of products submittable to a given marketplace without manual intervention all require connecting internal data quality measurement to external operational outcomes, a connection that is technically harder to build and tends to surface numbers that look worse than the completeness score, which makes it harder to present to leadership that has been receiving an improving trend for two years.

So organisations measure what is easy, the easy measurement shows improvement, the operational teams continue running correction sprints, and the gap between the two realities widens quietly.

Most product data quality measurement programmes were defined when the governance initiative was established and have not been revisited since, so the metrics report on a data environment that has continued evolving while the framework has not evolved with it. MIT Sloan Management Review research on KPI governance confirms this as a documented organisational pattern, finding that it takes effective governance to ensure KPIs evolve, remain aligned with strategic aspirations, and are trusted by workers and managers alike, and that the organisations that sustain effective measurement treat their frameworks as living systems rather than infrastructure decisions made once and reported against indefinitely.

“Effective measurement is a living system. Most product data quality programmes were defined once, when the governance initiative launched, and have not been revisited since.” 

— Adapted from MIT Sloan Management Review, Governance for Smarter KPIs 

What the Dashboard Does Not Show

What sits beneath a healthy reported score

When a data quality dashboard shows a score of 87% and an upward trend, it is telling a specific story about a specific set of measurements, and what it is not showing is equally important to understand. 

It is not showing the product manager who reviewed forty records manually before last week’s submission because the completeness check passed and the channel compliance check did not exist, and it is not showing the retailer relationship strained for two quarters by recurring feed rejections that the internal quality score never registered as a problem.

It is not showing the new product introduction that took three weeks longer than planned because the enrichment required for the primary launch channel was not part of the standard quality threshold and was only discovered during the final submission review, and it is not showing the AI initiative underperforming because the product data it works with scores well on internal completeness and carries taxonomy inconsistencies that the measurement framework never caught.

A score of 87% with an upward trend is real information and incomplete information simultaneously, and incomplete information about data quality is particularly costly because it creates confidence where scrutiny would be more useful.

How the False Sense of Progress Compounds Over Time

The measurement gap would be a manageable problem if it stayed contained, and it tends not to. 

An organisation that believes its data quality is improving will underinvest in the root cause work that would actually improve operational performance, because the dashboard justifies the current investment level while the correction cycles continuing beneath it get treated as operational friction rather than as evidence that the measurement framework is missing something important.

How the gap compounds: score improves, investment shifts elsewhere, correction cycles continue, the gap widens 

Leadership makes decisions based on the reported progress, resources get allocated elsewhere, the governance programme is considered mature, and the focus moves to the next initiative, while the operational teams are still correcting data before every campaign, the retailer rejection rate has not improved, and the data foundation that every subsequent initiative will be built on is not as strong as the dashboard suggests. 

By the time the gap becomes undeniable, usually at a moment of significant operational failure, the distance between the reported progress and the operational reality is much larger than it would have been if the measurement gap had been identified and addressed earlier. 

What Measurement Actually Needs to Capture

The shift required is straightforward to describe, though genuinely difficult to execute because it asks organisations to accept that their current measurement may be telling them less than they think.

Effective product data quality measurement connects internal standards to external operational outcomes, measuring whether the data in those fields enables the business to execute without manual intervention at the point of execution.

In practice that looks like:

• Feed acceptance rates tracked by retailer and channel rather than internal completeness scores tracked in aggregate
• Attribute compliance rates measured against each channel’s actual requirements rather than against a single internal standard
• New product introduction cycle time tracked from record creation to first successful channel submission 
• Manual correction volume tracked per campaign and per submission window rather than absorbed into general operational activity
• The percentage of active SKUs submittable to the primary channel without any manual intervention, measured regularly rather than at a governance review point

These take more effort to build than completeness scores, and they reflect the operational reality that internal scores often obscure, and they give leadership a measurement framework that actually connects to what the commerce team experiences before every deadline.

The Connection to the Broader Pattern 

This series has traced a consistent pattern across five blogs, and the measurement gap is the final layer of it. 

The replatforming investment moved the data without fixing its foundation, the governance initiative produced a framework without changing operational behaviour, the ownership assignment created accountability on paper without enforcing it in the system, and the workaround cost accumulated invisibly while the operation declared itself functional. 

Now the metrics measuring progress are creating confidence in a situation where the underlying problems have not been resolved, just reported around, and the data quality score is the last place this pattern hides because once an organisation believes its data quality is improving it stops looking for evidence that it is not. 

The Question Worth Asking About Your Current Measurement 

Before presenting the next data quality dashboard to leadership, one question is worth sitting with.

If every data quality metric your organisation currently tracks showed a perfect score tomorrow, would your commerce and product data teams be able to launch a major campaign, onboard a new retailer, and expand to a new channel without any manual correction work?

If the answer is no, the metrics are measuring something other than what determines operational performance, and they measure something real and useful in its own way, just not the thing that will tell you whether the product data foundation is actually working.

That gap between what the score says and what the operation requires sits at the strategic level, because every investment decision made on the basis of an improving score that does not reflect operational reality is a decision made on incomplete information.

The conversation worth having starts with understanding what the current dashboards are not showing, and that is the gap ThoughtSpark helps enterprise data and commerce teams identify and address: the distance between data quality as it is measured and data quality as it actually performs in the operational environment.

The week before a major seasonal campaign, someone on the commerce team pulls the product readiness report. 

Of the 3,400 SKUs going live across seven retail channels, around a third need manual attribute corrections before the feeds can go out. Some are missing required fields for specific retailers. Some have taxonomy values that do not match the channel’s accepted classifications. Some were created by the supplier data team using a template that has not been updated to reflect the current channel specifications. A handful have conflicting values across the PIM, the ERP, and the commerce system, and nobody is certain which version is correct. 

The team knows what happens next. Someone builds a spreadsheet. Responsibilities get divided. People work through it over the following three days, alongside everything else they were supposed to be doing that week. The feeds go out on time. The campaign launches. Leadership sees the launch date met and the channel coverage achieved. 

What leadership does not see is the invoice. 

Not a literal invoice. There is no line item in the budget that reads “cost of correcting product data before campaign launch.” The cost is distributed. It lives inside the overtime hours, the delayed projects, the team members pulled away from higher-value work, the retailer relationships strained by late or incomplete submissions, and the quiet understanding across the commerce operation that this is just what the week before a major campaign looks like. 

It has always looked like this. It will look like this again before the next one. 

Why Product Data Workarounds Stay Invisible Until They Are Enormous

The reason workaround costs rarely get calculated is structural. They are distributed across teams, time periods, and activities in a way that makes them impossible to see on a single report or dashboard. 

A product manager spending three hours correcting attribute values before a retailer submission records that time as product management work. A commerce operations lead spending two days building and maintaining a master correction spreadsheet before a seasonal launch records that time as campaign preparation. A data team member investigating a rejected feed to identify which attribute caused the rejection records that time as operational support. 

None of these are recorded as what they actually are: the cost of product data quality problems that were never resolved at source. 

According to PwC’s 2026 Digital Trends in Operations Survey, based on 767 operations and supply chain leaders at US companies, 89% of organisations say their technology investments have not fully delivered expected results, and poor data quality is specifically identified as impacting organisations’ ability to achieve value from digital initiatives. The survey surfaces a paradox that most commerce operations leaders will recognise: 84% of leaders say they have become comfortable making decisions even when data is not perfect, while simultaneously acknowledging that poor data undermines outcomes. 

That paradox has a name in daily operations. It is called a workaround. 

The workaround is the gap between what the data should be and what it actually is, filled in by human effort at the point of execution. And because the effort is distributed across many people making many small corrections continuously, it rarely accumulates into a number that anyone calculates. 

MIT Sloan Management Review research by Thomas Redman found that poor data quality costs organisations between 15% and 25% of revenue. The most significant component of that cost is not the errors themselves. It is the human effort spent accommodating those errors — correcting them, working around them, seeking confirmation in alternative sources, and dealing with the downstream consequences when neither correction nor workaround is sufficient. 

That accommodation cost is what most commerce and product data teams are carrying. Silently. Continuously. At scale. 

The Three Categories of Product Data Workaround Cost 

Most organisations think about workaround cost as a single type of problem: people doing manual work that should be automated. The actual cost structure is more complex than that and more expensive. Product data workarounds create cost in three distinct categories simultaneously, and all three are running at the same time in most commerce operations. 

Direct Labour Cost — The Hours That Should Not Exist

The most visible component of workaround cost is the direct labour required to perform the correction. 

A feed enrichment sprint before a major retailer onboarding. A taxonomy reconciliation exercise before a marketplace expansion. A data cleaning project triggered by a channel compliance audit. An attribute correction cycle before every seasonal campaign. 

Each of these consumes hours from people whose time carries a cost. In most organisations, the people doing this work are product managers, commerce operations specialists, or data stewards — roles that are not cheap and are not supposed to be spending their time correcting records that should have been complete when they were created. 

The direct labour cost of a single correction cycle is calculable: hours spent multiplied by the loaded cost of the people involved. What makes this cost structurally invisible is that it is never calculated. It is absorbed into the role’s general activity and reported as operational work rather than as a cost of poor data quality. 

Across a year, across every campaign, every retailer onboarding, every channel expansion, every new product introduction cycle — the accumulated labour cost of these corrections represents a significant operational expense that most organisations have never seen on a single report. 

Opportunity Cost — The Work That Did Not Happen

The second category is less visible and more expensive over time. 

When a product manager spends three days correcting attribute values before a retailer submission, those three days were not spent on something else. The channel expansion analysis that was supposed to happen that week was deferred. The product content improvement project that had been scheduled got pushed. The competitive pricing review that needed to be completed before the end of the quarter was deprioritised. 

Workarounds do not just consume time. They consume the capacity for the higher-value work that the people doing them were hired to do. 

In a commerce operation running continuous correction cycles — which is most commerce operations — the opportunity cost compounds. Teams become perpetually reactive, organised around the next correction cycle rather than around strategic product data improvement. The work that would prevent the correction cycle from being necessary never gets done, because the correction cycle consumes the capacity that would have been used to do it. 

This is the mechanism MIT Sloan Management Review describes as organised cleanup mode: a state in which organisations have formalised their response to bad data without addressing the conditions that create it. As MIT Sloan research on proactive data quality management explains, companies that remain in organised cleanup mode find the gains are generally small. Finding errors is straightforward. Fixing them without understanding the business context is not. And the cycle continues because the root cause — data being created without quality standards enforced at source — is never addressed. 

The opportunity cost of remaining in this mode is not just the time lost. It is the strategic progress that never happened. 

Downstream Execution Cost — What Goes Wrong Despite the Workaround

The third category is the cost that accumulates when the workaround is insufficient, late, or simply missed. 

A retailer feed goes out with a corrected set of attributes, but the correction was based on last quarter’s specification. The retailer has updated their requirements. The feed is rejected. The team investigates. A resubmission is prepared. The window for the promotional placement was missed. The product does not appear in the retailer’s seasonal campaign at the planned position. 

A marketplace expansion onboarding is delayed because the enrichment sprint that was supposed to clean the data before submission was not completed on time. The delay costs two weeks of channel availability during a peak trading period. 

A new product launch goes live across four retail channels with incomplete specifications because the correction cycle ran out of time before the launch deadline. Customer-facing pages show incomplete product information. Conversion rates for those SKUs underperform against the campaign forecast. 

These are downstream execution costs: revenue impact, channel relationship damage, and operational disruption that occur because the workaround either failed to compensate fully for the underlying data problem or was not completed in time to prevent the consequence. 

Deloitte’s research on manual adjustments in the data supply chain identifies exactly this dynamic: manual adjustments across the data supply chain increase complexity and operational risk with a cumulative impact on business outcomes. The cumulative nature of that impact is the critical observation. Each workaround that partially compensates for a data problem leaves residual risk. That residual risk accumulates across every correction cycle, every campaign, every channel, and every product category that is being maintained through manual intervention rather than through a data foundation that performs reliably without it. 

Why Workarounds Feel Like Problem-Solving When They Are Actually Problem-Deferring 

There is a reason workarounds persist in organisations that have the resources and the intention to fix the underlying data problems. They work. In the short term, for the immediate deadline, the workaround delivers the result that was needed. The feed goes out. The campaign launches. The onboarding completes. 

That short-term success is what makes workarounds so expensive over time. 

Every time a workaround delivers the immediate result, it reinforces the belief that the situation is manageable. The campaign launched. The retailer accepted the feed. The quarterly targets were met. The underlying data problem is still there, but the evidence of its cost was absorbed by the team that corrected it and distributed across time and activity in a way that never produced a visible number. 

The next correction cycle begins with the same data foundation the last one started with, because the workaround addressed the symptom and the root cause was deferred to a point when things are less busy, when there is more resource available, when the next governance initiative gets prioritised. 

That point rarely arrives. Because the next correction cycle is already consuming the capacity that would have been used to address the root cause. 

This is the pattern MIT Sloan identifies as the common trap: organisations see themselves as data customers who consume data created elsewhere, correcting errors as they encounter them. They do not see themselves as data creators who are responsible for the quality of the data at the point it enters the system. The correction cycle perpetuates itself because the mindset that would break it — every person who creates or modifies data is responsible for its quality at source — never gets established. 

The workaround culture and the data quality problem are self-reinforcing. Workarounds make it possible to operate without addressing the root cause. Operating without addressing the root cause guarantees that workarounds will always be necessary. 

The Compounding Effect — Why Workaround Costs Grow Faster Than the Business 

The most dangerous characteristic of product data workaround costs is that they compound. 

As a commerce operation grows — more products, more channels, more retailers, more campaigns, more regions, more supplier relationships — the volume of data that needs to be maintained grows with it. If that data is being maintained through correction cycles rather than through a quality foundation, the correction work grows proportionally with the business. More products means more records to correct. More channels means more channel-specific requirements to accommodate. More retailers means more feed specifications to manually maintain. 

The business scales. The workaround cost scales with it. 

In an organisation managing product data well — with governance embedded in the systems where data is created, with ownership enforced through workflow checkpoints, with quality standards applied at the point of entry — business growth does not proportionally increase the correction workload. The foundation absorbs the growth because the standards and controls apply to new products and new channels through the same system logic that applies to existing ones. 

In an organisation managing product data through workarounds, growth creates more workarounds. The correction team grows. The correction sprints get longer. The tools built to manage the corrections — the master spreadsheets, the validation macros, the pre-submission checklists — become increasingly complex. The institutional knowledge of how to run the correction cycle becomes a critical operational dependency, concentrated in a small number of people who know which retailer requires which format and which product category needs which manual override. 

That concentration of knowledge in individual people rather than in documented, system-enforced standards is itself a risk that most organisations have not priced. When those people leave, or change roles, or are unavailable during a critical launch window, the correction capability temporarily disappears and the consequences arrive immediately. 

What the Workaround Budget Would Look Like If Anyone Built It

Most organisations have never tried to calculate the total cost of their product data workarounds. The distributed nature of the cost makes it genuinely difficult to aggregate. But the exercise is worth attempting, because the number that emerges is almost always larger than expected and almost always larger than the investment that would be required to address the root cause. 

A workaround budget for a typical commerce operation would need to account for: 

Direct correction labour: The hours spent by product managers, commerce operations specialists, data stewards, and marketing operations teams on attribute corrections, taxonomy reconciliations, feed reformatting, enrichment gap filling, and data conflict resolution — multiplied by the loaded hourly cost of those roles — across every campaign, every retailer onboarding, every channel expansion, and every new product introduction cycle in a twelve-month period. 

Management oversight of corrections: The time spent by team leads and managers planning correction sprints, allocating resource, reviewing outputs, managing escalations, and reporting on readiness status — all of which exists because the correction cycle exists. 

System and tooling cost: The licences, build time, and maintenance cost of the tools built to manage corrections — validation spreadsheets, data cleaning scripts, pre-submission checklists, custom integrations designed to compensate for data quality gaps between systems. 

Downstream execution failures: Lost revenue from retailer feed rejections, delayed channel launches, incomplete product pages, missed promotional placements, and onboarding delays — each of which can be partially or fully attributed to product data quality gaps that workarounds failed to compensate for in time. 

Opportunity cost: The value of the strategic work that was deferred because the correction cycle consumed the capacity that would have been used to do it. This is the hardest to calculate and the most significant over time. 

Most organisations that have attempted this calculation have found the total exceeds the cost of the governance, system, and process investment that would address the root cause. The workaround is more expensive than the fix. It is simply more visible as individual corrections and less visible as an aggregate cost. 

Why Workarounds Survive Governance Initiatives and Platform Migrations

The previous blogs in this series established two specific patterns. Replatforming rarely eliminates product data problems because the migration moves the data without changing the conditions that create the problems. Governance initiatives rarely produce lasting operational change because the frameworks they produce sit above the operational workflows where data decisions actually happen. 

Both patterns produce the same consequence: the workaround survives. 

After a platform migration, the correction cycle continues in the new environment because the data foundation that was migrated was the same data foundation that required corrections before the migration. The platform changed. The correction workflow transferred with the data. 

After a governance initiative, the correction cycle continues because the governance framework defined the standards without embedding them in the systems where records are created. The standards exist in the documentation. The correction workflow continues because the system does not enforce the standards at the point of data creation. 

This is why workaround costs are so persistent. They are not caused by any single failure. They are the cumulative consequence of a series of investments — platform, governance, ownership — that each addressed a visible aspect of the product data problem without reaching the root cause: the absence of quality enforcement at the point where data enters the system and at every point where it is subsequently modified. 

Until that enforcement exists — in the form of validation rules, required fields, controlled vocabularies, automated completeness checks, and workflow checkpoints that prevent non-compliant records from progressing — the workaround will fill the gap. Because something has to. 

How to Calculate What Your Workarounds Are Actually Costing

Before scoping the next data quality initiative, technology investment, or governance programme, one exercise is worth completing. 

Map every correction cycle your commerce and product data teams run in a typical quarter. For each one, record: 

• Who performs it and how many hours it takes
• What triggers it — a campaign, a retailer submission, a channel onboarding, an audit 
• What the consequence would be if it were not performed 
• Whether it addresses the same underlying issue as the previous cycle 

Then apply a loaded cost to the hours. Add an estimate of the downstream revenue impact of the correction cycles that were incomplete or late. Add the management time spent planning and overseeing them. 

The number that results is your current workaround budget. It is what you are already spending, distributed invisibly across roles and activities, to compensate for a data foundation that does not perform reliably without human intervention. 

Compare that number to the cost of the investment that would reduce it. In most commerce operations, the comparison is instructive. The workaround budget is larger. Often significantly larger. And unlike an investment in fixing the root cause, the workaround budget does not decrease over time. It grows with the business. 

What would it take for your largest seasonal campaign to launch without a correction sprint in the week before it? If the answer is unclear, the workaround budget is doing more work than the data foundation, and the gap between them is costing more than most organisations have calculated. 

What Organisations With Low Workaround Costs Do Differently 

Organisations that have genuinely reduced their product data correction workload share a characteristic that is less about the sophistication of their technology and more about where quality is enforced. 

In a low-workaround commerce operation: 

• Product records cannot be activated until completeness thresholds are met for every configured channel. The incomplete record does not reach the submission queue. It gets flagged at creation, not at launch week.

• Taxonomy classifications are controlled vocabularies in the PIM. A product manager cannot enter a free-text category. They select from approved values. The taxonomy drift that creates downstream feed rejections does not accumulate because the system does not permit the local classifications that cause it. 

• Supplier data goes through an automated validation on ingestion. Records that do not meet the quality threshold are quarantined before they enter the active product catalogue. The enrichment gap sprint before every campaign launch does not exist because the gap is identified and resolved before the record is ever live. 

• Channel-specific attribute requirements are mapped to product creation workflows. When a product is assigned to a channel, the system surfaces the required attributes for that channel and flags gaps immediately. The channel compliance discovery that currently happens during pre-submission review happens at the point of product creation instead. 

None of these require extraordinary technology. They require the quality standards that governance initiatives typically document to be translated into system logic — validation rules, required fields, workflow triggers, automated checks — rather than left as policies that teams are expected to remember and apply manually. 

The translation is the work. And it is the work that most organisations defer because it comes after the governance initiative closes and the project has already been declared complete.

ThoughtSpark works with enterprise data and commerce teams to identify where product data workaround costs are accumulating and what it takes to build the operational foundation that reduces them. If the correction cycles described in this article are a recognised part of your commerce operation, the conversation worth having is about the cost of continuing them versus the investment required to address what is causing them.

There is a moment most data and commerce leaders recognise.

A product record arrives in the wrong state. An attribute is missing. A classification is inconsistent with what three other records in the same category use. Someone investigates. The record has a named owner in the governance framework. That person is contacted. They did not know the record existed. Or they knew it existed but did not know they were responsible for its quality. Or they knew both of those things but had no clear way to act on the responsibility within the systems and workflows they use every day.

The ownership was assigned. The accountability never arrived.

Most organisations that have invested in product data governance have also invested in defining ownership. It appears on the framework as one of the foundational elements — stewards named, domains scoped, responsibilities documented. In practice, ownership tends to be the part of the governance framework that looks most complete on paper and functions least reliably in operations.

Understanding why that gap persists, and what it takes to close it, is what this blog works through.

Why Product Data Ownership Breaks Down After Governance Initiatives

Ownership is assigned during governance initiatives because the initiative creates the right conditions for that conversation to happen. Stakeholders are engaged. The question of who is responsible for what gets raised in workshops and working groups. Decisions get made and documented. A steward is named for each domain or product category. The framework reflects genuine organisational agreement.

The initiative then closes.

What the initiative produced was a record of who is responsible. What it did not produce was a change to the environment where those responsible people actually work. The systems they use day to day, the workflows they follow, the approval processes they operate within — none of these changed because of the ownership assignment.

According to Cynozure’s 2026 State of the Industry Report, based on insights from 60 senior data and AI leaders across sectors including retail, consumer goods, and financial services, 40% of organisations still split data strategy ownership across multiple executives, and 17% report no clear owner at all. These are not small organisations with immature data practices. Nearly half of respondents reported revenue over £1 billion. Ownership fragmentation at that scale is not a resourcing problem. It is a structural one.

The governance framework named a steward. The operational environment kept running without them.

The Difference Between Assigned Ownership and Operational Accountability

What Ownership Assignment Produces

When governance initiatives define data ownership, they typically produce:

• A named steward for each data domain or product category
• A documented scope of responsibility
• An escalation path for resolving data conflicts
• A RACI or equivalent matrix showing who is responsible, accountable, consulted, and informed
• Governance meetings where ownership decisions get made

These are real outputs. The conversations that produced them required genuine organisational alignment. The ownership structure reflects something that was agreed.

Why Operational Accountability Does Not Follow Automatically

A named steward can only influence product data quality at the moments when the system or workflow routes a decision to them. If those moments do not exist — if the product creation workflow does not require steward approval, if the enrichment process does not trigger a review, if the taxonomy update does not notify the domain owner — then the steward is responsible in the governance framework and invisible in the operational process.

Research published in the Journal of Business Analytics by Fadler and Legner at the University of Lausanne examined data ownership in enterprise organisations and found that allocating ownership rights has a direct effect on system implementations only when that ownership is enforced through the systems and workflows where data is actually created and modified. Ownership defined in documentation, without corresponding enforcement in systems, produces a responsibility that exists on paper rather than in practice.

That distinction is where most product data ownership structures break down. The steward was named in the workshop. The system never learned their name.

How Ownership Confusion Creates the Operational Problems Teams Experience

When ownership exists nominally rather than operationally, the consequences are specific and recurring. They tend to show up in a consistent set of situations.

Conflicting Product Records Across Systems

When multiple teams can update the same product record without a stewardship checkpoint, the record reflects whoever updated it most recently. The merchandising team updates the product description for a promotional campaign. The supply chain team updates the same record with logistics attributes. The digital team updates it again with channel-specific content. No single version is authoritative. No one is sure which one should be.

The governance framework has a named owner for this product category. That owner was not consulted during any of these updates. They find out about the conflict when a retailer rejects the feed.

Taxonomy Inconsistency That Governance Did Not Prevent

A product manager introduces a new subcategory for an incoming range. The taxonomy owner exists on the governance framework. The product creation workflow does not require their approval before the classification is saved. Three months later, the same product type has been classified under four different values by four different team members who each created what made sense to them at the time.

Enrichment Gaps That Surface at the Wrong Moment

A new marketplace requires a set of attributes the existing product records do not carry. An enrichment owner is named in the governance framework. The workflow for adding new channel requirements does not loop them in. The gap is discovered during onboarding, not during product creation when it would have been far cheaper to address.

In each of these situations, the ownership structure was in place. The operational process ran around it.

Why Ownership Breaks Down More Predictably in Complex Organisations

The governance initiative assigned ownership at a point in time, for a data environment that existed during the initiative. Organisations are not static. Ownership structures degrade as the organisation around them evolves.

New product categories get created that the original ownership matrix never anticipated. Teams are restructured and named stewards move to different roles or leave the organisation. Systems get added or replaced and the integration between the new environment and the governance framework is never fully established. Commercial urgency produces decisions that bypass the stewardship process because the deadline is today and the steward is available next week.

Gartner’s research on data governance platforms consistently identifies the gap between governance maturity as measured by framework completeness and governance effectiveness as measured by actual data quality outcomes. Organisations with documented ownership structures and organisations with operationally enforced accountability produce measurably different results, and the gap between them grows over time as business complexity increases.

The ownership framework was built for the organisation as it existed. The organisation kept changing. The framework did not adapt with it.

What Operational Accountability Actually Requires

Organisations where product data ownership produces real accountability tend to have made one decision that others have not. They stopped treating ownership as a governance artefact and started building it into the operational environment where data decisions get made.

In practice, that looks like:

• A product record in a given category cannot be activated without a review step that routes to the named domain owner
• A taxonomy classification outside the approved vocabulary triggers an automatic flag before it can be saved
• An enrichment gap against a channel’s required attribute set surfaces as an alert to the owner before the product reaches syndication
• When a steward changes roles or leaves, the system flags the orphaned records and the ownership gap gets resolved before it produces downstream problems

None of these require an extraordinary governance programme. They require the ownership decisions made during the governance initiative to be translated into system logic rather than left in a document.

That translation is the work that most organisations defer, or never resource, because it comes after the initiative closes and the governance project has already been declared complete.

The Question Worth Asking About Your Current Ownership Structure

Before the next governance initiative adds more names to an ownership matrix, one question is worth sitting with.

For each named data steward in your governance framework, can you point to a specific system step, workflow trigger, or approval checkpoint that makes their ownership operational? Or does their responsibility exist primarily in the documentation?

If the answer is documentation for most of them, the ownership structure is more complete on paper than it is in the systems where product data actually gets created, updated, and submitted.

That gap is not resolved by adding more stewards or running clearer workshops. It is resolved by connecting the ownership decisions the governance initiative made to the operational environment those decisions were meant to govern.

If the patterns feel familiar, the starting point is usually not a new ownership framework. It is understanding where the existing one stops influencing what actually happens to the data.

That is the gap ThoughtSpark helps enterprise data and commerce teams identify and address: the distance between ownership as it was assigned and accountability as it needs to operate.