Author
TL;DR: A sprawling SKU catalog is the pricebook recording the packaging decisions the deal desk made one negotiation at a time, while nobody decided the packaging model as a whole. Collapsing it is a re-derivation of the packaging model from Customer Groups rather than a deletion exercise. The number of SKUs is an output of that derivation.
A Legacy SKU Catalog Before the Collapse
Collapsing a legacy SKU catalog starts with recognizing what the catalog is. A software company that sells four or five products in practice can still carry hundreds of product codes in its pricebook. The codes are real. The product behind most of them is not a discrete offer anyone designed.
A SKU is the construct in the pricebook that represents what is being purchased. It carries a list price, a value metric the price attaches to, and a volume schedule. That is the complete definition. A SKU is where a packaging decision is written down, and a catalog nobody can explain is a packaging model nobody made.
The packaging model is upstream of the catalog. It is the decision about how capabilities group into offers. That decision covers which features sit inside an edition, which sit outside as add-ons, how many editions the company runs, and which Customer Groups each edition is built for. The packaging model’s design derives the SKU set as an output. When the packaging model was never made explicitly, the catalog grows by accumulation instead.
One pattern appears consistently across companies that have shipped for a decade or more: the catalog carries three generations of packaging at once. The original editions. The capabilities split out as add-ons to make quarters. An acquired product passed through on its own codes, with no decision recorded about whether pass-through was the design or the default. The deal desk quotes across all three as if they were one design, because the pricebook says they are.
A second pattern is packages built around the average configuration that no single customer bought. The codes exist for a customer who never did.
The ratio of codes to products shows where to look. Across our pattern library the bloated books run ten or twenty codes per product, and in the extreme cases fifty or more codes stand behind a single product. The ratio flags the problem and says nothing about the right count. Most of the excess had a reason when it was minted. Volume bands and configuration variants had been pressed into the code itself, because the entitlement and billing systems downstream could not express them any other way. The rest is sediment. Codes that duplicate other codes. Codes for retired products that nobody removed. Codes that bundled several items for one deal and then stayed in the book as if they were products.
What Is a SKU in Software, and Why Inventory Advice Does Not Transfer
The search results for “how many SKUs should a software company have” are almost entirely inventory-management content. That question deserves an answer, because the inventory definition imports assumptions that do not hold for a pricebook.
What a software SKU is
In software, a SKU is a pricebook record. It carries a price, a value metric, and whatever volume or discount schedule applies. There is no shelf, no carrying cost per additional unit held, no stockout, and no reorder point.
How a software SKU differs from an inventory SKU
In physical inventory, a SKU is a code attached to an item so a warehouse can count it. The advice built on that framing (keep codes between eight and twelve characters, rationalize on a calendar, avoid duplicates for accurate tracking) is correct for a warehouse and silent about a pricebook. A pricebook’s integrity problem is codes with no Customer Group behind them. Duplicate codes are the visible layer of that problem, and tracking accuracy is the least of what they cost.
Why inventory rationalization rules misfire on a pricebook
Inventory rationalization starts with the item count and asks which items to cut. A pricebook rationalization that starts with the code count is making the same move: editing the record without examining what wrote it. The record is a symptom with two causes. The packaging model that was never made explicit is one. The other is the systems downstream. Billing, contract management and license entitlement software carry limits of their own, so a volume band, a term, or a deployment right those systems could not hold became a product code instead. Cut the codes and leave either cause in place, and the book grows back.
Is Your SKU Count a Packaging Decision or a Pile of Deal Exceptions?
Inventory logic treats SKUs as shelf space; in software, each one encodes a licensing, packaging, and pricing choice. A short diagnostic shows whether your catalog reflects deliberate design or years of one-off quotes, and which decision to fix first.
How SKUs Multiply
The deal
A configuration a rep negotiated to close a quarter receives a product code so the order form and the billing system can carry it. The mechanism is the half-fit: a customer whose needs do not map cleanly to an existing edition receives an amendment, the amendment instantiates as a new SKU, and the pricebook grows an entry nobody designed. The amendment stays. Nobody reverses it.
The quarter
Product management splits a capability out of an edition and sells it as an add-on to make a quarter’s number. The capability was part of the offer design; after the split it is a separate code with a separate price. The split is rarely reversed because reversing it means deciding who absorbs the revenue loss.
The acquisition
An acquired product passes through on its own codes, its own editions, and its own value metric. One company carries two pricebook architectures. We cover the meld-versus-pass-through decision for acquired products separately. Pass-through is the quiet default. It can be the right door; its catalog cost is two architectures the deal desk quotes as one. The other door, a meld, re-bases the acquired product on the acquirer’s value metric. A meld has to carry the product’s price position across at the value its own metric measured. Otherwise the collapse has re-priced the product rather than re-packaged it.
The channel and the motion
Partner-only codes, self-serve-only codes, regional codes: the same offer under several names because two teams quote from two pricebooks. The case for one pricebook across two motions is made separately. The catalog consequence is straightforward: one offer, multiple codes, no clean owner for consolidation.
The retirement nobody owns
Codes do not die because deleting one reads as risk and nobody is accountable for the catalog as a whole. Adding a SKU has an owner and a reason: the deal needed it, the quarter required it, the acquisition brought it. Retiring a SKU has neither. The asymmetry is structural. Until someone owns the catalog as a design artifact, the only direction the count moves is up.
So the catalog is cleaned the way an attic is. Nobody goes up there until the clutter has made the room awkward to use, and by then the job is monumental. Every code has to be traced to the customers still on it, the contracts that name it, and the systems that bill it. That timing is itself a symptom. A pricebook attended to only when a pricing project comes around is pricing run as an event rather than a continuous practice, and the collapse it eventually forces is the price of the years in between.
“How Many SKUs” Is the Wrong Question
The question asks for a number. There is no number to give.
Across our pattern library the question resolves on the customer base. A company selling to one homogeneous base prunes under competitive pressure and loses little by it. A company whose base splits into distinct Customer Groups with different willingness to pay can carry a lower offer even at thin margin, because it holds the entry point one group uses to arrive. The count follows the group structure. The number of SKUs is an output of how many distinct Customer Group decision boundaries the company serves, plus what sits outside the editions as add-ons because a distinct group buys it separately.
Peer-reviewed research on choice overload finds option count alone a weak predictor of buyer confusion. The confusion comes from the complexity of the set and from buyers’ uncertainty about their own preferences. Read that way, the choice overload research resolves to a comparability question rather than a safe edition count.
The 80/20 reframe makes the same error from a different direction. The inventory version: a small share of items produces most of the revenue, so prune the rest. Software breaks the second half of that. A low-revenue SKU can be the entry point a Customer Group uses to arrive, and its contribution is the expansion it leads to rather than the revenue it books this period. Removing it on revenue grounds removes the doorway. The mirror failure is just as real: a SKU can book revenue and still be the reason three deals a quarter stall in configuration. Revenue per SKU answers the wrong question in both directions.
One pattern from our library: an ERP vendor carried an integration that behaved like an application in its own right, and for one type of customer it was the doorway to the full system. On revenue it was indistinguishable from the rest of the integrations, so it was grouped with the low-volume ones and retired with them. The code was small. The Customer Group that landed through it and expanded from there lost its on-ramp, and the land-and-expand motion for that group stopped with it.
A Collapse Re-Derives the Catalog
Starting from the catalog and asking which codes to remove edits the record. The collapse starts from Customer Groups, derives the offers, and only then maps every legacy code onto the new set.
The derivation itself belongs to the packaging model, and the Customer Groups it starts from are covered in customer groups versus buyer personas. What happens to the legacy codes is the question here, and every one of them lands in one of three destinations.
It is an offer a Customer Group buys as described
A Customer Group buys exactly this configuration, at this scope, as a discrete offer. The code maps directly to a derived offer and carries forward under the new structure.
It folds into an edition where the capability belongs
The capability belongs inside an edition. It was split out for a quarter, or negotiated into a standalone code for one deal. The re-derivation puts it back where it belongs, and the code retires when the new offer is live.
It was never a product, only a pricing exception with a code
It was a discount or an exception that had been given a product code. That belongs to the pricing model rather than to packaging. Pricebook deviation is the downstream signal: when the price on the code and the price on the closed deal diverge routinely, the code was doing pricing work it should not have been doing.
Every legacy SKU goes to one of the three. Mapping the whole catalog, code by code, is where the time goes, and an acquired product’s codes run the same map with one extra test. When one of them folds into an edition, the price that edition carries has to reflect what the product earned on its own. When a fold lowers the product’s realized price, it is a pricing decision presented as a packaging change, and the pricing model owns it rather than the collapse.
Starting from cost take-out (remove the tail, release overhead) is the same wrong starting point in different words. It still edits the record. The design is upstream.
Centralized product catalog tooling holds a real benefit: a well-stored catalog is easier to audit than a distributed one. A well-stored bad catalog is still a bad catalog. The design is upstream of the tool, and no billing platform changes what the SKUs represent.
What the Legacy Base Sees
Retiring a code does not retire a contract. Customers on retired SKUs hold entitlements, and the collapse is incomplete until every legacy entitlement has a home in the new packaging. Whatever the catalog count says, the work is finished when that mapping is.
The new offer set must be able to express every capability combination a legacy customer holds. Where it cannot, the collapse has a gap. How to move the installed base is covered in transitioning existing customers to new pricing.
The Tests to Run on Your Own Pricebook
No scoring rubric. No thresholds. These are the questions a company needs to be able to answer before the catalog is governed:
- Can you say, for each product code, which Customer Group buys it and why that group and not another?
- How many of your SKUs exist because a deal needed them, and how many because a group did?
- If two customers hold different codes for the same capability, what decision separated them, and who made it?
- Which codes would a new rep quote without asking, and which ones exist so that someone does not have to ask?
- Does retiring a code have an owner in your company the way adding one does?
If the fifth question has no answer, the retirement asymmetry described above is still live in your catalog. The count will keep moving in one direction.
A pricing expert can run these questions against your actual pricebook and map where the codes land before a collapse begins.
The catalog records every packaging call the deal desk, the quarter and the acquisitions made, with nobody deciding the model as a whole. Re-deriving the packaging model from Customer Groups is how the record changes, and the count is an output of that work.
