(Yes, I’m calling it concise.)

If you’ve been told that product data strategy can be explained in a short checklist, you’ve been misled. Product data isn’t a side project or something you “clean up later.” It’s an operating model that touches every part of the business — sales, operations, logistics, finance, eCommerce, marketing, compliance, the warehouse, and ultimately the customer.

Executives rarely underestimate product data because they’re careless. They underestimate it because the consequences surface far away from where decisions get made. If the CEO had to personally handle freight reclass charges, fix GTIN variances, or respond to marketplace suppressions, product data maturity would rise overnight.

That’s why this blog is longer. To explain this properly, it must be.

As a refresher:

• Issue #1 made the case for building a culture that respects data.Issue #2 showed the financial impact of bad product data — and that the cost is already hitting your P&L whether anyone is tracking it or not.

This issue brings it home:

“So what does a real product data strategy actually look like — and how do we implement it in a way that sticks?” And because “concise” and “comprehensive” don’t always agree with each other, consider this my attempt to make them shake hands.

Most companies treat product data as a technical detail — a cleanup project, a migration task, a PIM implementation. Something you “fix once” and move on from.

But product data problems aren’t technical by nature.

Bad freight class isn’t a data problem.

Missing GTIN isn’t a data problem.

Duplicate SKUs aren’t a data problem.

They’re organizational problems that surface through data.

Every recurring data issue is a symptom of something upstream — unclear ownership, no documented process, unknown rules, conflicting systems, multiple versions of truth, and well-meaning employees who are forced to invent local solutions.

Until leadership acknowledges this, the business quietly absorbs the cost — in rework, lost sales, margin leakage, customer churn, operational drag, inventory write-offs, shipping penalties, and marketplace suppression.

My aim is to help you stop absorbing that cost.

Before we dive into the details, we need to talk about structure. Product data doesn’t improve through enthusiasm, new tools, or the occasional cleanup project. It improves because the business has a simple, reliable operating model that everyone understands. That operating model comes down to four pillars. Nothing fancy. Nothing theoretical. Just the four things every organization must get right if they want product data to stop being a recurring headache.

These four pillars — People, Process, Data Standards, and Platforms — are the framework we’ll use for the rest of this strategy. Think of them as the scaffolding that keeps everything else upright. Once these are in place, everything downstream becomes exponentially easier.

Let’s walk through them.

Pillar 1: People — Ownership That Actually Means Something

If one theme has emerged across nearly every distribution and manufacturing organization I’ve worked with, it’s this:

When everyone “shares responsibility,” nothing gets fixed.

Product data breaks not because people don’t care, but because responsibility is ambiguous. And ambiguity is expensive.

Here are the common types of “ownership” I see:

1. Shadow OwnershipA field appears to belong to five people — until something breaks, and suddenly it belongs to no one.
2. Assumed OwnershipTeams assume “Purchasing owns that,” or “Marketing owns that,” or “Engineering owns that,” but none of those teams believe they actually do.
3. Reactive OwnershipA person becomes the “owner” only after something catches fire. Ownership by firefighting is not ownership.
4. Fragmented OwnershipDifferent regions, divisions, or sites maintain their own versions of the same fields. All slightly different. All technically “right.” None consistent.
5. Lost OwnershipOwnership walks out the door when an employee leaves. No institutional memory remains.

The Fix: Ownership by Field, Not by Department

The only scalable model is this:

• One person owns weightOne person owns freight classOne person owns GTINOne person owns MPNOne person owns Country of OriginOne person owns voltageOne person owns costOne person owns primary image
• And so on…

Not the department.

Not “shared responsibility.”

One accountable owner per field.

What Ownership Really Means

Most organizations say someone “owns” a data field, but rarely define what that actually includes. True ownership is not about typing values into a system — it is about ensuring the logic, purpose, quality, and business outcomes of the field remain intact over time.

Ownership means the person is accountable for:

