# Tam And Sourcing

> Use when the user says "how big is our TAM", "source my market", "build the universe", "pull a list of companies", "market sizing", "where do we find these accounts", "we need more accounts in the funnel". Sizes the addressable universe, then pulls it in cost-controlled pages with dedup against what already exists. Writes workspace/data/universe.csv.

- Skill: `guerrilla2799/tam-and-sourcing` (Agent Skill)
- Install (CLI): `npx skillmds@latest add guerrilla2799/tam-and-sourcing`
- Raw SKILL.md: https://api.skillmd.com/api/skills/guerrilla2799/tam-and-sourcing/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Data & Analytics
- Author: guerrilla2799 (https://skillmd.com/u/guerrilla2799)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/guerrilla2799/tam-and-sourcing

---


# 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:

| Universe size | Reading | Action |
|---|---|---|
| Under 200 | Very tight, possibly too tight | Confirm the filters are not accidentally excluding. Consider widening one dimension |
| 200 to 2,000 | The workable band for account-based work | Proceed. Full enrichment is affordable here |
| 2,000 to 20,000 | Too large to treat individually | Add a prioritization dimension before pulling. Pull the top tier only |
| Over 20,000 | The segment is not a segment | Go back to step 1. Something is wrong with the definition |

**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`