Catalogue debt: what it looks like when years of channel-chair operations compound across your SKU base

Software engineers have a term for this: technical debt. Shortcuts accumulate over time until the codebase becomes expensive to change. No individual decision was wrong. The system still runs. What is missing is the clean, maintainable architecture that could exist.

Catalogue debt is the product operations equivalent. Years of channel-chair operations (one person managing one channel end-to-end) produce a catalogue where the main channel is fully covered, secondary channels are partial, content diverges between channels, and attributes are populated to the minimum required. The products sold. The orders processed. The team kept up, more or less. What is missing is the catalogue state that could exist: every product fully attributed, consistently described across channels, present everywhere it should be.

That state represents revenue not earned. And it was never a failure. It was the output.

The channel-chair model organises product work by channel: one person or small team owns Amazon, another owns eBay, another the website. Each makes independent decisions about content, attributes, images, and which products to list. Over time, those independent decisions compound into divergence.

It is not that the channel manager made bad choices. They made reasonable ones, under time pressure, for their channel. The eBay catalogue at 10% of capacity was not a decision. It was what one person could manage while also handling listings, updates, and marketplace fires simultaneously. The content that differs from the website was not a mistake. It was written by someone who had not seen the website version because their tools did not show it to them.

When the team hits capacity, the intuitive response is to hire more channel people. That scales cost without fixing structure. The Amazon team grows, the eBay gap stays, and the catalogue diverges further with each hire.

The SKU naming pattern tells the same story. When workflow tools do not track ownership, teams improvise: SKU123 becomes SKU123-james, mapped back to SKU123 at the ERP. Creative, practical, and completely unscalable. It is a signature of people working next to each other rather than together.

The primary cost is calculable: average revenue per SKU per channel, multiplied by the number of SKUs absent from that channel. Run that number across your secondary channels. It is often larger than expected.

The second layer (thin optional attributes, weak descriptions) is harder to put a number on. Whether completing optional attributes moves revenue depends on the marketplace. On large platforms, historic conversion history drives visibility more than data completeness. The first cost is real and quantifiable; the second is directional.

There is a third cost that shows up operationally before the others: when the catalogue becomes opaque, the team can no longer see it clearly enough to work confidently inside it. Can you tell, right now, which of your products are not on your third-most-important channel? If the answer involves checking three different systems and asking a colleague, that is catalogue debt making itself felt.

There is no single threshold. A 400-SKU seasonal catalogue (clear start, clear end, one channel, one person) is manageable with discipline. The debt accumulates slowly and the team can see it.

The tipping point is complexity, not size. It arrives when multiple dimensions compound at once: more than one person in the product operations team, a constant flow of products (mix of long-lasting catalogue items and short-cycle seasonal drops), and new complexity added: a second language, a second domain, a new marketplace. Each dimension multiplies the divergence that was already accumulating. The team that could see the catalogue at 500 SKUs across two channels cannot see it at 8,000 SKUs across five.

At that point, the team is in permanent catch-up mode. Optimisation work (better descriptions, completed optional attributes, cross-channel consistency) never happens because there is no capacity for it. Adding a new channel means adding another person to manage it, which extends the drift rather than reducing it.

The symptom the team notices first is not a specific failure. It is that they cannot see the wood from the trees. They know products need deploying. They do not know which ones, where, in what priority. The catalogue has outgrown their ability to navigate it.

The full picture rarely becomes visible until everything is pulled into a PIM.

Before that, each channel person sees their channel. The divergence is invisible because no one has a cross-channel view. The eBay coverage gap only becomes visible when it sits next to the Amazon coverage and the website coverage in the same interface. The content differences only register as differences when the same product's descriptions appear in the same screen.

The PIM migration does not create catalogue debt. It reveals it.

The typical reaction is to dismiss it and keep walking forward. That is a rational response: stopping to clean the catalogue while the business needs new listings is not obviously the right choice. Over time, the operator who pays attention notices that the debt is not static. It is accumulating. The gap is growing, not closing. The team is not getting faster; it is getting more confused about where it is.

First, a clarification: the PIM is not the fix. Adopting a PIM while keeping the channel-chair workflow intact keeps the mess in place and often accelerates it. Products push to more channels faster, but the underlying divergence continues. The intervention is the workflow redesign, not the tool.

The cleanup and the restructure are two separate problems. They both need solving, but they do not have to be solved in sequence. For a small team with a manageable mess, running them together with discipline works. For larger teams or larger catalogues, separating the layers helps: restructure the workflow first so new data does not accumulate in the old pattern, then address the existing backlog systematically.

The goal of cleanup is not completion. Marketplace requirements change. Products keep flowing. There is always something to improve. The goal is manageability: making the debt visible in pieces that the team can actually work through. Dashboard exception cards (missing required attributes, untranslated fields, marketplace rejections) are more useful than a single cleanup project because they make the debt continuous and navigable rather than overwhelming and one-time.

The channel-chair model that generated the debt also needs to change. Not overnight, and not in a way that disrupts operations while the cleanup is happening. But the debt will return if the structural cause does not.