• The business logic – What the field represents, why it exists, and how it behaves under different business scenarios.
• The rules and expectations – Allowed values, formats, units, ranges, exceptions, and the conditions under which the field must be updated.
• Defining what good and bad data look like – Practical examples, common failure patterns, and the edge cases that tend to break downstream systems.
• Upstream and downstream impact – Where the value originates, which teams rely on it, and what operational or financial consequences occur when it is wrong.
• The tools and mechanisms that support the field – The owner defines the logic behind templates, validation rules, macros, PowerQuery steps, automation checks, or dashboards used to maintain their field — even if they do not build the tools themselves.
• The lifecycle of the field – How it is created, updated, reviewed, verified, governed, and eventually retired or replaced.
• Performance of the field – A true owner monitors the quality and stability of their field over time — error rates, recurring defects, exceptions, and the measurable impact their attribute has on the business.

Ownership is not custodianship.

Ownership means: “I am accountable for the clarity, correctness, and consequences of this field.”

This structure alone eliminates a meaningful share of recurring issues within the first 60 days, because it removes the “I thought someone else was handling that” factor.

Now do you see why one person must be the owner of each field?

Supporting Roles:

Alongside field owners, you will want to have supporting role:

Data Steward – Stewards run the operational process — intake, verification, and quality enforcement — ensuring the owner’s rules are applied consistently and accurately.

Executive Sponsor – The executive sponsor provides authority, alignment, and organizational air cover, ensuring that ownership, standards, and processes are respected across departments.

Product Team – The product team consumes the data to build digital experiences and customer value, but is not responsible for defining, cleaning, or governing the data itself.

(Please keep in mind that the size of your organization will depend on how much you will want to invest in the robustness of these different roles. Obviously, if you are a small one- or two-person team, this becomes very difficult. If you are in this position, don’t be overwhelmed of how much you are missing! Just start incorporating these different roles in your daily activities. It then becomes clear where you need to add resources!)

When people know who owns what, every subsequent pillar becomes easier. It becomes possible to answer basic questions like “Who needs to approve this change?” without a 15-person email thread.

Pillar 2: Process — The Intake → Triage → Fix → Verify Loop(and the Principle of Process Over Project)

Most product data problems aren’t catastrophic. They’re small, recurring issues that never get resolved cleanly because no one knows where they go, who handles them, or how they move from “problem” to “resolved.”

This is where “process over project” becomes foundational.

Companies tend to reach for projects when something hurts: a cleanup project, a “data sprint,” a taxonomy project, a PIM implementation project. Those can be useful — but only if they sit on top of a clearly defined process.

Here’s the truth:

Projects fix symptoms. Processes prevent them.

Every company knows the feeling:

• You fix something through a project……everyone celebrates……and 18 months later, the exact same issue is back.And you quietly fund another project to fix it again.

Why does that happen?

Because the root cause was never addressed: there was no process underneath the project.

Projects reset the data.

Processes sustain the improvement.

Teams burn out because nothing stays fixed.

Every cleanup becomes temporary.

Every migration is a reset button.

Every PIM implementation becomes a mirror reflecting broken processes.

You deserve better. And your teams deserve better.

The 5-Step Data Quality Loop

A functional organization has one simple, repeatable operational loop:

1. IntakeAll requests, issues, and corrections enter through a single controlled channel.– Not Slack messages– Not hallway conversations– Not “Hey, can you fix this real quick?”– Not personal spreadsheets scattered across laptopsA simple intake form beats a sophisticated system that nobody uses.
2. TriageRank by business impact, not by who shouted loudest.– A weight error on a top seller → high impact– A missing spec on a slow mover → lower impactImpact-based triage prevents the loudest voice from always winning.
3. FixThe field owner resolves the issue using the documented data standards (Pillar 3), instead of inventing a new interpretation every time.
4. VerifyA steward confirms accuracy before the update hits ERP, PIM, eCommerce, pricing, logistics, or analytics systems. This extra moment prevents bad fixes from turning into new problems.
5. PublishThe change moves downstream with confidence. Everyone knows it’s correct and where it came from.

