Product Information Management: Where The Truth About A Product Lives

Product information management is the least exciting problem in ecommerce and one of the most expensive to have unsolved. It is the question of where the truth about a product lives, given that a product is described in more places than anyone remembers.

The store. The Google Shopping feed. Amazon. The wholesale price list. The printed catalogue. The spreadsheet somebody in purchasing maintains. The supplier's PDF that started all of it.

Each of those is a copy. Copies drift. PIM is the discipline of having one authoritative version and treating everything else as a rendering of it.

How you know you have the problem

The symptoms are recognisable long before anyone uses the phrase.

A dimension is right on the website and wrong on Amazon. A product is discontinued in three places and live in the fourth. Somebody asks what the case pack is and two people give different answers from two systems. A new product takes a week to appear everywhere because it has to be entered by hand four times. Nobody can say when a description was last changed, or by whom, or why.

None of these are dramatic. They are a steady tax, and the tax grows with the catalog.

What a product record actually contains

People underestimate this, which is why spreadsheets survive longer than they should. A product has at least five different kinds of information and they behave differently.

Identity. SKU, barcode, manufacturer part number. Rarely changes, and everything else joins to it.

Descriptive content. Name, description, features, images, documents. Changes often, needs review, and may exist in several languages and several lengths, because a marketplace title has a character limit that your own product page does not.

Attributes. Dimensions, weight, material, colour, certifications, ingredients. Mostly factual, and different categories need entirely different sets. A t-shirt and a laptop have almost nothing in common as data.

Commercial. Price, cost, tax class, per-customer agreements. Frequently the ERP's territory rather than the PIM's.

Channel-specific. The Amazon category, the Google product type, the marketplace-specific title. This is the one people forget, and it is why a single description field is never enough. Each channel wants the same product described its own way.

The decision that matters more than the tool

Not which PIM. Which system is authoritative for which field.

It is almost never one system for everything. In most businesses the ERP owns cost and stock, the PIM owns descriptions and attributes, and the store owns nothing but displays all of it. That is a perfectly good arrangement, and it only works if it is written down.

Where it goes wrong is when two systems both believe they own a field. Then a sync runs, the last write wins, and somebody's correction gets silently reverted on Tuesday. The symptom is a value that keeps changing back, and the cause is always ownership rather than the sync being buggy.

Write the list. One row per field, one system named. It takes an afternoon and it prevents a category of problem that is otherwise permanent.

Variants are where the modelling gets real

A product with a colour and a size is not one thing with two labels. Some attributes belong to the product and some to the variant, and getting the split wrong is the most common modelling error in a catalog.

Brand, description and care instructions belong to the product. Barcode, weight, dimensions and stock belong to the variant, because a large one weighs more than a small one and they ship differently. Put weight on the product and every shipping quote for the large one is wrong in a direction that costs you money.

Test any system with your most awkward product rather than your simplest. A bundle, a made-to-order item, something sold by weight, something with a variant that has its own certification. Simple products work everywhere.

Do you need a dedicated PIM?

Honestly, most stores do not, and the vendors will not tell you that.

A dedicated PIM starts earning its cost at real scale: thousands of SKUs, several sales channels, more than one language, a workflow where different people write, review and approve product content, and suppliers sending data in formats you have to normalise.

Below that, a well-modelled catalog in the system you already run is sufficient, and a separate PIM adds a synchronisation problem in exchange for features you will not switch on. The question is not how many products you have. It is how many places you describe them and how many people touch the descriptions.

Where we fit, and where we do not

dashfordevs is not a PIM and does not claim to be. It is a commerce backend with a catalog that is properly modelled: custom attributes per product type, variants that carry their own identity, weight and dimensions, media on the record rather than in a folder somewhere, and all of it readable over the same API your storefront and your feeds use. For a lot of stores, that is the PIM you needed, because the store was the only place the product had to be right.

Where we are the wrong answer: if you have a content team with an editorial workflow, approvals and translations, a real PIM does that and we do not. If your product data starts in an ERP that owns it, the PIM question is really an integration question. And if you sell across five marketplaces with different taxonomies, a dedicated syndication tool exists for exactly that job.

The short version

Decide which system owns which field and write it down. Model variants so that anything physical lives on the variant. Then ask whether your product data has to be right in more than one place, because that is what decides whether you need a separate tool or a better catalog.

If you want to see how attributes and variants are modelled on our side, the docs have the product schema.