What MDM/PIM solves, and what it doesn't

MDM (Master Data Management) is the discipline of maintaining a single, trusted source of truth for a business’s core entities: customers, products, vendors, locations. PIM (Product Information Management) is its product-data subset: attributes, categorizations, media, translations, and channel-specific overrides, published consistently across many destinations.

There are few software categories more confidently misunderstood than these two. Buyers conflate them with CRM, ERP, DAM, content management, and “the database where everything lives.” Vendors are happy with the confusion because it widens the surface they can sell into. Engineers inherit a system that’s been bought for the wrong reason.

This is a working reading of what these systems actually do and, more usefully, what they don’t.

What MDM/PIM actually solves

Single source of truth for the data you keep contradicting yourself on. When the website says one thing, the catalog says another, and the sales team’s spreadsheet says a third, you have the problem these systems exist for. Not a database problem; a governance problem with a database underneath it.

Cross-channel publishing without copy-paste. Once the product data is structured, you publish to web, shop, marketplaces, PDF catalogs, and InDesign templates from the same source. The structure is what makes “the same product information in three places” stop being a synchronization nightmare.

Attribute discipline. A serious PIM forces you to decide what attributes mean, what their types are, what their values are allowed to be. That sounds like overhead until you’ve watched a team try to filter products by weight and discover the field contains “1.2 kg”, “1200g”, “approx. 1.2”, and empty strings, all in the same column.

Run an export through the Product Data Check before any PIM decision: a scored report on completeness, content quality, and consistency shows how far the catalog is from attribute discipline today.

Translations and channel variants as first-class data. German vs. English product copy, B2B vs. B2C pricing, marketplace-specific title length limits. PIMs treat these as data, not as exceptions bolted onto the side.

What MDM/PIM doesn’t solve

It doesn’t replace your CRM or ERP. PIMs hold product information, not orders, not customers, not financial transactions. Buyers sometimes expect “the central database” to absorb adjacent systems. It doesn’t, and trying to make it doesn’t end well.

Connecting CRM and ERP is its own engineering problem; the cost behind a CRM/ERP integration button maps that layer.

It doesn’t fix bad processes. If three departments edit product data without coordination, putting a PIM in the middle just centralizes the chaos. The system enforces structure once you’ve agreed on it. It won’t manufacture the agreement.

It doesn’t clean your data for you. PIM rollouts that assume the data migration will be straightforward are the ones that run long. The legacy data is going to be inconsistent in ways the new schema doesn’t accommodate, and someone has to make the cleanup decisions.

The PIM migration checklist covers that layer end to end: inventory, mapping, idempotent imports, and post-cutover validation.

It’s not magic for catalogs that are actually small. A few hundred products, a single channel, and a stable team do not need a PIM. A spreadsheet with discipline beats a PIM with no discipline. Buying the platform doesn’t substitute for the discipline.

When you actually need one

A small number of products on a single channel does not need a PIM. Many products, many channels, and product content that changes faster than the team can keep up almost certainly do. Some practical thresholds we use when advising clients:

• Catalog size: past roughly a thousand SKUs, manual maintenance starts losing battles. The exact number depends on attribute count more than SKU count.
• Channel count: anything past two destinations for the same product data is where copy-paste hidden cost compounds.
• Team size: when more than two people edit product data regularly, the contradictions show up.
• Update frequency: a stable catalog that changes once a quarter doesn’t need a PIM. A catalog where prices, attributes, or media shift weekly does.

If none of these are true, the answer is usually “not yet” and the right work is structuring the spreadsheets and process you already have. If all of them are true, the answer is almost always “yes” and the right work is choosing the PIM carefully and budgeting heavily for the data migration.

The mistake we keep seeing

The most expensive mistake in this space is treating PIM as a software purchase. It isn’t. It’s a data project that requires software. The budget, timeline, and team skills needed for the software are a fraction of what’s needed for the data. Projects that get that ratio wrong tend to ship a working PIM with the wrong data in it.

FAQ

What is the difference between MDM and PIM? MDM is the discipline of keeping master data (customers, products, vendors, locations) consistent and authoritative across systems. PIM is the product-data subset aimed at publishing: attributes, media, translations, and channel overrides for the web shop, marketplaces, and print.

When does a business actually need a PIM? Roughly past a thousand SKUs, more than two destinations for the same product data, more than two people editing product data regularly, or a catalog that shifts weekly. Below those thresholds, a spreadsheet with discipline beats a PIM without any.

Does a PIM replace an ERP or CRM? No. A PIM holds product information, not orders, customers, or financial transactions. Buyers who expect “the central database” to absorb adjacent systems end up owning several disconnected ones.

Why do PIM rollouts fail? Because they are treated as software purchases. The budget, timeline, and skills needed for the software are a fraction of what the data work needs, and the data migration is where the project actually lives.

If you’re trying to figure out whether you actually need one, or if you’re staring at a PIM rollout and the data side is the part keeping you up, that’s the work we usually pick up.