Product data management is the part of the work nobody talks about on a stage. There is no campaign to show, no award, no image for a portfolio. It is about colour names, material declarations, size runs, care instructions and making sure the same pair of trousers carries the same name in four systems. I have still seen very little that decides as reliably whether marketing works at all.
The reason is simple. Every feed, every translation, every recommendation in the shop reaches into those fields. If they are wrong, the error gets multiplied rather than corrected. Product data management is therefore not a systems question you hand to IT, it is the ground everything else stands on. A brand that leaves it lying pays later in time, a little every day.
- Product data management decides whether marketing works and never shows up in a campaign.
- Fashion makes it harder than elsewhere because colour, size and season keep moving.
- The most common failure is that nobody owns it and everybody owns a little.
- Automation multiplies bad data, it does not repair it.
- Maintaining fields nobody uses only moves the problem somewhere else.
Table of contents
What product data management actually means day to day
At its core, product data management answers a banal question: what is this thing, and is it called the same everywhere. Behind that sits a structure of fields, rules and responsibilities that decides which entry is binding and which may be derived. The literature calls it product information management, and the clumsy term describes it better than the abbreviation people use.
In practice it means there is one place where the truth about a product lives, and every other system draws from it. That sounds obvious. In most houses it is not, because over the years three or four places have grown up, each of them a little bit right. The result is familiar: the colour is ecru in the shop, natural white in the catalogue, beige in the ad.
The second part is less technical than it looks. Product data management is above all an agreement about who gets to decide. Whether a jacket is carried as a light coat or as a coat is not a data question but a range question. Until it is answered no system helps, because a system only stores what somebody types into it.
Why product data management is harder in fashion
In many industries a product does not change for years. In fashion it changes every season, and not only the article but the language around it. A colour is named differently this year than last, a cut gets a new name, a line is renamed. Product data management has to absorb that without making the past unreadable.
Then there is volume. An article consists of variants, every variant of sizes, every size of availability per market. What starts as a manageable list becomes a number nobody checks by hand any more. That is exactly where product data management proves its worth, because it has to catch the cases no human will ever look at.
And finally language. We play the same collection into several markets, and a material declaration has to be correct and legally clean in each one. This is the moment where product data management and marketing touch, because a bad translation of a care instruction is not only ugly, it can get expensive.
What that list leaves out is time. A collection is photographed, described and signed off long before it goes on sale, and entries still change during that window. Product data management therefore has to hold a sequence rather than a state, and it has to be clear from which point an entry is binding. Where that is missing, several departments work simultaneously from different versions and only notice once something is out in the world.
Where it fails in practice
The most common failure is that nobody is responsible and everybody is a little. Buying maintains the master data, e-commerce adds the copy, marketing corrects whatever it notices. Everyone does something, nobody decides. Product data management without one person who owns the end of it becomes a permanent building site with rotating workers.
The second failure is maintaining fields nobody uses. I have seen systems with more than a hundred attributes, a third of which were never played out anywhere. That costs working time and creates the impression everything is captured while the important fields sit empty. Fewer fields, filled reliably, is better in every situation.
The third failure is believing automation repairs bad data. It does the opposite. A wrongly set attribute gets carried into every channel by marketing automation, and because it is equally wrong everywhere it suddenly looks right. The same holds for generative tools that build descriptions out of existing entries.
What I would do differently
First I would settle which system holds the truth, and write that decision down. Not as a concept paper but as one sentence anybody on the team can repeat. Product data management starts with that, and everything that happens before it in terms of tool selection is premature.
Second I would cut the number of mandatory fields hard and make the rest optional. A short, completely filled set of entries is worth more than a long one that is half empty. You can always add later, and adding is easier once the base is solid.
Third I would couple product data management to the content supply chain instead of running it beside. The two belong together anyway: without clean entries no content can be derived automatically, and without a production line the best data is useless because nobody calls it up.
And fourth I would accept that this work never becomes visible. Good product data management is noticed by no one, bad product data management is noticed by everyone. That makes it hard to fund, and it is the reason I am writing it down here. Anyone clearing out the martech stack and skipping this layer is only clearing the surface.