The standard method for SKU rationalization is the main reason SKU rationalizations lose revenue they were never supposed to touch.
You have probably seen the method, and you may have run it. Pull a year of sales by SKU, rank the list from top to bottom, draw a line where the cumulative total reaches eighty percent, and mark everything below the line for review. It is tidy, it fits on one slide, and it fails in a way that does not appear until the revenue report two quarters later.
These are field notes from doing this work in businesses as different as a refrigeration category at Whirlpool that was losing $175 million a year and a small industrial tank liner manufacturer I bought, ran, and later sold. The approach I settled on does not rank SKUs at all. It ranks the relationships between products and the customers who buy them, and that difference is most of what separates a rationalization that frees capacity from one that quietly loses accounts.
The ranking method, and why it feels right
The ranking method feels right because its arithmetic is real. In most product lines a minority of SKUs carries most of the volume, and the tail below the line genuinely is small in revenue terms. Cutting it looks like removing a large amount of complexity in exchange for very little money, which is exactly the trade any operator would want to make.
The flaw is in the unit. The ranking treats each SKU as an independent product with its own revenue, which will either survive or disappear on its own. Almost no industrial SKU behaves that way. It is bought alongside other products, by particular customers, for particular reasons, and its revenue is tangled up with theirs.
The ranking cannot see any of that, because a sales-by-SKU report has already thrown away the one column that matters: who bought it. Once that column is gone, a bracket bought only by your largest account looks identical to a bracket bought by nobody you would miss. Both sit near the bottom of the list, and both get marked for review.
There is a second, quieter problem with the ranking: it is usually built on revenue, and revenue is the wrong measure for a cut decision even on its own terms. A high-revenue SKU can lose money, and a low-revenue one can be among the most profitable things you sell per hour of capacity. Ranking on margin instead fixes that, and it leaves the unit problem untouched.
The tell, when a ranking-based cut goes wrong, is that the revenue lost afterward is larger than the revenue of the SKUs that were cut. That is not bad luck, and it is not the sales team failing to hold the accounts. It is the method working exactly as designed on an assumption that was false from the start.
Where does the revenue go when you cut a SKU?
It goes to one of three places: to a substitute you still sell, to a competitor, or out the door along with everything else that customer used to buy from you.
The ranking method assumes the first. Some of the revenue will indeed move to a close substitute, and for genuinely redundant variants most of it does. The second destination applies when your nearest remaining product is not close enough and a competitor’s is. That loss is real but bounded, since it is limited to the revenue of the SKU itself.
The third destination is the expensive one, and it is the one the ranking never models. Industrial buyers consolidate suppliers because every additional vendor costs them qualification, paperwork, and attention. A customer who buys forty items from you and loses one they depend on does not switch one item. They move the basket to a supplier who stocks all forty. The SKU’s own sales were small. Its exposure was the whole account.
The practical consequence is that the same cut can be harmless in one account and damaging in another. A variant bought by fifty small customers who each have alternatives will mostly move to a substitute. The identical variant bought by three large customers who use it to complete an assembly can take all three baskets with it.
A customer who buys forty items from you and loses one they depend on does not switch one item. They move the basket to a supplier who stocks all forty.
Estimating which of the three destinations each candidate’s revenue will reach is the single most important analytical step in a rationalization. It is also the step the standard method skips entirely, because a list of SKUs has no way of representing a basket.
A SKU has no economics of its own
A SKU’s profitability depends on who buys it, in what quantity, alongside what else, and on what terms. Strip those away and the question of whether a SKU is profitable usually has no answer.
Take the same part sold two ways. Shipped in full pallets to a distributor on standard terms, it earns a healthy margin. Shipped in ones and twos to a small account that orders irregularly, wants it expedited, and pays late, the same part loses money on every order. Your ERP averages those two streams into one margin figure that describes neither of them, and the ranking inherits the average.
The averaging problem gets worse as you go down the list, not better. High-volume SKUs are bought by many customers, so their average margin is at least a stable number. Tail SKUs are often bought by a handful of accounts, and their average can swing from profitable to unprofitable on the behavior of one customer. That makes them the SKUs where a product-level margin is least trustworthy and most decisive.
At the tank liner company, the analysis that changed what the business did was not which products made money. It was which customer and product combinations created value and which destroyed it, and the resources moved toward the combinations that created it. No product-level report would ever have shown that split, because the split did not run between products.
So replace the question. Instead of asking whether each SKU is profitable, ask which customer and product combinations make money and which lose it. That changes the work from ranking a list to building a grid, and the grid is where a rationalization either protects the business or damages it.
How do you see which products matter to which customers?
You build a grid with customers on one axis and products on the other, and you judge every cell rather than every row.
The method I use for this is the 80/20 Matrix of Profitability. Split your customers into the top 20 percent and the bottom 80 percent by profit contribution, split your products the same way, and cross the two. You get four quadrants. The one where top customers buy top products is, by simple arithmetic, only about 4 percent of the possible combinations, since 20 percent of customers times 20 percent of products is 4 percent. The premise of the method is that profit concentrates in that small cell far beyond its share, and that every rationalization decision should begin by asking what it does to that cell.
This is not a Pareto chart with a second axis bolted on for decoration. The whole point is that a product in the bottom 80 percent can sit in the same row as your best customers, and the moment it does, what you are allowed to do with it changes.
Build it roughly. You need a year of invoice lines with customer, product, quantity, and net price, plus the best cost figure you have for each product. Allocate the obvious customer-specific costs, freight, expedites, special packaging, and payment terms, where you can, and accept approximations everywhere else. A rough grid built in weeks will find the cells that matter. A perfect one scheduled for next year will not be built.
Expect the first version to surprise you in both directions. Some products you considered strategic will turn out to be bought mostly in the bottom-right quadrant, and some you considered tail will turn up in the top row. The surprises are the point of building it.
What to do with each quadrant
Each quadrant gets a different instruction, and only one of the four is a cut list.
Protect: top customers buying top products. Nothing in this cell is ever a source of cuts. It gets first claim on bottleneck capacity, the shortest lead times, and the safety stock. If a rationalization frees capacity, this is where the freed capacity goes, and saying so in advance is one of the better arguments you will have for the cuts elsewhere.
Keep, reprice, simplify: top customers buying bottom products. This is the cell a SKU ranking destroys, because these products look like tail and are bought by the accounts you can least afford to annoy. Keep most of them. Reprice the ones that cost far more to make than they earn. Move some to make-to-order with an agreed lead time, and engineer others onto a common base. Cut one only with the customer’s agreement and a named replacement.
Fix the terms: bottom customers buying top products. The product is fine. The terms are not. Minimum order quantities, standard pricing, standard freight, and standard payment terms fix most of what is wrong here, and none of it requires removing a SKU.
Cut candidates: bottom customers buying bottom products. This is the real cut list, and most of what sits here can be retired with a last-time buy and little risk. Before you finalize it, check the few customers in this cell who are growing, and check whether any of these products is the only thing keeping a promising account with you.
The cut list that comes out of this is shorter than the ranking’s by exactly the SKUs your best customers depend on. That is not a weakness of the method. It is the reason to use it.
The cost you are removing is larger than the ledger shows
The benefit side of a rationalization is almost always understated, because most of what a SKU costs is never charged to it.
Standard costing spreads overhead across products by volume or by labor hours. That charges your high-volume products for complexity the low-volume ones create, and it flatters the tail. Your costing system is quietly subsidizing the tail with the margin of the head, and it has been doing so for as long as the system has existed.
The costs that go missing are familiar once you list them: changeovers on shared equipment, safety stock and slow-moving inventory, raw material bought in small lots at worse prices, forecast error that grows as volume per SKU shrinks and demand gets noisier, drawings and bills of material and compliance documents that must be maintained for every live product, engineering change effort, quoting and price book upkeep, and the attention of every planner and buyer who has to think about the product at all.
You do not need a full activity-based costing project to see this. Take the most frequent changeovers on your constrained machine, note which SKUs triggered them, and compare those SKUs’ share of changeovers with their share of volume. The gap between the two figures is a rough measure of the subsidy, and it is usually enough to change the conversation.
None of that disappears the day you announce the cuts. It drains out as the inventory runs down and the changeovers stop, which is why the benefits of a rationalization show up in the months after it rather than in the week of the decision. Build the business case on that timing, or the savings will look late to the people who were expecting them immediately, and the next rationalization will be harder to approve.
Cutting is half the job
The lineup you leave behind matters more than the list you remove, because a rationalization with no architecture simply regrows.
In side-by-side refrigeration at Whirlpool, the product line was rationalized into a good, better, best structure as part of a new platform launch, with premium features migrated up into the higher tiers. That lineup supported pricing about $100 higher. It was one lever among several. There were two price increases, a deliberate retreat from unprofitable volume that took market share from 53 percent down to 29 percent on purpose, and new products aimed at specific gaps. Together they took a category losing $175 million a year to break-even over three and a half years.
What the tiers did for the product line was give every surviving SKU a job. Each tier had a reason to exist that a customer could say out loud, and each step up had a feature that justified its price. A product that could not be placed in a tier had no argument for surviving, which made the remaining cuts much easier to agree.
The architecture also changes the sales conversation. A salesperson with a clear good, better, best lineup has a reason to sell up the tiers. A salesperson with forty loosely related variants tends to sell whichever one closes fastest, and the tail grows back one special at a time.
So before you finalize the cut list, draft the lineup. Name the tiers, put every survivor in one of them, and look at what is left over. The leftovers are either cuts you missed or a gap in the architecture, and either finding is worth having before you talk to a single customer.
Can adding a SKU be part of rationalization?
Yes, and sometimes it is the most profitable move in the whole exercise.
One of those new products in the refrigeration category was a stainless-only model at a key price point. It eliminated the losses being taken on the white and black configurations carried at that price. Measured by count, that was one product added. Measured by what it did to the economics of that price point, it was a rationalization.
The mechanism is general. When a price point is carried in several variants and some of them lose money, a single well-chosen variant can concentrate the volume where the economics work, and the losing variants can then be retired without leaving the price point empty. You get the benefit of the cut without the gap that usually makes a cut hard to sell.
Adding has a failure mode worth naming. A new SKU introduced to fix a price point has to replace the variants it was meant to replace, on a date. If the old variants stay in the price book alongside it, you have added complexity and called it rationalization. Put the retirement date for the losing variants into the same decision as the launch.
The broader lesson is that the goal of a rationalization is not a smaller number. It is a line where every product has a job and no job goes unfilled. Sometimes that means fewer SKUs, sometimes it means different ones, and occasionally it means one more. Any method that can only subtract will miss the last two.
How do you estimate the revenue you will lose?
Estimate it customer by customer rather than SKU by SKU, and put a name next to every estimate.
For each product on the cut list, pull every customer who bought it in the last year straight from the grid. For each of those customers, decide which of the three destinations applies: they will move to a named substitute, they might move, or they will take the basket elsewhere. Then ask the person who owns each account to confirm or correct the call, in writing. Account managers are not always right, but they are closest to the answer, and a written call gives you someone to go back to when the result differs.
Sum the result the right way. The exposure is the full basket of every customer in the second and third groups, not the revenue of the SKUs being cut. That number is usually uncomfortable, and it is supposed to be. It tells you which cuts need a migration plan before they are announced and which ones should come off the list.
There is also a cheaper test that avoids most of the guessing. Price before you cut. Raise the price on a candidate to a level where it would pay for the capacity it consumes, and watch what happens. Customers who genuinely need the product will pay for it, and customers who do not will migrate themselves to the substitute you would have pointed them to anyway. Either outcome is useful, and neither one costs revenue you wanted to keep.
Price before you cut. Customers who genuinely need the product will pay for it, and customers who do not will migrate themselves.
Every SKU has an owner, and that is the real obstacle
The analysis rarely stalls a rationalization. The politics do.
Every SKU was added by somebody for a reason. An engineer solved a customer’s problem with it. A salesperson won an account on the promise of it. A customer asked for a special, got it, and bought it twice. Proposing to kill that SKU reads, to the person attached to it, as a verdict on a decision they made, and they will defend it with specifics nobody can rebut in the meeting.
That is why debating the list item by item almost guarantees that most items survive. Each one gets a defender with a story, and nobody at the table has an equally vivid story about the changeover hours the product consumes. The costs are diffuse and the defenses are personal, and personal wins.
It also helps to separate two conversations that get tangled in these meetings. One is whether the product is worth keeping today. The other is whether the person who introduced it made a good decision at the time. The second question almost always has a defensible answer, and saying so out loud makes the first one far easier to settle.
Change the process rather than the arguments. Agree the rules before anyone sees the list: the grid, the quadrant instructions, and the exposure estimate. Give one person decision rights over the final cut. Then set the default so that a product on the list is retired on a date unless someone defends it in writing, with a named customer and a number, before that date. The burden of proof moves from the person proposing the cut to the person proposing to keep the product, which is where it belonged all along.
How to retire a product without losing the customer
Tell the customers who matter first, personally, and with a replacement already named.
The sequence that protects accounts is simple and is skipped constantly. Contact every top-quadrant customer who buys the product before any general notice goes out, and bring the migration path with you: the substitute, the price, the lead time, and whatever qualification help they need. Then issue the general notice with a last-time-buy window that has a firm closing date and a firm quantity limit.
Build to the last-time-buy orders, not beyond them. The single most common way a rationalization loses its savings is a final production run sized for optimism, which leaves you holding exactly the slow-moving inventory the exercise was meant to eliminate.
Prepare the internal side as carefully as the external one. Customer service needs a script and the substitute’s details before the first call comes in, and whoever quotes new business needs to know the product is gone. A retirement that customers hear about from a confused service representative costs more goodwill than most retired products were worth.
Close the door behind the product on the same day. Remove it from the price book, the quoting tools, the website, and the configurator, or somebody will sell it again the following month and the SKU will be back with a new part number. Then watch the affected accounts for two quarters. A customer who has quietly started buying less of everything is telling you the migration did not work, and there is still time to fix it if you are looking.
Why product lines grow back
Product lines grow back because adding a SKU takes an email and removing one takes a meeting.
Every new variant arrives with a customer, a salesperson, and an urgent reason. Every retirement requires analysis, agreement, and someone willing to be blamed if the account complains. Left alone, that asymmetry produces a line that grows every year, which is the condition you just spent months reversing. Change that asymmetry or the tail returns within a few years.
The fix is governance at the entry point. Set criteria a new SKU must meet before it is released: a volume commitment, a price that covers the capacity it will consume, and a place in the tier structure. Put a review date on every special built for one customer, so it expires unless someone renews it with evidence. And refresh the customer and product grid once a year on a fixed date, so the next rationalization is a routine review rather than a project.
Some businesses use a one-in, one-out rule. It is crude, and it will occasionally block a good product, but it does something the other measures do not: it makes every addition carry the cost of a retirement decision, which is the conversation the business has been avoiding.
Whatever the rule, publish it and apply it to everyone, including the largest customer and the most senior salesperson. An entry rule with exceptions for the people who generate most of the requests is not a rule.
Product lines grow back because adding a SKU takes an email and removing one takes a meeting. Change that asymmetry or the tail returns.
How long does a SKU rationalization take?
The analysis takes weeks. The execution takes as long as your longest customer commitment.
A rough customer and product grid can be built from a year of invoice data in a few weeks, and precision is not what limits you. You do not need exact costs to find the bottom-right quadrant. You need them only for the borderline cases, and those can be worked through individually.
Execution is gated by things outside the analysis: contractual supply obligations, qualification timelines at customers who must approve a substitute, last-time-buy windows, and the time it takes to run down inventory. Phase the work by customer rather than by product, so that each account hears once, about everything that affects it, rather than receiving a series of notices over a year.
The benefits arrive on the same schedule as the execution. Changeover hours come back as the last runs finish, and inventory falls as the remaining stock sells through. Report progress on those two measures rather than on the number of SKUs retired, because the count is the easiest thing to move and the least connected to the reason you started.
Expect the middle of the project to feel slow. The analysis produces a clear list early, and then weeks pass while customers qualify substitutes and last-time-buy windows run. That lull is when a rationalization is most likely to be quietly abandoned, because the costs of the work are visible and the benefits are not yet. Put the drain-down measures in the monthly operating review from the start so the progress stays visible.
Where to go from here
Start with the question of whether you have a SKU problem at all. The five tests in how many SKUs is too many will tell you whether your tail is consuming capacity your best products need, or whether the real problem is a missing configuration that a count will never reveal.
If the rationalization is part of a larger question about where to invest, the funding side of the same decision is covered in the guide to product portfolio strategy. And if the unit you are looking at is a whole business rather than a product line, the triage for that decision is in fix it, sell it, or shut it down.
If the question in front of you is narrower, which of several near-identical variants to keep, the grid still applies. Put the variants in adjacent columns, look at which customers buy each one, and keep the one your top row buys. The rest become migration candidates with a substitute already chosen.
Whichever way you enter, begin with one product line rather than the whole catalog. A single line, done properly with the grid, the exposure estimate, and a named migration path, teaches the organization how the method works, and it produces the evidence you will need to do the next line faster and with less argument.
What to do Monday morning: pull last year’s invoice lines into one sheet with customer and SKU side by side, and find out which of your tail products your top twenty customers buy.
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.
Most SKU cuts stall at the decision, not the analysis. Request a free Decision Velocity Audit and I will measure how long a kill decision actually takes in your business, and where it waits.
See also: 3 Places Revenue Goes After a SKU Cut, When to Keep the Long Tail and When to Cut It