TAM and Sourcing

Turn a market definition into a deduplicated, sized, prioritized universe. Sizing first, pulling second, and never the reverse.

When to use

• Standing up a program and nobody knows how many accounts exist
• A segment expansion decision needs a denominator
• The current list is too small to hit a pipeline number and you need to know whether more exist
• Territory planning

Inputs

• Reads: workspace/data/object-model.md, workspace/data/suppression.csv (both required)
• Needs from user: the segment definition in firmographic terms, geography, the exclusions, and the current account list

Do not run this without the object model. Sourcing into an undefined model produces a universe you cannot dedup.

Workflow

1. Write the segment definition as filters

Vague segment definitions produce unusable universes. Convert prose into filters.

"Mid-market SaaS in North America" is not a definition. This is:

Industry:        <specific codes or categories, listed>
Employee count:  <range>
Revenue:         <range, or a proxy>
Geography:       <countries, or regions>
Business model:  <B2B, subscription, etc.>
Technology:      <required stack signals, if any>
Excluded:        <competitors, resellers, staffing, agencies, franchises>

If a filter cannot be expressed as a field, it is a qualification criterion for later, not a sourcing filter. Note it and move on.

2. Probe the size before pulling anything

Run a count-only query first. Sizing costs nothing and pulling costs money.

Then react to the number:

A universe larger than your team can work is a definition problem, not a capacity problem. Adding a filter is cheaper than enriching 20,000 records you will never touch.

3. Reconcile against what you already have

Before pulling, compute the overlap:

Universe size                 n
Already in CRM                n   (matched on normalized key)
On the suppression list       n
Net new to source             n   ← the only number that should be pulled

Teams routinely pay to source records they already own. The reconciliation is one join and it is always worth doing.

4. Pull in pages, with a ceiling

Never a single unbounded pull.

Page size:        500 rows
Ceiling:          <stated before starting>
Fields at pull:   identifiers and firmographics only

Pull identifiers only at this stage. Do not enrich during sourcing. Sourcing establishes existence, enrichment fills detail, and they have completely different cost profiles. Mixing them means paying enrichment prices on records that will be disqualified thirty seconds later.

5. Prioritize before handing off

The universe is not a work list. Add a coarse priority so enrichment runs on the top of the list first.

Use whatever is available for free at this stage: employee count, industry match strength, geography, existing relationship, known technology fit. A three-band split is enough. Precision comes later in icp-scoring-engine.

6. Record the provenance

Every row carries where it came from and when. Without provenance you cannot tell a stale 2024 pull from a fresh one, and you will re-source records you already have.

Output

• Writes: workspace/data/universe.csv with provenance columns
• Prints: the filter definition, the probe count, the reconciliation table, rows actually pulled, spend, and the priority band distribution

Rules & quality bar

• Size before pulling. Always. Counting is free
• Identifiers only at sourcing. Enrichment is a separate, gated step
• Reconcile against CRM and suppression first. Never pay for what you own
• Every pull is capped. State the ceiling before starting
• Provenance columns on every row: source, query, date
• A universe over 20,000 means the definition is wrong. Say so rather than pulling it

Related skills

• Requires: data-model-and-sync
• Hands off to: data-hygiene, then enrichment-waterfall, then icp-scoring-engine
• See also: docs/cost-model.md