- 1. What goes on each axis?
- 2. How do you define a product family?
- 3. How do you define a customer?
- 4. What goes in the cells?
- 5. What period should you use?
- 6. How do you handle the tail?
- 7. How do you read the finished matrix?
- 8. What construction errors show up most?
- 9. How do you know the matrix is wrong?
- 10. What do you do the day it is finished?
Twelve. That is the number of product families most manufacturers should end up with on one axis of this matrix, and it is almost never the number they start with. The first attempt usually produces either four, which hides everything, or two hundred, which is the part number list wearing a costume.
Getting that one decision right determines whether the exercise produces an insight or a spreadsheet. I have watched several of these builds and the failures are almost never in the cost allocation, which everybody worries about. They are in the axes, which nobody discusses.
This is the construction guide. The reasoning behind the exercise is in the profitability pillar, and the cost drivers that feed the cells are in the three-week cost-to-serve method. What follows is how to actually build the thing.
One note on tooling before the mechanics. Build this in a spreadsheet for at least the first two annual cycles, regardless of what your systems could theoretically do. The spreadsheet forces you to make every definitional decision explicitly, where a business intelligence tool will make several of them silently using whatever hierarchy it already holds. Those silent decisions are exactly the ones this article is about.
1. What goes on each axis?
Customers on one, product families on the other, and the reason both are needed is that the interesting behaviour lives at the intersection rather than at either margin. A customer ranking hides which part of what they buy is the problem. A product ranking hides which customers are driving the cost of an otherwise healthy family.
If you build only one axis, build products first, because product families are more stable than customer lists and the finding transfers to next year. But build both. The method I use for this is the 80/20 Matrix of Profitability, and it is two-dimensional for the same reason a map is: the position matters, not the ranking.
Orientation is arbitrary and you should pick one and never change it, because everyone in the business will memorize the layout and re-orienting it later costs you a month of confusion for no benefit.
A word on what this is not. It is not a segmentation exercise and it is not a strategy artifact. It is an operating instrument you will rebuild annually, which means every construction decision should be judged on whether the same decision can be made again next year by somebody else. Clever definitions that only the person who built them understands will not survive their departure, and the matrix will quietly stop being produced.
That test disciplines most of the choices below. If a family definition requires a paragraph to explain, simplify it. If assigning a new customer to a row requires judgement nobody has documented, write the rule down. The value of this thing comes from the third build, not the first.
One more framing point before the mechanics. The matrix is not a report you produce for someone else. The person who builds it should be somebody who will also have to act on it, because the build is where the understanding happens. A model constructed by an analyst and handed to a decision maker loses roughly half its value in the transfer, and the half it loses is the part that explains why a particular cell looks the way it does.
2. How do you define a product family?
By how the product consumes your operation, not by how the catalogue is organized. This is the single most consequential decision in the build and it is usually made by whoever runs the export, in about four seconds, by selecting whatever field the ERP already has.
Your existing product hierarchy was built for a purpose that was not this one. It usually reflects how things are sold, or how they were sold in 2011, or which division made them before a reorganization. Grouping by that hierarchy will produce a matrix that confirms whatever the organization already believes.
Group instead by shared cost behaviour: things made on the same equipment, with the same setup pattern, the same material class, the same engineering intensity. If two items sit in the same catalogue category but one runs on an automated line and the other requires a manual cell, they are different families regardless of what they are called.
Aim for eight to sixteen. Below eight and the families are too coarse to act on, because every finding applies to a quarter of the business. Above twenty and you cannot hold the matrix in your head, which means nobody will use it in a meeting, which means it will not change anything.
Write down the definition of each family in one sentence before you build anything. If you cannot describe why a family is a family without listing its members, it is not a family.
Two specific traps in family definition are worth naming because they are near universal. The first is treating a size or configuration range as separate families when they run identically through the plant. Sixteen variants of the same casting, differing only in a machined dimension, are one family. Splitting them fragments the matrix and produces cells too small to interpret.
The second is the opposite: collapsing genuinely different cost behaviour because the items share a brand or a catalogue page. A standard item and its custom-engineered cousin can sit side by side in the catalogue and consume completely different amounts of your operation. If the setup pattern differs by an order of magnitude, they are different families no matter how the brochure organizes them.
When in doubt, split. You can always merge two families in the analysis afterwards, and you cannot separate one you collapsed without rebuilding.
How many families you end up with also determines how usable the matrix is in a room. Twelve families against fifteen named customers plus a tail row is a grid of roughly two hundred cells, which fits on one page and can be scanned in a meeting. Thirty families against fifty customers is fifteen hundred cells, which is a database rather than an instrument, and nobody will ever look at it twice.
That constraint is not a compromise forced by presentation. A grid you cannot scan is a grid whose patterns you will never notice, and the patterns are the entire point. Build for the page.
3. How do you define a customer?
By who makes the buying decision, which is frequently not what your customer master says. This is where the build stalls most often, and the reason is that customer masters accumulate rather than get maintained.
You will find the same company under three spellings, ship-to addresses treated as separate accounts, divisions of the same parent that have never been linked, and at least one entry that has not ordered since 2019. All of that is normal and none of it needs to be fixed properly before you can proceed.
Work top-down. Take the accounts making up the first eighty percent of revenue, which is usually a manageable list, and clean only those by hand. Assign each to its real decision-making entity, linking subsidiaries to parents where the buying is genuinely coordinated and leaving them separate where it is not. Ask a salesperson rather than a system, because the salesperson knows.
Your customer master will link entities your salespeople know are unrelated, and separate ones they know are the same buyer. Ask the salesperson, not the system.
Decide in advance how you will treat three specific situations, because each of them will arrive and each will stall the build if it is decided ad hoc. Contract manufacturers and distributors who resell your product, where the buying decision sits with their customer rather than with them. Intercompany sales, which should usually be excluded entirely. And one-time project customers, who distort a twelve-month view and are better flagged than removed.
The rule I would apply to all three is to include them, flag them, and look at the matrix both ways. Excluding transactions because they are awkward removes exactly the population most likely to be unprofitable, and you will not know that until you have looked.
The parent-versus-subsidiary decision deserves a rule rather than case-by-case judgement, because you will face it thirty times and inconsistency will undermine the whole matrix. The rule I use: combine them when a single procurement function negotiates for both, separate them when each site or division buys independently. That is a question about their organization rather than yours, and the answer comes from your salespeople in a ten-minute conversation.
Record the decision next to each combined entity, because next year somebody will ask and the reasoning will have evaporated. A one-line note is enough.
A related question that always comes up: what about customers who buy nothing this year but bought heavily last year. Leave them in the matrix with zero revenue for the current period rather than dropping them from the customer list. A row of zeros next to a row of substantial prior-year numbers is one of the more useful things the matrix can show you, and dropping the account makes the loss invisible.
4. What goes in the cells?
Gross profit after allocated cost to serve, in dollars, with revenue available as a second layer. Dollars rather than percentages, because percentages make small cells look important and large cells look boring, which inverts the priority you are trying to establish.
Keep three numbers per cell and no more: revenue, gross profit before cost to serve, and gross profit after it. The third is the answer, and the first two are what you need to explain it to somebody who does not believe the third.
Resist the urge to add margin percentage as a fourth. It will be the number everyone looks at, it will lead the conversation toward the smallest cells, and you can always compute it when a specific question calls for it.
Put the numbers in a long format table before you pivot anything: one row per customer, per family, per period, with the three values in columns. Every analyst instinct says to build the visual grid first, and every one of those builds becomes impossible to extend the moment somebody asks for a second year or a fourth measure. The grid is a view. The long table is the model.
Keep the raw transaction file alongside it, unmodified. You will need to trace a surprising cell back to individual invoices at least twice during the build, and a model with no path back to the transactions cannot survive its first serious challenge.
The grid everyone wants to see is a view. Build the long table first, one row per customer per family per period, or the model cannot be extended.
Include revenue in the cells even though profit is the answer, because the two together tell you something neither tells you alone. A cell with large revenue and small profit is a pricing problem. A cell with small revenue and large negative profit is a complexity problem. Both look identical if you only carry the profit number, and they need opposite interventions.
One more practical point on units. Express everything in whole dollars or whole thousands, consistently, and never mix. A matrix where some cells are in thousands and some are not has produced at least one wrong decision in every business I have seen do it.
Include a revenue layer even if the decision will be made on profit, because the two answer different questions and you will be asked both within the first ten minutes of any meeting where this appears.
5. What period should you use?
Twelve months, rolling, and then repeat the build on the two prior years once the first one is working. A single year tells you the position. Three years tell you the direction, and the direction is where the actionable finding usually hides.
Twelve months matters specifically because it absorbs seasonality and one-off events without smoothing away real movement. A quarter will mislead you badly in any business with a seasonal pattern or a project-based order profile.
If you can only produce one year, produce one year and proceed. The comparison across years is a refinement that costs an afternoon once the first build exists, and waiting for all three before starting is how this turns into a project.
One decision to make explicitly rather than by default: whether to use a rolling twelve months or a fiscal year. Rolling is better analytically because it can be refreshed at any point and always covers a full cycle. Fiscal is better politically because it reconciles to numbers people already argue about. If the matrix is going into a leadership meeting, use fiscal for the first build and switch to rolling once the method is accepted.
Build the current year first and only then go back. The temptation is to assemble all three years at once because the queries are similar, and the result is three weeks of data work before anybody sees a finding. Produce the current year, read it, get the reaction, and then add history. The reaction usually changes what you would have built for the prior years anyway.
6. How do you handle the tail?
Roll it into a single row called tail for the first pass and treat it as one population. The tail is where most of the data quality problems live, and cleaning it before you have any findings is the most reliable way to spend six weeks and abandon the exercise.
This works because the tail behaves as one population anyway. Two hundred accounts each producing a fraction of a percent of revenue do not need individual treatment at this stage. What you need to know is how much revenue and how much cost the whole group consumes, and whether the group as a block is profitable.
Once the matrix is built and you know whether the tail row is positive or negative, you can decide whether it is worth decomposing. In most businesses it is, but only after the finding justifies the effort, and by then you have leadership attention to fund it.
The same logic applies to product families with trivial volume. If four families together represent two percent of revenue, combine them into an other column rather than carrying four near-empty columns across the whole matrix. Sparse cells are noise, and a matrix that is mostly white space is one nobody will read.
There is one exception worth protecting. If a tiny family is strategically important, a new product line or an entry into a segment you intend to grow, keep it visible even though the numbers are small, and label it so nobody reads its poor economics as a verdict on something that has existed for six months.
Set the tail threshold by count rather than by revenue percentage, because a revenue rule produces wildly different results in a concentrated business than in a fragmented one. Taking the top fifty customers by name and rolling the rest works in most manufacturers, and fifty is a number a leadership team can look at without their eyes sliding off the page.
Keep a list of which accounts went into the tail. You will need it the first time somebody asks about a specific customer and finds they are not on the matrix, and being unable to answer that question undermines confidence in everything else you built.
7. How do you read the finished matrix?
Cells first, then rows, then columns, and in that order specifically. Most people read it the other way round, starting with customer totals, which is exactly the single-axis view the matrix exists to replace.
Scan the cells for the largest negative numbers and the largest positive ones. The negatives are your action list and the positives are your risk register. Write down the top five of each before doing anything else, because your first reading is the least contaminated by other people’s opinions.
Then read the rows to see which customers are profitable in aggregate but negative in one specific family, which is the most fixable pattern on the whole matrix. Then read the columns to see which families are carried by a small number of customers, which is where your concentration risk actually sits.
One reading discipline that pays for itself: look at the matrix before anyone tells you what it means. Circulating it in advance of a meeting guarantees that by the time you discuss it, every participant has constructed an explanation for the cells that concern them, and the session becomes a contest of narratives rather than a reading of data.
Read it alone, write your five conclusions, then circulate. Compare what you concluded against what the room concludes, and pay particular attention to any cell where your reading and theirs diverge sharply. That divergence is either a data problem or a knowledge gap, and both are worth finding.
Then look for the pattern that is easiest to act on and hardest to see in a list: a family that is profitable with most customers and heavily negative with two or three. That configuration is almost always a pricing or specification problem confined to those accounts rather than a problem with the product, and it is the most fixable finding the matrix produces. A one-dimensional product analysis would show this family as merely mediocre and you would go looking for a cost reduction that was never needed.
The reading order matters for a reason worth stating. Cells are specific enough to act on, rows and columns are aggregates, and aggregates invite explanation while specifics invite decision. Start with aggregates and the meeting becomes an argument about what the totals mean. Start with five named cells and the meeting produces five owners and five dates.
8. What construction errors show up most?
Five, and four of them happen before any cost is allocated. This is why the axes deserve more attention than they get and the allocation deserves less.
Using the catalogue hierarchy as the family definition, covered above, and the most common by a wide margin.
Leaving the customer master uncleaned, so the same buyer appears in four rows and none of them looks significant. This one is insidious because the matrix looks fine and the finding is simply absent.
Putting percentages in the cells, which redirects every conversation toward small high-margin corners of the business.
Excluding revenue that does not fit neatly, such as tooling charges, freight billed, samples and non-standard work. It is tempting because it is messy, and it removes exactly the transactions most likely to be unprofitable.
And allocating cost to serve at the customer level rather than at the cell level. If a customer’s expedites all relate to one product family, spreading that cost across everything they buy makes the guilty family look acceptable and the innocent ones look worse.
Four of the five common construction errors happen before any cost is allocated. The axes deserve more attention than the allocation and almost always get less.
A sixth error, subtler than the rest and specific to businesses with a long order-to-delivery cycle: mismatching the revenue period and the cost period. If revenue is recognized at shipment and the setups, engineering and expedites occurred two quarters earlier, a customer can appear profitable in a period where you actually spent heavily on them. In project or backlog businesses, align both to the order date rather than to the invoice date and say so on the page.
A seventh, and the one most likely to survive undetected: building the matrix on a revenue figure that includes items the gross profit calculation excludes, or the reverse. Freight billed, tooling charges and surcharges all commonly sit in one and not the other. Reconcile the revenue total on your matrix against the general ledger revenue line once, at the start. It will not match, and the reason it does not match is always instructive.
Finally, a presentation error that is not a construction error but destroys builds anyway: colour-coding the matrix before the numbers have been validated. A red cell is a verdict, and once somebody’s account is red in a meeting the conversation is about defending it rather than understanding it. Present the numbers plain for the first reading and add colour only after the outlier testing is complete.
9. How do you know the matrix is wrong?
When the people who know the accounts cannot explain the outliers. That is the test, and it is more reliable than any reconciliation.
Take the twenty cells that differ most from what the organization expected and walk each one with the person who owns that account or that family. You are looking for two responses. If they say they always suspected that and here is why, the model is working. If they say that cannot be right and then produce a specific reason it cannot, check the reason, because two or three of them will be correct and will reveal a structural error affecting many cells.
Fix what that test surfaces and then stop. A second full iteration will change the numbers slightly and the conclusions not at all, and every week of refinement is a week the decisions are not being made.
A second test, mechanical rather than conversational, takes ten minutes. Sum the matrix and compare the total gross profit after cost to serve against the company total. The difference is your unallocated overhead, and you should be able to say what it consists of in one sentence. If the unallocated remainder is larger than you expected, some cost that varies by customer is sitting in it and the model is understating the spread between accounts.
Run one more sanity check on the extremes. Your single most profitable cell and your single least profitable cell should both be explicable in a sentence by somebody who knows the business. If either is a mystery, you have found something or you have found a bug, and both are worth an hour.
Ask one more question of every outlier, and it is the question that separates a real finding from an artifact: is this cell unusual because of what the customer does, or because of how we recorded it. Customers who order through an unusual channel, who are invoiced by a different entity, or whose product is built under a legacy part numbering scheme will all produce strange cells for reasons that have nothing to do with their economics.
Keep the twenty tested cells and their explanations in a tab alongside the model. Next year, when you rebuild, that tab is the first thing you read, and it tells you which of last year’s surprises were real and which were artifacts. It also protects you from the most demoralizing outcome of an annual cadence, which is rediscovering the same finding three years running because nobody recorded that it was already known.
10. What do you do the day it is finished?
Present the cells, not the totals, to the smallest group that can decide things. Six people, two hours, with the matrix on one page and the top five negative and positive cells written out separately.
Expect the meeting to spend forty minutes on one account that somebody is attached to. Decide in advance how you will handle that, because it will happen and it will consume the session if you let it. The technique that works is to acknowledge it, park it explicitly as a decision for later, and move to the other nineteen.
Leave the room with owners and dates against the top five negatives, and a named person responsible for rebuilding the matrix in twelve months. Without that second item you have produced a document. With it you have started a cadence, and the cadence is the part that compounds.
Monday morning: write the one-sentence definition of each product family, before touching any data.
About the Stagnation Assassin
Todd Hagopian is a Fortune 500 transformation executive who has generated $3B+ shareholder value across five turnarounds at Berkshire Hathaway, Illinois Tool Works, and Whirlpool. He is 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.