What a PIM is, and how to tell whether you need one yet

You changed a product description this morning. The size chart was wrong, so you fixed the wording.

Now: where else does that description live?

If the answer is "nowhere, I changed it in the one place it exists", you can stop reading. Genuinely. Everything below is about a problem you don't have yet, and there's nothing here worth paying for until you do.

If you had to stop and count, this is written for you.

The short version

A PIM, which stands for product information management, is one place to keep your product information. Every store, marketplace and feed reads it from there instead of keeping its own copy.

That's the whole idea.

The rest of this page covers the parts nobody tells you: when it stops being a nice-to-have, what one of these actually holds, what it costs, and what the first few months are really like.

The test everyone gives you is the wrong one

Search for this and you'll be told to get a PIM once your catalog passes some number of products. A hundred, usually. Sometimes a thousand.

The test is easy to apply, and it measures the wrong thing.

A seller with 12,000 products in one store has an easy job. Everything is in one place, one screen edits it, and nothing can disagree with anything else. Big catalog, simple catalog.

A seller with 80 products across a store, two marketplaces and a supplier feed has a hard job. Every description exists four times. Every price exists four times. Four copies of the truth, and nothing that makes them agree.

Count copies, not products. Take one sentence about one product, and ask how many places you have to change it before the change is finished. If the answer is one, you're fine. If it's more than one, you already have the problem, and the only question left is how you're handling it.

Right now you are handling it with files

Almost everybody starts the same way. You export a spreadsheet, edit it, and import it back. Or you keep a master spreadsheet and paste from it into each channel.

This works, and it works for longer than people expect. That's exactly why it's worth knowing what it does to your data while it's working.

The failure is quiet. Nothing crashes, the file imports successfully, and some of your data is now different from what you meant. Three mechanical reasons, none of them obvious.

An empty cell means two opposite things

You export forty columns and edit two. The other thirty-eight come back empty, and you very much want them left alone: the blank here means "I'm not telling you anything about this field, leave what is there."

Now the same file arrives every night from a supplier, and a price column is empty. This time the blank means the supplier no longer has that price, and leaving the old one in place would show stock you don't have.

Same file. Same blank cell. Two correct readings that contradict each other, and which one is right depends on context that isn't in the file anywhere.

In our own catalog system these are two different code paths, on purpose. The rule reads: an import is one-shot, so empty means no data; a vendor feed overwrites according to a policy you set per field.

Now look at whatever you use today and ask which rule it follows. Most tools pick one, stay consistent about it, and never tell you which. Some let you choose per import. At least one popular platform erases the value, and people usually learn this the first time a half-filled column blanks a field across the whole catalog.

Exporting and re-importing is not a neutral operation

The obvious workflow is export, edit, import. Nothing changed except your two cells.

Except the file came out of a system, so its column headers are that system's own field names. That sounds like a convenience, and it's where the trap is.

A column whose header matches an internal field name gets read as that field, whether you meant it or not. We hit exactly this ourselves, and the lesson is blunt: a canonical column header looks exactly like a field name, mapped or not.

So a round trip that looks like two edited cells can change a setting on every row, because every row carried a column you never looked at.

Inventory tracking is usually where it shows up first. It's a setting rather than a value, and nobody scans a spreadsheet looking at settings.

CSV files and spreadsheets do not agree on where the header is

This one is small and it wastes whole afternoons.

In a CSV file, the header is the first line with content in it, so blank leading lines get dropped before anything reads them. In an XLSX file, the header is physically row one, blank or not.

So a file with an empty first row reads correctly as a spreadsheet and mislabels every column as a CSV, or the other way around. We had to write the two rules separately in our own parser, one per format, because unifying them breaks one of the two silently.

None of this is your fault, and no amount of care with the file prevents it. It's a property of the formats.

What a PIM actually does about this

It removes the copies.

Not "syncs" them, which is the word everybody uses and which quietly means "keeps two copies and tries to make them match". Removes them. The description exists once, every channel reads that one place, and there's nothing left to reconcile because there's nothing left to disagree.

Everything else follows from that, and the feature lists you've read are mostly consequences rather than reasons. Bulk editing matters because you can now edit once. Completeness checks matter because there's one place where a field is either filled or it isn't. Channel formatting matters because the same product has to look different on Amazon than on your own store, and that's a formatting job once the data underneath is single.

If a PIM is doing its job, the change in your week is small and specific: the sentence "I need to remember to update that in the other places too" stops happening.

What one of these actually holds

Worth being concrete, because "product information" is doing a lot of work in that sentence.

The product itself. Name, description, brand, category, the identifiers a channel demands (barcode, manufacturer part number), cost and price, dimensions and weight for shipping. Roughly what you'd expect.

Attributes, which are the part that surprises people. Sleeve length belongs to shirts. Screen size belongs to monitors. Neither belongs to the other, and an attribute is simply a named property that belongs to a kind of product rather than to all of them. A store's built-in product form usually gives you one flat set of fields for everything you sell, which is why this comes up.

It matters more than it sounds. Channels ask for attributes by name and they ask for different ones per category, so if "material" is written into your description as prose, no channel can read it. If it's an attribute, any channel that wants it can be handed it.

Variants, and specifically the ones that don't exist. A shirt in three sizes and four colours suggests twelve variants. You might stock eleven, because XL only comes in black.

A lot of systems won't let you say that. They generate every combination and expect you to fill them all in, or to keep dead rows around forever. Our own model builds variants against the ones that already exist rather than regenerating the full grid, so a deliberate gap is a normal state and not a data error. If you sell clothing, you already know why this matters.

