- Part one: building the screen
- Find the constraint first
- Rank by contribution per constraint hour
- A worked example
- When the constraint has slack
- The exceptions that survive the screen
- Part two: making the kill
- Give every candidate one way out
- The whole screen on one page
- Decide in batches, not one at a time
- Prove the kill paid
Picture the constraint on a Thursday afternoon. The press has been down for a changeover for most of the shift. The part going on next sells a few hundred units a year to a customer nobody in the room can name without checking, and the part waiting behind it is the one your largest account has been chasing since Monday. Everyone in the building can see what is wrong with that picture. Almost nobody’s SKU review would catch it.
The standard way to find SKUs to kill is to rank them by margin percentage and look hard at the bottom of the list. It is intuitive, it is what the ERP reports make easy, and it protects exactly the wrong products. A small, fussy, high-margin part can look like one of your best items on a margin report while it eats constraint time your real best items need.
Short answer: find your constraint, then rank every SKU that runs on it by contribution per constraint hour: price minus truly variable cost, divided by the constraint time each unit consumes, changeovers included. Kill candidates sit at the bottom of that ranking, but only while the constraint is full and the products above them could use the hours. Everything on the list gets one way out before it goes.
This screen sits inside the wider method in how to cut a product line without losing revenue. It answers a narrower question: of the products you could cut, which ones should go first.
Part one: building the screen
The screen has four steps and an exception check, and the order matters, because each step changes what the next one means. Finding the constraint tells you which products compete with each other. Ranking tells you which of those competitors earns least. The worked example shows why the ranking disagrees with your margin report, and the slack test tells you whether the ranking applies at all this quarter. Only then do the exceptions come in.
You will need four inputs for every product that touches the constraint: price, variable cost, run time per unit, and the number and length of its changeovers over the last year. Most plants already hold all four between the ERP and the schedule. The difficulty is not finding them. It is putting them in one place for the first time.
Resist the urge to start with the list of products everybody already suspects. That list is built from margin reports and irritation, and it is the input this screen is designed to replace.
Find the constraint first
The constraint is whatever limits how much you can ship: a press, a paint line, a test cell, a heat treat oven, occasionally a single skilled trade. When demand for your good products exceeds what that resource can do, every hour it spends on something is an hour it cannot spend on something else, and that fact is the foundation of the whole screen.
Do not take the constraint from the capacity report. Capacity reports describe what equipment could do under standard assumptions, and the real constraint is usually wherever those assumptions fail most often. Walk the floor and look for three signs: the place where work waits, the place where overtime concentrates, and the machine the planner schedules first every week because everything else is arranged around it. When all three point at the same resource, you have found it.
Many plants have more than one, usually one per product family. That is fine. Run the screen separately for each family against its own constraint, because a product that eats hours on one machine is not competing with products that never touch it.
If you cannot find a constraint at all, because nothing waits and nothing runs overtime, you have a different situation and a different screen, covered under slack below. Most plants that believe they have no constraint have one that moves between two or three resources depending on the mix, which is itself a symptom of a line with too many products sharing too few machines.
Rank by contribution per constraint hour
For every product that runs on the constraint, you need two numbers. The first is contribution per unit: price minus the costs that truly vary with each unit, meaning material, consumables, freight, and commission. Leave allocated overhead out, because the question here is what the business gains or loses per unit, not how the accountants spread the building.
The second is constraint time per unit, and this is where most rankings go wrong. It is run time plus the product’s share of changeovers: the setup hours it causes in a year divided by the units it sells in a year. For a high-volume product the setup share is a rounding error. For a tail product it can be larger than the run time, and a margin report never sees it.
Divide the first number by the second. The result is contribution per constraint hour, and it is the only ranking that tells you what a product earns from the one resource that limits your earnings. Sort every product on the constraint by it, highest to lowest.
The method I use for capacity allocation is the Karelin Method. It treats output as the product of three multipliers, volume, efficiency, and focus, and gives focus by far the heaviest weight. A kill screen is the focus multiplier applied to a product line: it takes the constraint away from work that earns little per hour and hands it to work that earns a lot.
Underneath it is the principle I have run my career on: make as much money as you can every minute of the day. Contribution per constraint hour is that principle applied to the only minutes in the plant that actually limit the money. The same idea applies to people as it does to machines. Spend as much of your day as possible doing the things only you can do, and spend as much of your constraint’s day as possible making the things only it can make profitably.
A worked example
Hypothetical: two parts share a press that is fully booked. Part A sells for $50 with $30 of variable cost, a 40 percent margin and $20 of contribution. It takes 0.05 press hours a unit and sells 10,000 units a year in ten runs, each with a two-hour changeover, which adds 0.002 hours a unit. Total: 0.052 press hours a unit, or about $385 of contribution per press hour.
Part T sells for $60 with $30 of variable cost, a 50 percent margin and $30 of contribution. On a margin report it beats Part A comfortably. But it is fussier to run, at 0.10 press hours a unit, and it sells only 300 units a year across six runs, each with the same two-hour changeover, which adds 0.04 hours a unit. Total: 0.14 press hours a unit, or about $214 per press hour.
Part T uses 42 press hours a year. Given to Part A, which has orders waiting, those hours make about 800 more units and roughly $16,150 of contribution, against the $9,000 Part T earns in the same hours. Retiring Part T is worth about $7,150 a year before counting any of its per-SKU costs, and the margin ranking would have protected it.
Notice what did the damage. It was not Part T’s run time, which was only twice Part A’s. It was the changeover share, twenty times larger per unit, because six setups were spread over three hundred units instead of ten setups over ten thousand. That is the pattern to look for across your whole list, and it is invisible in any report that does not divide setup hours by volume.
When the constraint has slack
The ranking only means what the worked example says it means when the constraint is full. If your press has idle hours, retiring Part T frees time that nothing else will use, and the $7,150 does not exist. The hours come back and sit there.
In that case the kill decision rests on two other things: the costs that are fixed per SKU, such as changeovers, safety stock, planning time, and document upkeep, and the cash tied up in the product’s inventory. Those are real and often larger than people expect, and the method for putting a number on them is in what a SKU actually costs. But the bar is higher and the list is shorter, because you are removing cost rather than releasing capacity into demand that is already waiting.
There is one trap in the slack case worth naming. Apparent slack is sometimes created by the tail itself: when changeovers chop the schedule into short runs, the constraint can look under-loaded and backlogged at the same moment, because it spends its hours setting up rather than running. If you see idle time and long queues together, recompute the load with setups included before you conclude you have slack.
Many plants are full in some months and slack in others. Run the ranking on the busy months, because that is when the displacement happens and when the tail does its damage. A product that is harmless in February and costly in October is a product you should either move off the constraint or retire, and the busy-season ranking is what tells you which.
The exceptions that survive the screen
Three kinds of product survive even the bottom of the ranking, and you check for them only after the ranking is built, so the exceptions cannot be used to avoid building it.
The first is a product your top customers need in order to keep buying the rest of their basket from you. Its contribution per hour is low and its real value sits in someone else’s revenue. The second is a product you are obliged to supply: a service part, a regulated item, a line under a supply contract. The obligation has an end date, and that date is the earliest the product can go. The third is a product too new to judge, still inside the ramp period you set when it was launched. If you did not set one, set it now and judge the product when it expires.
Hold the exceptions to a written standard. A product claimed as a basket completer needs a named customer and evidence that the customer buys the rest of the basket from you. An obligation needs a document. A product claimed as too new needs a launch date. Without that standard, every product at the bottom of the ranking acquires an exception by the time the meeting starts.
Everything else at the bottom of the ranking is a candidate. Sorting a tail into kinds is a separate job with its own method, and the full breakdown is in when to keep the long tail and when to cut it.
Part two: making the kill
The screen produces a ranked list of candidates. Turning that list into retired products is a different kind of work, and it fails for different reasons. The analysis fails when it uses the wrong ranking. The execution fails when the decision is made one product at a time, when nobody offers the customer an alternative, or when nobody checks afterward whether the freed hours went anywhere.
Each of the next four sections deals with one of those failures, in the order they tend to happen.
Give every candidate one way out
Before any product goes, it gets one chance to earn its hours, and the screen tells you exactly what that chance looks like. The first way out is price. In the worked example, Part T would need about $54 of contribution per unit to earn what Part A earns in the same press time, which means a price of about $84 instead of $60.
That number is the most useful output of the whole exercise. Some customers will pay it, and when they do, the product has stopped being a problem: it now earns its place on the constraint. Customers who will not pay it have told you the product was never worth the hours to them either, and they will generally move to an alternative without much friction.
Offer the price in writing, with a date, and mean it. A price increase floated verbally and withdrawn at the first complaint teaches the customer that the product was never really at risk, and it teaches your sales team the same thing. The customer’s answer is only information if the alternative is real.
The second way out is to take the product off the constraint. Route it to a slower machine with spare hours, make it in larger and less frequent batches, or buy it in from a supplier. Any of those removes it from competition with Part A, and at that point the ranking no longer applies to it. Its remaining costs still need to be justified, but it is no longer taking hours from the product waiting behind it.
A product that refuses both, that will not bear the price and cannot move off the constraint, has had its chance. Retire it.
The whole screen on one page
Laid out as a decision tree, the screen is five questions, asked in order. Does it run on the constraint? If not, judge it on per-SKU cost and cash. Is the constraint full? If not, the same. Is it at the bottom of the ranking? If not, keep it. Is it an exception? If so, keep and manage it. Does it accept a price that pays for its hours? If so, keep it at the new price. If not, kill it.
The tree is deliberately short. Every question has a factual answer that someone in your plant can check, and none of them asks whether anyone likes the product. Put it in front of whoever proposes the next new product as well, because the same five questions tell you what that product will have to earn to deserve its place.
Decide in batches, not one at a time
Run the screen on a whole product family at once and decide on the whole bottom of the ranking in one sitting. Deciding product by product, as candidates come up, guarantees that each one gets argued on its own story, and a story about a customer beats a number about press hours in almost every meeting.
The ranking changes what the argument is about, which is its real value. Publish the list with the math visible: contribution per unit, run time, setups per year, units per year. Anyone who disagrees with a product’s position now has to disagree with an input, and inputs are checkable. Either the setup takes two hours or it does not. Either the part sells three hundred a year or it does not. The meeting stops being a contest of opinions and becomes a correction of data, which is shorter and ends with a decision.
Expect the first run of the screen to generate the most corrections. Setup times recorded in routings are often years out of date, and variable costs often leave out freight or packaging. Treat every correction as an improvement to the data you run the business on, not as an attack on the screen.
Set the rules before the list appears: which constraint, which months, what counts as an exception, who makes the final call. Then give one person that call. Line owners supply the corrections to the inputs. They do not vote on their own products.
Repeat the screen when the constraint load changes materially, and at least once a year regardless. New products arrive, volumes drift, and the bottom of last year’s ranking is not the bottom of this year’s.
Prove the kill paid
The benefit of retiring a product on the constraint is not the cost you removed. It is the contribution the freed hours earn when they go to something better, and that only happens if somebody makes sure they do.
Track three things for two quarters after each batch: the constraint hours the retired products used to consume, where those hours went, and contribution per constraint hour for the product family as a whole. If the freed hours went to products with orders waiting, that last number rises and the kill paid. If they sat idle, either the demand was not there, in which case you were in the slack case and should have judged on per-SKU cost, or the schedule never reassigned them, which is a planning problem you can fix in a week.
Watch lead time on the products at the top of the ranking as well. When the tail stops interrupting the constraint, the queue in front of your best products shortens, and your largest customers will notice before your reports do.
Keep the worked example in mind when someone argues for bringing a retired product back. A SKU that earns half as much per constraint hour as the product waiting behind it is not a small profitable item. It is a charge against the product it displaces, paid every time it runs.
A SKU that earns half as much per constraint hour as the product waiting behind it is not a small profitable item. It is a charge against the product it displaces.
So which SKUs should you kill? The ones that earn the least per hour of your constraint while the constraint is full, once they have refused the price that would make them worth their hours and fall under none of the exceptions.
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.
The kill screen works best run live, with the people who will argue about it in the room. Bring it to your next leadership meeting or industry association event through the speaking page, and your team works it on its own product lines instead of hearing about someone else’s.
See also: When to Keep the Long Tail and When to Cut It, What a SKU Actually Costs You