‘PRODUCT IDENTITY’
CRISIS
Turning a 3.5M SKU mess into a platform asset in one initiative
THE
PROBLEM
The catalog was its own worst enemy
After a decade of rapid supplier expansion, FindItParts had 3.5M SKUs and no unified identity structure. The same physical part would appear dozens of times under different naming conventions depending on which supplier submitted it. Customers were effectively asked to resolve the ambiguity themselves.
In a category where ordering the wrong part means vehicle downtime, that friction had real consequences: high return rates, elevated support volume, and eroding trust in search.
Catalog quality surfaced in a business review as a drag on growth. I audited support tickets, analyzed search pages on high-volume categories, and mapped the downstream impact across purchasing and returns.
What looked like a data hygiene issue was a structural platform deficiency compounded over a decade.
THE
REFRAME
Infrastructure, not maintenance
The stakeholders wanted to spend a sprint on a 1-time cleanup.
I pushed back on that framing for one reason: a sprint approach would only address the symptoms without touching the cause.
We had hundreds of active suppliers continuously feeding new data into the catalog. Without a structural intervention, we'd be cleaning the same mess every three to six months.
I reframed the initiative to leadership as building a Product Identity capability where the system defines a Parent SKU and the duplicate variants are rolled up under it.
That framing unlocked broader engineering investment and executive alignment, because it positioned the work as infrastructure rather than maintenance.
THE
APPROACH
PHASE 1
PHASE 2
PHASE 3
Before cleaning anything, we needed a shared definition of what made a product unique. I facilitated an audit of manufacturer part numbers (MPNs) and cross-reference equivalents, establishing the MPN as the primary key. Distributor data could enrich a record but not override manufacturer specs.
Without this explicit definition, every engineer and supplier had a different working assumption. The audit aligned engineering, catalog ops, and supplier management before a line of code was written.
Defining the Identity DNA
We developed an automated conflict resolution engine that examined duplicate records and determined which SKU should be set as the parent and which duplicate SKUs should be merged under it.
Conflicts outside the engine's confidence threshold were surfaced for human review.
Result: 1.5M duplicates removed, 60% of the catalog cleaned, with a full audit trail.
Build the Merging Engine
I worked with engineering to build a validation layer into the Supplier Onboarding portal: no new data enters without passing an Identity Match check. Records matching an existing MPN enrich it rather than creating a duplicate.
This shifted the org from corrective (patch bad data after entry) to preventive (stop it at the gate).
The Governance Engine
THE HARD CALLS
Build vs. buy
and winning over the skeptics
We evaluated third-party master data management (MDM) tools early on and landed on custom identity logic. Generic platforms weren't built for heavy-duty trucking's cross-reference complexity and the customization required would have cost more than building targeted logic ourselves.
The harder challenge was the Supplier Onboarding team, whose primary metric was speed. To them, adding a validation step looked like friction.
I brought in data that showed every hour of upfront validation eliminated several hours of reactive post-cleanup and the cleaner data meant better visibility of products in search. Once the framing shifted, they became advocates for the gate rather than critics.
THE
RESULTS
2X
Faster Supplier Onboarding
40%+
Reduced Manual Intervention
1.5M
Duplicate SKUs Removed
Catalog Integrity: Parent SKU for every part in the system.
Operational Efficiency: Manual patching time dropped 40%+ and sped up supplier onboarding.
Preventive Architecture: The governance engine ensured new supplier data did not create duplicates anymore.
Duplicates removed.
Measurable efficiency in supplier onboarding.
Revenue protected.
THE
TAKEAWAY
Systems beat sprints
A cleanup effort without a prevention layer is a temporary fix that will need repeating. You cannot sprint your way out of structural debt. The governance and merging engines helped us solve the root cause rather than put a bandaid on the problem.
The same logic applies to any platform problem where the root cause is upstream of where the symptoms appear. The right intervention isn't always where the pain is most visible.