Skip to Content

Describing Your ICP to a Model

Outcome: a written ICP split into executable filters, research questions and exclusions, validated against your own customer list.

Surface
App and MCP server
Level
Intermediate
Uses
find_companies · enrich_organization
Credits
~5 for validation
Prerequisite
A list of your best customers

Why “describe your ICP” fails

Handed “mid-market B2B SaaS companies that care about data quality,” a model will produce something. It will guess at a headcount range, pick an industry tag, and silently drop “cares about data quality” because no filter expresses it.

You will get a list. You will not know which parts of your definition survived.

The fix is to do the translation yourself, in three buckets.


Three buckets

Filters — executable now

Headcount, country, founded date, funding stage and amount, industry, tech stack presence. These go straight into find_companies.

Research questions — executable later, per row

“Cares about data quality.” “Sells to enterprise.” “Has a partner programme.” No directory field holds these; a research agent answers them after sourcing, on rows that passed the filters.

Exclusions — the bucket everyone forgets

Current customers, open opportunities, competitors, partners, investors, companies you have contacted recently, industries you cannot serve for compliance reasons, regions you do not support.

Anything in your ICP sentence that lands in none of the three buckets is not a criterion. It is a preference, and it should be written down as such rather than quietly influencing the list.


Worked translation

The sentence: “Mid-market B2B SaaS companies in Western Europe that are scaling their sales team and take data seriously.”

ClauseBucketExecutable form
Mid-marketFilteremployee_count 50–500
B2BResearch”Do they sell primarily to businesses? B2B / B2C / Both / Unknown”
SaaSFilter + researchIndustry tag, confirmed by a research verdict
Western EuropeFilterExplicit country list — GB, IE, NL, DE, FR, ES, IT, BE, DK, SE
Scaling their sales teamFilter (signal)2+ sales roles posted in last 30 days
Takes data seriouslyResearch”Do they list a data or analytics tool in their stack, or a data role on their team?”

Six clauses, four filters, three research questions, and one clause (“takes data seriously”) that needed rewriting into something checkable before it meant anything.

“Western Europe” as a region string is a common trap. Region groupings differ between data sources, and a list can silently include or exclude countries you did or did not mean. Always enumerate the countries.


Validate against your customers

The check that turns an ICP from an opinion into a definition.

  1. Take your 20 best customers — by revenue, retention, or expansion, whichever matters to you.
  2. Run your filters against them.
  3. Count how many pass.
Pass rateReading
Above 80%The definition describes your business
50–80%One filter is too tight. Find it by removing them one at a time.
Under 50%The ICP describes who you want, not who buys. Rewrite it from the data.

Then run the same check against 20 churned or badly-fit customers. If they also pass, your filters do not discriminate — you need a criterion that separates good from bad, and it is usually a research question rather than a firmographic.


Writing it for a model

Once translated, the prompt is mechanical:

Using find_companies, source companies matching ALL of: - employee count between 50 and 500 - country in: GB, IE, NL, DE, FR, ES, IT, BE, DK, SE - industry: software / SaaS - posted at least 2 sales roles in the last 30 days Exclude any company whose domain appears in the attached suppression list. Cap at 200 companies. Return: company name, domain, employee count, country, roles posted. Do not enrich anything yet.

Note the last line. Sourcing and enriching are separate steps because the filter between them is where the money is saved.


Do this now

Write the ICP sentence

One sentence, as you would say it aloud.

Split into three buckets

Filters, research questions, exclusions. Every clause goes somewhere or gets deleted.

Enumerate every list

Countries, industries, stack items. No region strings.

Build the suppression list

Customers, open opportunities, competitors, partners.

Validate against 20 best customers

Count the pass rate.

Validate against 20 bad-fit customers

If they pass too, add a discriminating criterion.

Write the sourcing prompt

Filters only. Research comes after.


Check your work

  • Every clause of your ICP is in one of the three buckets
  • No region strings — countries are enumerated
  • The exclusion list exists and is loaded
  • Best customers pass at above 80%
  • Bad-fit customers fail at a meaningfully higher rate

Where this breaks

An ICP validated only against good customers cannot discriminate. Filters that admit 90% of your best accounts and 90% of your churned ones will produce a large, plausible list with the same mix of good and bad you already have — and no amount of downstream enrichment fixes it. The second validation run is the one that finds the criterion worth having.


Further automation

Re-validate quarterly. ICPs drift as the product changes and as you win in segments you did not plan for — and the drift shows up in the customer-pass-rate check before it shows up in pipeline. Lesson 07 uses the same customer set to source lookalikes rather than to validate filters.


Next lesson

07 — Sourcing lookalike accounts, using your best customers as the input rather than as the test.

Reference for this lesson: find_companies, Company, TAM Sourcing, MCP prompting guide.