Product catalogs don’t die in an accident. Nobody deletes them, nobody breaks them. They die quietly, one reasonable-sounding product at a time — until one day someone runs a revenue report, gets three different answers, and realizes nobody trusts the catalog anymore.
I’ve written before about one flavor of this problem: transient configuration state leaking into the catalog. Today I want to talk about the other flavor — the human one. The one-off SKU.
What catalog pollution is
Picture a rep closing a deal on the last day of the quarter. The customer wants your standard platform license, but with onboarding bundled in and billed monthly instead of annually. That exact combination doesn’t exist in the catalog.
So the rep — or an admin doing the rep a favor — creates a new product: Platform License - ACME Special. The deal closes. Everyone moves on.
That product is now a permanent citizen of your catalog. It will never be used again. It has no price book discipline behind it, no attribute model, no owner. And next quarter, there will be four more like it.
Catalog pollution is the accumulation of these deal-specific, single-use products inside an object that was designed to hold your stable, governed offering. Each one made sense at the time. Together, they turn your source of truth into a junk drawer.
Why it happens (and why blaming reps is lazy)
It’s tempting to frame this as a discipline problem. It isn’t. It’s a gap problem.
- The catalog is missing real variants. If customers keep asking for monthly billing on a product you only modeled annually, that’s demand data. The catalog just has no way to hear it.
- Reps are under deadline. A quarter-end deal will not wait three weeks for a product committee. The rep will find the fastest path, and the fastest path is a new SKU.
- There’s no middle ground. Most orgs offer exactly two options: use a catalog product as-is, or create a new one. Nothing in between.
Twenty years of teaching taught me that when many people keep making the same “mistake,” the mistake is usually in the system, not the people. Reps creating one-off products are telling you something true about your catalog. The problem is where they’re telling you — inside the catalog itself.
What it costs later
The cost of catalog pollution is almost invisible at creation time and painfully visible later.
Reporting stops meaning anything
“How much revenue did Platform License generate?” should be one query. In a polluted catalog it’s an archaeology project — the real product plus fourteen near-duplicates with slightly different names, some with prices baked in, some without. Product-level analytics quietly become fiction.
Pricing governance evaporates
A one-off SKU usually carries a one-off price, set by whoever created it, approved by nobody in particular. Every write-in product is a small hole in your pricing policy. Enough holes and there is no policy — just precedents reps can point at.
Migration becomes a nightmare
This is the cost people feel most sharply. When you move to RLM — or restructure your catalog, or launch a new pricing model — every record in the catalog has to be classified: keep, merge, or kill. A clean catalog of 300 products migrates in weeks. The same catalog plus 2,000 one-off SKUs means months of interviewing people who left the company two years ago about what Enterprise Bundle FINAL v2 (ACME) was for.
The honest trade-off
Here’s where I want to be careful, because the easy answer is wrong.
The easy answer is: lock it down. Remove the ability to create write-ins. Force everything through catalog governance.
I’ve watched orgs do this, and here’s what actually happens: deals slow down, reps escalate, and within two quarters someone senior forces an exception path — usually a worse one, like free-text quote lines with prices typed into a description field. The pollution doesn’t stop; it just moves somewhere you can’t even query.
The truth is that write-in freedom and catalog governance are both legitimate needs, and they genuinely pull against each other:
- Sales needs the freedom to shape a deal today, with the customer on the phone.
- The business needs a catalog it can trust for reporting, pricing, and the next migration.
Any solution that pretends one of these needs doesn’t exist will fail. The goal isn’t to eliminate the tension — it’s to give each need its own home.
Patterns that actually handle it
Three patterns, in increasing order of maturity. They work together.
1. Deal-scoped configurations
Give reps a place to define deal-specific products on the quote itself — scoped to that deal, living outside the catalog entirely. The rep gets full freedom: name it, describe it, attach it to the quote. The catalog never hears about it.
This is the structural fix. The one-off product still exists, because the deal genuinely needed it — but it exists as deal data, not catalog data. When you later report on the catalog, migrate it, or govern its pricing, the write-ins simply aren’t in the way.
2. Gap detection
Deal-scoped write-ins have a second job: they’re a sensor. Every write-in is a rep saying “the catalog couldn’t do this.” If you capture write-ins in a structured way, you can detect the gaps — which write-ins keep recurring, on which products, requested by which segments.
Instead of pollution, you get a prioritized backlog for your product team. That’s the difference between noise and signal, and it only works if write-ins live somewhere queryable instead of being smuggled into the catalog under creative names.
3. Promote-to-catalog when a write-in recurs
The final piece closes the loop. When gap detection shows the same write-in appearing for the third, fifth, tenth time — that’s not a one-off anymore. That’s a real product your catalog is missing. So you promote it: convert the recurring write-in into a proper, governed catalog product, with real pricing and a real owner.
The lifecycle becomes: write-in → detected gap → promoted product. Freedom at the front, governance at the end, and the catalog only ever receives products that have already proven their demand.
Where I stand on this
I’ll be transparent: this exact problem is why I’m building Configra — deal-specific configurations on the quote without touching the catalog, catalog-gap detection, and one-click conversion of a recurring write-in into a real RLM product. It exists because I kept seeing the same quiet death in org after org and the platform had no native middle ground.
But you don’t need my product to benefit from the thinking. Even a spreadsheet-level version of gap detection — a monthly review of “what did reps create this quarter and why” — will teach you more about your catalog’s blind spots than any amount of governance policy.
The lesson underneath is simple: a catalog stays clean when the pressure that pollutes it has somewhere else to go. Give the exceptions a home, listen to what they’re telling you, and promote the ones that earn it. That’s not just cleaner data. That’s your customers designing your catalog for you.