Process Over Project — In Practice

“Process over project” doesn’t mean projects are bad. It means that a project without an underlying process is a temporary reset.

A project can:

• clean up dimensions on your top 5,000 SKUsstandardize freight classnormalize GTINsmigrate attributes into a new PIM

But unless there is a process underneath that governs how those fields are maintained going forward, the problem will slowly return.

A practical starting point is to document one process per week.

Ask each field owner:

1. What triggers a change?
2. Where does the request come from?
3. What rules guide the change?
4. Who approves it?
5. What systems does it affect?
6. How do we verify accuracy?
7. How do we publish the update?

You’ll learn more in those conversations than you expect. You’ll find gaps, local workarounds, and “we’ve always done it this way” patterns that explain why issues keep coming back.

Why This Matters

Until a process exists:

• Automation is impossibleWorkflow tools either fail or get bypassedPIM rules can’t be enforced consistentlyTeams quietly revert to personal spreadsheetsNo one can train new hires properly because there’s nothing written down

Process turns chaos into signal — and signal into progress. Projects are still valuable, but the most rewarding project is one where the team finishes knowing, “We’re not going to have to redo this in 18 months.”

Pillar 3: Data Standards — The Constitution of Product Data

You cannot govern what you have not defined.

Data standards transform product data from tribal knowledge into a stable operational system. And the beautiful thing is: you don’t need fancy software to create them.

A well-structured Excel file is often more valuable than a metadata repository, especially early in the journey. The APEX data model is a great example — a structured, field-by-field model with definitions, types, and rules that both business and technical teams can understand and use.

Here is how to build standards that everyone can work with.

How to Document Data Standards (APEX-Style, Generalized)

Your standards template can be simple, but it should be complete. At a minimum, include:

• Field NamePublic-facing definition — written in plain languageTechnical definition — written for engineers and system adminsData type — string, decimal, integer, boolean, dateAllowed values — controlled lists, ranges, formatsUOM rules — accepted units, prohibited units, conversion expectationsGolden source — ERP, supplier, internal engineering, etc.Validation rules — required/not required, min/max ranges, prohibited valuesDownstream usage — freight, eCommerce filters, SEO, warehouse slotting, analytics, etc.Examples of good dataExamples of bad data (what not to do)Change control rules — who approves changes and under what conditionsOwner — the accountable field owner from Pillar 1

This turns abstract fields into operational assets.

You are no longer just saying “we have a weight field” — you are saying:

“This is what weight means, here’s where it comes from, here’s how it should be formatted, here’s who owns it, here’s where it’s used, and here are examples.”

Where to Start

If you feel overwhelmed, begin with the fields that matter most:

• WeightDimensionsGTINBrandMPNHazard fieldsPack quantitiesCost

These fields drive freight cost, shipping accuracy, search and filter behavior, marketplace compliance, and customer expectations. Fixing them provides visible business value quickly.

How to Communicate Standards to Technical Teams

Technical teams don’t need 50-page essays. They need clear, structured information.

Practical approach:

• Use Excel or Google SheetsFreeze the header rowKeep one attribute per rowUse separate tabs for:– Global attributes– Category-specific attributes– Enumerated value listsUse comments for business rules and edge casesAdd a column to indicate required fieldsAdd a simple version number and “last updated” date

You can implement more sophisticated tools later. For now, a clear, shared document that everyone respects is far more valuable than a complex system full of vague fields.

Data standards are the “constitution” of product data — they reduce debate, speed up decisions, cut rework, and give new hires a fighting chance.

Pillar 4: Platforms — Start Low-Tech, Grow With Maturity

Most companies rush to enterprise tools too early. They assume that if they pick the right PIM, or the right MDM, the data problems will go away.

In reality, tools magnify the state of your process.

