What was actually wrong.
Product data problems are rarely confined to one system. They show up in catalogue structure, enrichment work, ownership and the effort needed to prepare information for each channel.
DNATA needed governed product information that could be modelled once and syndicated to every retailer, marketplace and channel where the Food & beverage range is sold.
Product data ownership, attribute structure and channel-specific feed rules were likely sources of operational friction, with brand, editorial and trading teams reconciling the same product record for each retailer.
Shoppers meeting the brand on retailer sites, marketplaces and syndicated channels needed consistent, complete product information so the range is represented accurately wherever it appears.
Product information was spread across teams and systems, making catalogue management harder to control and product content harder to reuse with confidence.
Enrichment work needed a clearer workflow, with ownership defined for the people preparing, checking and maintaining product information.
Attributes, product models and category structure needed common rules so the catalogue could stay consistent as products and channels changed.
What happens if it isn't fixed.
When product information is difficult to maintain, teams compensate with manual work. The result is slower onboarding, inconsistent content and less confidence in the catalogue.
When product information drifts across retailer sites, marketplaces and syndicated channels, shoppers stop trusting listings and the brand absorbs the returns, complaints and lost baskets.
Most relevant to Food & beverage teams running B2C and D2C operations and weighing similar platform decisions.
Poor product data makes teams work around the catalogue instead of improving it. Product onboarding slows down, enrichment becomes repeated manual effort and ownership stays unclear.
That creates catalogue drift and inconsistent product presentation. It also weakens confidence in the information each channel receives.
The longer those gaps remain, the harder it becomes to reuse product data across channels without another round of checking, correction and content rework.
Five things, in order.
Delivery is not just a list of features. The order matters, because the wrong sequence can turn technical dependencies into business risk.
- 01Audited the product data shape before changing workflowsMapped the existing product information, catalogue structure and maintenance work so the team could see where inconsistency and repeated effort entered the process.
- 02Defined ownership around product information and enrichmentSet clearer responsibility for creating, enriching, checking and maintaining product information across the teams involved.
- 03Structured attributes, categories and content rulesOrganised product models, attributes and category rules so the catalogue could stay consistent as the range and channel requirements changed.
- 04Connected product data to the systems and channels that needed itDefined how product information moved through fulfilment and ERP, including which system owned each part of the product record.
- 05Put governance in place so the data could keep improvingEstablished maintainable rules for enrichment, content consistency and ongoing data quality instead of treating catalogue preparation as a one-off task.
Systems, one operational truth.
Where this could have gone wrong.
Measurable, not adjectival.
The useful proof is the shape of the product data work, the systems and channels involved and, where available, the numbers recorded from the project.
What moved into support.
Product data work continues after the initial structure is in place. Teams still need to enrich records, maintain quality, support new products and prepare information for changing channel needs.
The product data foundation moved into ongoing maintenance and improvement.
Support kept data ownership, enrichment workflows, catalogue structure and channel readiness visible as the product range changed.
That continuity gave teams a clearer basis for resolving data issues and improving product information without claiming an unverified outcome.
Surfaces from the live project.
Screenshots show how governed product information, content and assets are prepared for the channels and teams that use them.
Projects with a similar shape.
A pizza oven PIM project built around product accuracy, digital assets and international retail activity.
Product data quality updated across a fast-growing outdoor cooking catalogue.
A buying group PIM project built around product data, catalogue scale and supplier complexity.
Faster product data management across a complex wholesale buying group catalogue.
A buying group PIM project designed around catalogue scope, product data and governance.
catalogue scope supported by cleaner product governance and faster enrichment workflows.