TAM, SAM and SOM without the hand-waving

Market sizing is the estimation of how much revenue a market contains and how much of it a given company could plausibly capture. Three terms carry most of the work, and they are routinely used interchangeably by people who would be embarrassed to learn they mean different things.

What do TAM, SAM and SOM actually mean?

The most common error is a deck that presents a large TAM and then jumps straight to a revenue projection. TAM is not a forecast and was never meant to be. It is a ceiling — useful for establishing that a market is worth entering at all, and useless for planning anything.

Top-down sizing: start from the market

Top-down sizing begins with a published total for a market and narrows it with successive filters until you reach the slice you can serve.

Global market for category X → the regions you sell in → the customer segments you serve → the sub-segment with the problem your product solves → SAM.

It is fast, and it anchors you to what the market believes about itself, which matters when you are presenting to people who have read the same reports. Its weakness is inherited: every flaw in the source's category definition becomes a flaw in yours. If a research firm's "workforce management software" figure bundles four things and you only sell one of them, your top-down number is wrong by an amount you cannot see.

Two disciplines make top-down sizing defensible. First, name the source and its cut-off date. Second, write out each filter as an explicit percentage with a justification — "38% of the total is EMEA (source: same report, regional split)", not an unexplained multiplication.

Bottom-up sizing: start from a unit

Bottom-up sizing builds the number from things you can count:

Number of potential customers × how many units each buys × price per unit × purchase frequency = market value.

Bottom-up is grounded in quantities you can defend, and it forces you to state a price, which is where a surprising number of business cases quietly fall apart. Its weakness is compounding: if your customer count is 20% high and your price assumption is 30% high, you are out by more than half before you have made any other mistake.

The customer-count input is the one to spend time on. Company registries, industry association membership figures, professional-body counts, licensed operator lists and job-posting volumes are all real, checkable proxies. An estimate anchored to a countable population is far stronger than one anchored to a percentage of a percentage.

Why run both?

Because the gap between them is the most informative output of the exercise.

• Within roughly 30% of each other: your model is probably sound. Present the range, note that both methods agree, and move on.
• Different by 2–3×: one input is materially wrong. Usually it is your price assumption, or the source report's category is broader than you thought. Find it before presenting anything.
• Different by an order of magnitude: you have defined the market differently in the two models. This is the most valuable failure the exercise produces, because it means you did not have a settled definition of the market you are entering.

Reconciling the two is not busywork to satisfy a methodology checklist. It is the actual analysis. The reconciliation paragraph — "top-down gives £340m, bottom-up gives £210m; the difference is almost entirely the source's inclusion of hardware, which we do not sell" — is often the single most useful sentence in a sizing study.

How do you get from SAM to a defensible SOM?

SOM is where sizing stops being arithmetic and starts being an argument. A share figure asserted without a mechanism is worthless; the number needs an account of how the share is taken.

Useful anchors:

• Capacity-constrained. Work forward from what your team can actually sell and deliver. If you can onboard 40 customers a year and the SAM contains 4,000, your three-year SOM is bounded by 3% regardless of how good the product is.
• Analogue-based. Find a company that entered a comparable market and look at the share it held after three years. This is the most credible method with an audience that has seen many plans.
• Displacement-based. If you are replacing a named incumbent, size from their customer base and a realistic switching rate. Switching rates in enterprise software are low — often low single digits annually — and plans that assume otherwise need to say why.

For a new entrant in an established market, 1–5% of SAM within three years is a defensible planning band. Above 10% needs a structural reason: a distribution advantage, a regulatory change, an incumbent exiting the segment. Boards do not reject ambitious SOMs; they reject SOMs with no mechanism attached.

Presenting a number a CFO cannot dismantle

Four properties separate a sizing that holds up from one that does not.

1. A range, not a point. "£180m–£240m" reads as analysis. "£214.7m" reads as false precision and invites someone to ask where the seven-hundred-thousand came from.
2. The fragile assumption named. Every model has one input that moves the answer more than any other. Say which, and show what the number does at ±30% on it. Naming your own weakest point is disarming; being caught not knowing it is fatal.
3. A visible calculation. One appendix table with every input, its value, its source and its provenance class. Readers who want to argue will argue with an input — which is a far better conversation than arguing with the conclusion.
4. An explicit definition of the market. One paragraph stating what is in and what is out. Most sizing disputes are definition disputes that nobody noticed in time.

A sizing model is a claim about the world with an audit trail attached. The audit trail is the product. The number is just where it happens to land.

Common failure modes

• Treating TAM as the opportunity. Nobody wins 100% of a market. TAM establishes that the room is big enough to stand in.
• Sizing a market that does not exist yet. For genuinely new categories, size the problem instead — current spend on the workaround, hours lost, error costs. That number is real and countable; a projected category size for something nobody buys yet is not.
• Double-counting the value chain. If both the platform and the reseller appear in your customer count, you have counted the same revenue twice.
• Using a growth rate you did not derive. A CAGR lifted from a press release is a marketing figure. Either derive growth from historical data points you can see, or present it as reported and label it as such.

Do those things and the sizing becomes what it should be: not a big number in a deck, but a model someone can disagree with productively — which is the only kind of estimate worth putting in front of a decision.