Episode 15: Why Massive Retailers Still Run on Monstrous Spreadsheets

A conversation we had recently, about a genuinely large retailer. What does their tech stack look like?

A spreadsheet.

Not a spreadsheet alongside a system. One enormous spreadsheet running the product data operation for a business most people reading this would recognise, which any one person could break on a Tuesday afternoon.

The reflex is to be appalled. We would rather explain it, because businesses do not arrive here through incompetence. They arrive through four decisions, each of which made sense at the time, and none of which anybody has revisited since.

Buying a PIM does not remove the spreadsheets

Worth saying up front, because it complicates the obvious answer.

We speak to a lot of businesses that have implemented a PIM and still run enormous spreadsheets. Most of them, in fact. The work happens outside the system: export, transform in a sheet, import, repeat. Even projects sold explicitly as the end of spreadsheets tend to leave them in place, doing the parts the system never handled.

So the real question is not spreadsheet against system. It is why the spreadsheet keeps winning the jobs it is worst at.

1. It is the only tool everyone can use

Start with the least interesting reason, because it is the strongest one.

Everybody knows how to use a spreadsheet. There is no licence to buy, no training to run, no support ticket to raise when something does not work. It functions across departments without anybody agreeing to anything, which makes it the only tool in the business that fits the whole org chart.

Everyone already holds the Microsoft licences. Most businesses we work with have SharePoint folders full of sheets, sitting there, immediately accessible.

That accessibility is the entire appeal, and it comes with its own punchline. You open it and it is right there. You open it and it is badly out of date.

2. Spreadsheets survive because they are bad

This is the part that sounds like a joke and is not.

A spreadsheet is inherently poor at structure, schema and validation rules. Those are precisely the things that make product data a mess in the first place. That weakness is why people keep choosing it, because a tool which enforces nothing is a tool that never blocks you.

It does not reject entries. It does not make you pick a valid value. It never surfaces the problems, so nobody has to fix them. A real system would refuse the input and force a decision.

Being unvalidated and endlessly flexible also lets you handle every edge case round the side, which feels like agility right up to the point somebody has to reconcile it all.

One prospect sent us their exports recently. We had asked for a subset, around 100 SKUs. What arrived was 22 spreadsheets. Several existed purely to hold relationships: one sheet linking parent products to variants, another for linked products. All of them have to be loaded back into their systems to reassemble a single product record.

3. The cost is real, it is just buried in headcount

On paper the spreadsheet is free. No licence fee, no implementation cost, no integration bill.

What that comparison leaves out is the manual work feeding it. For the retailer we started with, that is something like ten people whose job is substantially this spreadsheet. The cost is not absent. It is sitting in payroll, where nobody thinks to look for it.

It stays invisible because manual work is offline by nature. There is no tracking, no systemised view of how the thing is actually used, and half the time the people doing it do not register it as work.

That is also only the version you know about. There is the official spreadsheet, and then there are the local copies people keep on their own machines. One client last year found their team held individual versions on individual desktops, which raises the obvious question of what happens when somebody leaves.

Think of it as an iceberg. You see the master sheet. Underneath sit the personal copies, the working files, and increasingly the ones living inside ChatGPT and Claude. On discovery calls we ask several people in the same business where the data lives and get several different answers.

This is shadow product data, and it persists for one reason. It never takes a line in the P&L.

4. Nobody can prove a system would fix it

One business we are talking to now has been evaluating PIMs for five years and still runs on spreadsheets. Not through inertia. They could never prove a PIM would actually solve their problem, and they were not willing to spend on faith.

Businesses tend to fail this in one of two directions.

Some buy on arrival. Somebody new joins, decides a system is obviously the right thing, and signs before anybody has mapped the existing process or quantified the gain. That is how you end up with an expensive tool wrapped around a workflow nobody understood.

Others stay risk averse and spend years unable to build the case. Their fear is a reasonable one: that they would replicate today's problems inside a more expensive database.

To be clear, there are businesses where a PIM genuinely fixes this. It brings governance, control and a single version of the truth, and it gets everyone's USB sticks into one place. The point is not that no case exists. It is that the case is unusually hard to prove.

We are a decade into the PIM market and businesses still struggle to build a solid business case for one. That says something. A lot of these systems get bought on a whim, or at the end of a sales cycle long enough to wear the buyer down.

Exposure tracks catalogue size, not company size

The risk here does not follow revenue. It follows the catalogue.

We worked with a manufacturer last year running around 2,000 SKUs, each carrying substantial technical data and assets. That is genuinely manageable in a sheet. You are still exposed, because one stray leading zero in the wrong field will break something downstream, but the margin for error is survivable.

A large catalogue is a different proposition. We have received enrichment files where somebody selected a cell and dragged it down the column, overwriting real values, on a sheet holding 50,000 products. That is the level at which this goes wrong, and it stays invisible until something downstream fails.

Then add free text where there should be controlled values. Everyone has lists of values, technically. Some run to 4,000 entries, which is not a controlled list. It is an accumulation of whatever anybody has ever typed, holding the same thing fifteen different ways.

Start with structure, not software

If you are reading this thinking your business is embarrassingly behind, the useful move is not to go shopping.

All of it reduces to governance, a word with a deservedly bad reputation. What it means here is narrow: locking down the structure, the validation rules, the attribute definitions, and who owns them.

A spreadsheet can do that. You can build sheets with structure and governance baked in, and for a lot of catalogues that is a sufficient answer on its own.

It is also what we do first with every prospect, whatever they think they are buying. We ask for a dump of all their product data and build a structure out of it. Until the attributes, the taxonomy and the definitions exist, there is no point looking for a system to replace anything, because you cannot brief a vendor on a model you have not written.

Do the model and the ownership first. Then decide whether a tool is a better place to hold the data and manage the workflow around it.

We do keep arriving at the same answer. Structure and schema, before anything else.

Listen to the full episode

Episode 15 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.