Your price book has grown past the point where anyone in the building can recite it. The planner builds the schedule around changeovers nobody chose. Sales asks for one more variant every quarter and usually gets it, because saying yes takes an email and saying no takes a meeting. And at the last operations review somebody finally asked the question out loud, how many SKUs is too many, and the room went quiet because nobody had a number.
Nobody had a number because there is no number. That is not a dodge. It is the first useful thing to know about this question, and it is why the benchmark you were hoping to find does not exist in any form worth trusting.
Short answer: too many SKUs is a condition, not a count. You have too many when low-volume products consume constrained capacity that your highest-contribution products need: changeovers on the bottleneck, planner attention, engineering time, and working capital. You can have too few at the same moment, when a missing configuration at a key price point pushes customers onto a product that loses money. The five tests below tell you which situation you are in.
If you already know the answer is too many and want the method for cutting, the full sequence is in how to cut a product line without losing revenue. This article is the step before that one: deciding whether the count is actually your problem.
Why isn’t there a right number of SKUs?
Because two plants with the same count can carry completely different burdens. Picture one plant with four hundred SKUs that differ mostly in the label and the carton, running on dedicated lines in long campaigns. Picture another with four hundred SKUs that each need their own tooling, their own material, and their own changeover on a single shared machine. The count is identical. One plant barely notices its catalog and the other is being strangled by it.
Any benchmark that quotes SKUs per million dollars of revenue is averaging those two plants together and handing you the average. That is worse than no benchmark at all, because it gives the plant with the real problem permission to ignore it and sends the plant without one hunting for cuts it does not need.
What actually varies is load: how much shared, scarce capacity each additional SKU draws on. A SKU that differs from its neighbor only in what is printed on the box costs almost nothing to carry. A SKU that needs its own setup, its own raw material, and its own line in the forecast costs a great deal. Your ERP reports both of them as one row.
For a brand that won back its premium by cutting distribution, see my podcast episode the Angela Ahrendts Burberry turnaround audit.
Where does the tail actually take from you?
From four places, and none of them is the tail’s own line on the P&L. That is why the tail rarely looks expensive. Its costs land in overhead and in the performance of other products.
The first is bottleneck time. Every changeover on your constrained machine for a product that sells a few times a year is time that machine did not spend making the products that fill your trucks. The second is people: planners, buyers, and schedulers whose attention is a fixed quantity, spread across every active SKU whether it sells or not. The third is engineering. Drawings, bills of material, compliance documents, and change orders have to be maintained for every SKU that is still live, and the rarely sold ones generate that work at the same rate as the bestsellers. The fourth is cash, tied up in raw material and finished goods for products that turn slowly.
Put together, the mechanism is simple. The cost of a tail SKU rarely shows up on its own line. It shows up as a late order on the product that pays your bills.
How do you tell whether you have too many?
Run five tests, in order, against one product line at a time rather than the whole company. Each one is a branch: a yes gives you a finding for that line, and a no sends you to the next test.
- Check the bottleneck schedule for tail changeovers. Pull the last four weeks of the schedule for your constrained machine or cell and mark every changeover made for a SKU in the bottom fifth by volume. If you would not accept that share of bottleneck hours going to scrap, do not accept it going to setups for products almost nobody buys. A yes here means too many on this line, and you can stop testing it.
- Check what got expedited. List every order expedited or shipped late last quarter. If top-volume SKUs appear on that list in weeks when tail SKUs shipped on time, the tail is taking priority it has not earned. That is too many, expressed as service rather than as cost.
- Ask the planner to name the tail. Ask whoever plans the line to name, from memory, the ten slowest SKUs and when each one last ran. If they cannot, the tail is invisible, which means nobody is making decisions about it, and an undecided tail only grows.
- Compare the engineering queues. Count open change orders, drawing revisions, and document updates by SKU. If a disproportionate share sits on products that rarely sell, your engineers are maintaining the past instead of improving the products that pay.
- Look for the missing configuration. Find the price points where customers are buying a product that loses money, or buying up to a configuration they do not want, because nothing else is offered. If you find one, you have too few at that point, whatever the total count says.
Five no answers means the count is not your problem. Cutting SKUs in that business produces a shorter catalog and nothing else, and the margin or service issue that started the conversation is sitting somewhere else, usually in price or in customer mix. If you have never counted your constraint yourself, which the first test depends on, the method is in the two-week plant diagnostic.
Can you have too many and too few at the same time?
Yes, and it is more common than either condition alone. A line can be bloated with configurations nobody needs while missing the one configuration a large group of buyers is looking for.
I ran into exactly this at Whirlpool, in side-by-side refrigeration, a category that was losing $175 million a year. Industry orthodoxy said a side-by-side refrigerator without a water and ice dispenser in the door would never sell, because everyone knew customers wanted one. A quality refrigerator without a dispenser, at a lower price, went onto the floor at every major retailer at $899, and customers bought it.
That was a SKU added, not cut, in a category whose problem everybody assumed was too much product. A count would never have found it. The fifth test would have, because the question it asks is not how many products you carry but whether a buyer at a specific price point can find the one they came for.
Should you use an industry benchmark for SKU count?
No, not as a decision tool. A benchmark that says your count is normal does not mean your bottleneck is free, and one that says your count is high does not tell you which SKUs are causing the damage. Both answers leave the actual work undone.
If someone above you insists on a comparison, compare load instead of count: the share of bottleneck hours spent on changeovers, the share of late orders that land on your top products, and the share of engineering work sitting on rarely sold items. Those three numbers describe your plant. A SKU count describes your catalog.
What should you do if the answer is too many?
Do not start by cutting from the bottom of a volume ranking. The SKUs at the bottom of that list may be exactly the ones your best customers need in order to keep buying everything else, and cutting them removes revenue you never meant to touch. Before anything is cut, find out who buys each candidate.
The cost of a tail SKU rarely shows up on its own line. It shows up as a late order on the product that pays your bills.
Then remember that cutting is only one of the moves available. You can price a tail SKU up until it pays for the capacity it uses. You can take it off the bottleneck and make it to order with an agreed lead time and a minimum quantity. You can consolidate several variants onto one common base and differentiate them later in the process. Each of those removes load without removing a product, and each is easier to get agreed than a cut.
What should you do if the answer is too few?
Test the missing configuration small. One SKU, one price point, a defined period, and a clear measure: does it pull buyers off the product that was losing money, and does it bring in buyers you were not reaching? If it does, it has earned a place. If it does not, retire it on schedule, which is a discipline worth practicing on a product you launched yourself.
Resist the temptation to fill every gap you find. The test that exposed one missing configuration will expose several, and adding all of them rebuilds the problem you just diagnosed. Add the one with the clearest evidence behind it and let the result decide the next one.
So how many SKUs is too many? Enough that the tail is spending capacity your best products need, and that is a test you can run on your own plant this week rather than a number you can look up.
About the Stagnation Assassin
Todd Hagopian is a Fortune 500 transformation executive who has generated $3B in shareholder value across Berkshire Hathaway, Illinois Tool Works, Whirlpool, and JBT Marel, where he serves as Global VP of Product Strategy and Marketing. Known as The Stagnation Assassin, he is the author of two published books: The Unfair Advantage: Weaponizing the Hypomanic Toolbox and Stagnation Assassin: The Anti-Consultant Manifesto. His blog is published in 15+ languages and read by operators worldwide. Bring him to your stage via his speaking page or connect with him on LinkedIn.
If the five tests came back mixed, the product line may not be where the problem starts. Request free Stagnation Genome scoring for your business and I will tell you whether the SKU sprawl is the cause or a symptom of something upstream.
See also: What a SKU Actually Costs You, How to Identify Which SKUs to Kill