Episode 10: Do You Actually Need a PIM?

The minute a new head of ecommerce arrives, or a new board takes a look at the digital roadmap, the same line appears. We need a PIM.

Sometimes that is right. A PIM does several things genuinely well, and for a certain kind of business the return is easy to articulate.

But we have had this conversation with hundreds of businesses now, and the pattern is consistent. Most teams going to market for a PIM cannot say what problem they are buying it to solve. They know the data is bad. They have assumed the system will make it good.

It will not. A PIM stores and distributes product data. That is more or less the whole job.

The two myths

Two beliefs do most of the damage.

The first is that a PIM will fix the mess your suppliers send you. In most cases it will not. Nothing about installing a PIM changes what arrives in the new line form.

The second is that a PIM will enrich your product data. Write the descriptions. Source the attributes. Fill the missing specs. Generate the SEO copy. Most of the time it does none of that.

Enrichment appears constantly in PIM sales and marketing, which is where the confusion starts. What you are buying is a place to enrich data. Not the enrichment itself. That distinction looks small in a demo and looks enormous six months later.

There is a third assumption sitting underneath both. A PIM takes it as given that your taxonomy, your SKU structure and your attribute model are already defined. It does not give you the tools to define them.

A PIM is a filing cabinet, not a content team. It does not do the work. It stores the work.

What a PIM is genuinely good at

It is worth being fair about this, because a PIM does several things properly.

It stores product data in a structured central place, which gives you a single version of the truth. At its simplest it is a very glorified product database with a decent interface on top, and that has real value.

It distributes. Website, marketplaces, print, trading partners. PIMs are well designed for downstream syndication and sharing, and this is where the strongest business cases usually sit.

It handles product record versioning, localised content and channel specific variants. And it governs, by enforcing a structure and a product data model: required fields, attributes, standards. Some carry business process workflows as well.

As a master source, a governance layer and a distribution tool, it works well.

That is also why it lands most cleanly with brands and manufacturers. They have a syndication problem by definition, preparing channel content for downstream partners across many channels, usually with PDF and data sheet creation and compliance storage alongside it. Looking back at the large PIM projects we have run over the past year, effectively all of them were brands or manufacturers.

The two problems it will not touch

For retailers and distributors the picture is different, because there are almost always two problems and a PIM addresses neither.

The first is intake. Suppliers send incomplete, badly formatted data as part of new product introduction, and a team of people re-key spreadsheets to make it usable. Or fail to. What fixes that is supplier onboarding discipline, templates and validation at the point the data arrives. A PIM sits downstream of all of it.

The second is enrichment. You have the basic data, but not the descriptions, the attributes, the imagery, the SEO copy, the commonality in filtering, the taxonomy schema. Fixing that needs writers, content workflows and AI assisted tooling. A PIM gives you somewhere to put the output.

It is worth being precise about the AI point, because every PIM has now integrated generative AI to write descriptions. That part is easy, and they all jumped on it at once. Attribute enrichment at scale, translation, normalising supplier data, onboarding: there is far less there than the marketing suggests.

A real example

The clearest version of this we have seen recently was a large catalogue retailer with around 100 suppliers.

They had been looking at solutions for about three months. Several demos, a couple of PIM vendors, multiple rounds. At the end of it they still could not articulate what the PIM was actually going to do for them.

That was not a failure of the demos. The problems they were trying to solve were not PIM problems. Supplier onboarding, taking structured and unstructured sources and making them usable. Content generation for the ecommerce channel. Enrichment and extraction to fill gaps. Translation. Image generation and editing.

Every one of those is an onboarding or an enrichment problem. Not one of them is storage or distribution.

They were three months into evaluating the wrong category of software. It costs real money well before anybody signs anything.

Where does your pain actually sit?

One question settles this, and it is worth answering honestly before you take another demo. Look at your end to end product data process and work out where the pain really is. Is it getting the data in? Making the data good? Getting the data out? Or storing it?

If the pain is storing and distributing, you have a PIM business case. Many channels, several languages or regions, and manual localisation and channel work that is overwhelming the team through sheer volume. That is what the tool was built for.

If the pain is getting data in and making it good, a PIM is not your answer. Or not your first one. Buy it now and you end up with an expensive data store and no budget left for the onboarding and enrichment work that actually needed doing. We work with businesses trying to fix exactly that, retrospectively.

Most businesses land on a combination. Brands and manufacturers usually end up with a PIM plus syndication, or a PIM with syndication built in. Retailers and distributors usually need a PIM plus onboarding and enrichment tooling, with syndication on top if they are pushing to marketplaces.

The PIM itself may not need to be the expensive one. If the heavy lifting is happening upstream, a lean PIM or a lean structured database can be enough. Work out the parts of the process first, then apply tools to each part, rather than buying the platform and reverse engineering the process around it.

The takeaway

A PIM is the right call under three conditions.

Your intake is already disciplined, so suppliers send content you can use, in the format you need, ready to publish. You are distributing across enough channels, languages and regions that the manual cost is genuinely hurting the team. And you have the people and the process maturity to maintain the data once it is in there.

Read those back and the pattern is hard to miss. A PIM is a tool for businesses that already have their act together on onboarding and enrichment. It rewards maturity. It does not create it.

If that is not you, the answer sits further upstream, or in the messy middle where enrichment lives. Fix it there first. The PIM will still be available later, and it will cost you less when you do buy it, because you will know exactly what you are asking it to do.

Listen to the full episode

Episode 10 of Product Data Weekly is available now. For more episodes and the weekly newsletter on operational issues inside product data and ecommerce teams, visit productdataweekly.com.