Nobody did. That’s exactly the problem.
A product manager would love one place where product data is always correct, always current, and always ready to go wherever it is needed. In practice, they have built something that approximates that, out of exports, reformatting, and a copy-paste routine they could do in their sleep.
No one designed this process. No executive approved it. It emerged slowly, one workaround at a time, until it became invisible background noise that everyone accepts as the cost of doing business with a large catalog and multiple sales channels.
How it starts
It always begins reasonably. A small catalog, one or two channels, a person who figured out a clever shortcut. Export the data here, clean it up there, and paste it where it needs to go. Fast, flexible, completely under control. For a while, it works.
Then the catalog grows. New product lines arrive. A second marketplace gets added, then a third. The company expands into new markets, and suddenly the same product needs descriptions in four languages. Each new requirement adds another column to the spreadsheet, another tab, another person who gets CC’d on the file. The shortcut that made sense for 200 SKUs quietly becomes the official process for 20,000.
The workaround becomes the workflow. The workflow becomes the system. The system becomes something nobody remembers questioning.
At some point, the spreadsheet gets a name. Then a version number. Then someone creates a “do not edit” tab and sends a company-wide email about it. By then, it is too late to call it a workaround. It has become infrastructure.
Where it breaks
The damage is rarely dramatic. There is no single moment where everything collapses. Instead, it accumulates in ways that are easy to dismiss individually and devastating in aggregate.
A product dimension gets updated in the ERP, but the person responsible for updating the spreadsheet is on leave, so the old measurement stays live on the website for three weeks. Returns start coming in slightly above normal, but not enough to trigger an alert. A product description written for the European market gets pasted into the US catalog because it was faster than writing a new one, and nobody notices until a customer complaint surfaces six months later. A new product launches on time, but with three different names across three different channels, because each team pulled from a slightly different version of the file.
None of these failures makes the news. They just quietly erode margin, customer trust, and team morale, while everyone is too busy maintaining the spreadsheet to address the system that makes the spreadsheet necessary.
There is also a quieter risk that rarely gets discussed: institutional dependency on individuals. In most companies running on copy-paste workflows, there is one person, sometimes two, who truly understands the full picture. They know which tab overrides which, which column maps to which field in which system, which rule was added in 2021, and why. When that person leaves, they take the logic with them. What remains is a file nobody fully trusts and a process nobody can fully explain.
€Why does the ERP not solve this
A common response at this point is to suggest that the ERP should handle it. After all, the ERP already holds the product data. Why not just use it as the single source of truth?
The answer is that ERPs are built for a fundamentally different job. They are designed to manage transactions: stock levels, purchase orders, pricing, and logistics. They are optimized for accuracy and auditability in an operational context. They are not designed for product data enrichment: the work of layering rich marketing descriptions onto raw records, managing content across multiple languages, enforcing channel-specific formatting rules, and distributing product information in the formats each sales channel requires. Asking an ERP to do that is like asking an accountant to write the product packaging copy. The data is there, but the tool was never meant to do anything meaningful with it.
What’s missing is a dedicated layer between the back office and the customer-facing world. A place where product data is not just stored but enriched, validated, structured for different audiences, and distributed to every channel that needs it. reliably, consistently, and without a human manually ferrying it across systems.
This is what the category of software called Product Information Management (PIM) was built to address. Not as a replacement for the ERP, but as the layer the ERP was never designed to be.
What a real product data workflow looks like
When product data has a proper home, the dynamic shifts in ways that are hard to appreciate until you have experienced the alternative. There is one place where a product record is created and owned. Attributes are defined once and applied consistently. When a product specification changes, it changes in one place and propagates everywhere. When a new sales channel is added, it receives structured, validated data, not whatever happened to be in the clipboard that afternoon.
Teams that previously spent their days maintaining spreadsheets shift to managing content: writing better descriptions, improving translations, and building out richer attribute sets that help customers make decisions. The operational burden shrinks. The quality goes up. And the company’s ability to move quickly, to launch new products, enter new markets, and add channels, stops being constrained by the bandwidth of the people doing the copy-pasting.
It also changes accountability. When data has a home, it has an owner. When it has an owner, errors get caught before they propagate. The question “which version is correct” stops being a daily negotiation and starts having an actual answer.
Choosing the right approach
PIM solutions vary considerably in scope, architecture, and fit. Some are built for specific industries, others for a particular scale of operation. Some are cloud-only; others offer deployment flexibility for companies with specific infrastructure or compliance requirements. Some lock you into a vendor ecosystem; others are built on open standards and give you full control over your data and your setup.
For companies with complex catalogs, multiple channels, and specific integration requirements, the configurability of the platform matters as much as the feature list. A system that cannot be adapted to your product structure or connected cleanly to your existing ERP and e-commerce stack will create a different kind of bottleneck, just further upstream.
One option worth knowing about is AtroPIM, an open-source PIM platform built for mid-sized and large companies with complex product data needs. Because it is open source, you own your data and your setup. It supports both on-premises and SaaS deployments, integrates well with popular ERP and e-commerce solutions, and is built on a flexible data platform that makes it significantly more adaptable than most traditional PIM tools. For teams that need to start with core functionality and expand over time, its modular architecture means you are not paying for what you do not yet need and are not constrained as your needs grow.
That said, the right tool is the one that fits your product complexity, your team’s workflow, and your integration landscape. The category has matured enough that there are solid options at different price points and deployment models. The more important shift is recognizing that the choice needs to be made at all.
Back to the product manager
The product manager with the spreadsheet is not doing anything wrong. They are solving a real problem with the tools available to them. The copy-pasting gets the job done, more or less, most of the time. That is precisely why it persists.
But “more or less, most of the time” is a fragile foundation for a product catalog that is supposed to represent your company accurately across every market, channel, and customer touchpoint. At some point, the catalog grows past what any spreadsheet can reliably hold, and the workaround starts costing more than it saves in errors, in time, in the quiet exhaustion of people who deserve better tools.
Nobody decided copy-pasting was a product data strategy. It just became one, incrementally, while everyone was too busy to notice. Noticing it is the first step toward something better.