If you have weak ownership and no standards, your tools will simply amplify that inconsistency and make it more visible.

Instead, think of platforms as a maturity ladder.

Stage 1: Low-Tech, Business-Driven Tools

Start with tools that your business users already know and can adopt quickly:

• Excel (with structured templates for item setup and attribute capture)Excel + Power Query to clean supplier files and normalize columns, units, and formatsExcel macros for repeatable transformations (like UOM conversions or column reshaping)SharePoint or Teams lists to track intake, status, and ownership of data issuesGoogle Sheets for collaborative attribute modeling when teams are remote or cross-functional

These tools:

• Cost little or nothingAre easy for business users to learnReduce dependence on IT for every changeReveal where your process is broken

A basic Power Query workflow can take a messy supplier file and output something that aligns with your attribute standards — without any enterprise software.

Stage 2: Mid-Tech, Process-Guided Tools

Once your processes are real (not just slides), mid-tech tools can help scale and monitor them:

• Power BI or similar tools for data quality dashboards and exception reportingSQL queries or scripts for spotting outliers (extreme weights, missing attributes, invalid ranges)Microsoft Lists + Power Automate or similar workflow tools to route intake requestsLightweight data quality tools for completeness, duplicates, and formatting rulesInternal scripts or services to enforce attribute normalization for search and filtering

Here, the tools reinforce process. They don’t replace it.

Stage 3: Enterprise Systems (Chosen Last, Not First)

When your processes are stable and your standards are trusted, then enterprise platforms become accelerators instead of sources of frustration.

At this stage:

• ERP remains the operational and financial system of recordPIM governs product content, attributes, relationships, and completenessWorkflow engines automate the intake → triage → fix → verify loopSupplier portals standardize inbound data from vendorsData quality platforms scale anomaly detection and rule enforcement

If you choose enterprise tools before processes and standards exist, the tools will simply expose chaos. If you choose them after maturity starts to take hold, they will scale what already works.

A product spec travels farther than leadership often sees:

Supplier → Purchasing → ERP → Inventory → PIM → Category → eCommerce → Marketing → Sales → Customer → Returns → Analytics

At each step, data can drift:

• Units changeDimensions get overwrittenLegacy formatting reappearsSomeone “fixes it locally” in a spreadsheetOutdated values reenter the system from old filesMarketplace feeds suppress items without clear explanation

Your strategy should exist to prevent drift, not just react to it. That is why documentation, standards, and process matter so much — they anchor the data as it moves.

Remember in our last blog we tied value to data? Everything in this strategy ties directly to financials.

If someone doubts the ROI, don’t argue with them. Measure it.

Use the Bad Data ROI Checklist from Issue #2 as a starting point. Put dollar estimates next to a few of the issues you already know you have. Executives make better decisions when the cost is visible, not theoretical.

What Good Looks Like

A mature product data organization doesn’t look perfect. It looks predictable.

• Ownership is clear.Issues have a defined path.Fixes are verified before they propagate.Data has standards and rules.Systems reinforce the process instead of fighting it.Audits surface problems before customers do.Metrics show trends and improvement, not random spikes.Teams spend more of their time building and less of their time cleaning.

This is what a real product data strategy unlocks.

Why This Issue Is Long (Intentionally)

Product data can’t be reduced to a buzzword or a slide in a strategy deck. It is one of the least glamorous and most consequential foundations of running a modern business.

So yes — I called this a concise product data strategy. It’s only “concise” relative to how deep this topic truly goes. As I’ve written and edited this, I’ve had to stop myself from continually adding more.

If you’re still here, reading Issue #3, you already understand something important:

Your competitive advantage isn’t your product catalog.

It’s your ability to operationalize it.

And that starts with leadership choosing process over project — every time.

CTA

• Take the Data Culture Maturity AssessmentDownload the Bad Data ROI ChecklistUtilize the 180 day checklist to build out your data strategy