Images and files, linked to the product rather than uploaded per channel. This is where the two categories overlap: holding files well is digital asset management, and some PIMs include it.

Translations, in the tools that support them. Where a tool holds them properly, a second language is another value of the same field rather than a second copy of the product, which is the difference between fixing a typo once and fixing it once per language.

This is the widest gap between products in this category, so check it rather than assume it. Ours doesn't do it today. Our product content is single-language, and if you need the same catalog kept in two languages, that's a real reason to look at something else for now.

How the information reaches each channel

Most explanations skip this part, and it's where the value shows up.

Amazon has its own category tree and its own required fields. Your own store has themes and layout. A shopping feed wants a flat file with specific column names. Each one wants the same product described differently, so the product doesn't change, but the shape of the answer does.

A PIM therefore keeps one product plus one set of rules per destination for how that product should be expressed there. Which attribute maps to which of their fields. Which description goes out, since a marketplace listing and your own product page are rarely the same paragraph. Which images, in what order, at what size.

Channels genuinely disagree about images. One wants square, another rejects animation, another caps the file size, and those limits are real and all different.

The practical consequence is the one from before, seen from the other end. You change the product once and every destination gets the version it wants. Nobody re-types anything, and nothing drifts: not because everyone is disciplined, but because there was never a second copy to drift.

Three things people think are a PIM and are not

Worth knowing, because buying the wrong one is expensive and slow.

A feed manager is not a PIM. These take a catalog you already have and shape it for each destination, which is genuinely useful and is a different job. They assume your product data is already correct and lives in one place, and if it doesn't, a feed manager distributes the mess faster.

An ERP is not a PIM, even though many of them hold product records. An ERP is built around transactions: stock, orders, invoices, cost. It knows a product's number and what it costs. It's rarely built to hold forty marketing attributes, per-channel descriptions and a dozen images per product, and teams who try discover this a few months in.

A DAM is not a PIM either. Digital asset management holds files: images, video, documents. Some PIMs include one. If your problem is "which image is the current one", that's a DAM problem; if it's "which description is the current one", it isn't.

And none of them replace your store. A PIM doesn't sell anything and has no checkout. Your store, your marketplace accounts and your payment provider all stay exactly where they are. Only one thing changes: where the product text and images come from.

When you genuinely do not need one

Skip it, for now, if:

• –Everything lives in one place and always has. One store, edited in the store's own admin. There is no second copy, so there's nothing to keep in agreement.
• –Your catalog barely moves. Fifty products that change twice a year are fine with care and a calendar reminder, because the cost of a mistake is low and it happens rarely.
• –You're about to change platforms. Moving your store and adding a system on top of it is two migrations at once. Do one.
• –The work is annoying but not wrong. If updating three places is tedious and you still get it right every time, you're buying back time rather than preventing damage. That's a real reason, and it's a weaker one, so it should feel like a smaller decision.

The reason to move isn't that you crossed a product count. It's that you stopped trusting your own catalog: a listing went out with last season's price, a channel rejected a product for a field you were sure you'd filled, somebody asked which spreadsheet is the current one.

That loss of trust is the actual threshold, and people usually notice it about six months late.

What it costs, and what the cost is actually made of

Published prices in this category run from tens of dollars a month at the small end to tens of thousands a year at the enterprise end, and the gap is mostly not about features.

It's about who the buyer is. Enterprise pricing assumes a procurement process, a services team and a multi-month rollout, and it's priced for that whether or not you need it.

The number on the pricing page is rarely the whole cost either. Three other lines show up:

• –Implementation. At the enterprise end this routinely costs as much as the first year of licensing, and at the small end it's supposed to be zero. If a product needs paid onboarding to be usable, that's part of its price.
• –Data migration, priced by how messy your existing data is rather than by how much of it there is.
• –Your own time, which is the one nobody quotes and the one you'll actually spend.

Ours is the only pricing we can state as fact: the PIM starts free up to 500 products, and paid plans begin at $49 a month, flat, with no usage metering. That's a fraction of the enterprise end, and the honest reason is that we aren't built for the enterprise buyer, not that we've found a trick.

What to expect if you do move

Four honest notes, because the ones you'll read elsewhere are optimistic.

The first import is the work. Not the tool. Getting your existing data into a shape a system can hold means deciding what your attributes actually are, and most catalogs have been avoiding that decision for years. Expect it to surface disagreements about your own products. That's the value arriving, uncomfortably.

Audit before you import, not after. The expensive mistake here is loading everything and cleaning it up live, because you then spend months fixing data that customers are already reading. Look at a sample of what you have first, and fix the source. It's slow, and it's the part that pays for itself.

Plan for the migration taking longer than you think. Teams budget a couple of weeks and find themselves six weeks in. The extra time is almost never technical: it goes into deciding what your product model should be, which is the question the spreadsheet let you avoid.

You'll keep exporting things. A PIM doesn't end spreadsheets, and a supplier will send you a file next week regardless. The file stops being where the truth lives and becomes what it always should have been, which is a way to move data in and out.

One more, about people rather than data: this belongs to whoever runs the catalog, not to IT. The decisions that make it work are editorial ones, about what your attributes mean and which description is right, and a technical owner will build a working system that answers the wrong questions.

Questions that usually come next

We build one of these, so treat that as the interest it is. Our own PIM will still be there after you've decided. If what you took from this page is that your one store is fine and you should stop reading about PIMs for another year, that's a good outcome and it's the honest one.