AI Makes Execution Cheap. Customer Understanding Is the GTM Moat.

Jordan Crawford's 2026 stack can enumerate a market, research companies, enrich contacts, and draft campaigns quickly. But his core GTM claim is not about the stack: advantage comes from knowing a narrow customer well enough to identify who has the worst version of a problem, then using tools to repeat that research without discarding its source judgments.

Jordan Crawford, interviewed on FullEnrich, The best GTM engineer in the world explains his 2026 tech stack (50 minutes). YouTube source EZpoQ8gT02E.

The $67,000 bill that was not $67,000

While analyzing a client's Anthropic usage, Crawford queried its spend API and read a cents-denominated value as $67,000. He panicked and emailed Dario Amodei before discovering the unit error. He later describes the real spend as roughly $600 over six months, although that timeframe does not reconcile with his earlier reference to $67,000 over three months; the anecdote therefore supports checking units and scope, not an exact conversion.

It also explains the metric Crawford uses for his research systems: the lowest cost per right answer. Cheap retrieval matters only when the answer survives verification.

The stack is not the advantage

The host introduces Crawford as someone many people call "the best GTM engineer in the world." Crawford says 100% of his work now happens inside Claude Code. He uses it to orchestrate research, APIs, local scripts, and subagents; he also sells Edge Co-Pilot for $2,500 a year and advises companies on this operating model.

Yet his first principle is almost anti-stack. GTM advantage comes from information asymmetry: the accumulated knowledge that lets a company understand customer 1,001 better than that customer has articulated the situation themselves.

He mocks the opposite kind of outreach with a line that deserves to survive every personalization trend: "The biggest problem is that my money is trapped in your wallet." Add a scraped compliment such as "Hi Tim, congratulations on being named Tim," and the message remains about the seller.

Useful outreach starts when the seller can show why this account has a particular version of a problem, what it costs, and what evidence supports the diagnosis. Copy comes later.

Narrow markets make learning compound

Crawford's argument for vertical focus is not merely that a niche is easier to target. It creates a bounded learning system. If one conversation is with an auto-shop owner, the next with a GTM engineer, and the next with a plumber, the operational details fracture. When successive customers share the same work, each conversation improves the next.

He gives two extreme examples. A would-be dental-billing founder reportedly worked for free for six months and claimed to have filed 5,652 instances of one procedure code. A permit-intelligence founder reportedly interviewed 1,000 city and state officials, stopping only when she knew what they would say before they said it. Crawford says the second company grew through referrals and was closing a multimillion-dollar statewide agreement. These are self-reported anecdotes, and the procedure-code caption may be wrong. Their function is to describe a standard of immersion.

The founder is not trying to learn "healthcare" or "government." They are learning a recurring job deeply enough to recognize exceptions, source quality, hidden constraints, and the language practitioners use when nobody is selling to them.

A vertical does not become attractive because its label is specific. It becomes attractive when every new observation updates the same model.

The message is targeting rendered as prose

For a company that already has customers, Crawford starts with the people receiving absurd value. Who pays $100 a month and gets $100,000 a month back? Build a dossier from CRM history, customer statements, and product behavior. Put it on a timeline. Then ask which customer has the worst version of the problem.

His contrast is deliberately dramatic. A hospital facing a hypothetical $500,000 repeat surgery has a more consequential problem than a podiatrist receiving ten after-hours calls. The job is to translate that severity into an observable selection criterion.

Crawford improvises a healthcare message around 425 heart surgeries, a 10% return rate, and five emergency rooms that reduced incidents to zero. He immediately says, "I'm just making stuff up. I'm not a doctor." The figures should not travel outside the example. The structure should:

1. Identify a condition visible in internal or external evidence.
2. Connect it to a consequence the buyer cares about.
3. Show a believable outcome and why it should transfer.
4. Offer something useful before asking for a meeting, such as the three screening questions a hospital could use.

His compact formulation is better than most copywriting frameworks: "The message is just a re-descriptioning of the targeting." If the research has identified a severe, observable problem, the message can state what was found. If the copy needs a clever hook to manufacture relevance, the diagnosis upstream is probably weak.

Zero data means earning data

Asked how a pre-seed company with no customer data should approach GTM, Crawford does not begin with an outbound campaign. He begins by narrowing the market and interviewing prospective buyers until the founder can describe their existing workflow and its failures.

His example begins too wide: "AI agents for bookkeeping." Narrow it to a job and a market: close the monthly books for plumbers. Then talk to roughly 100 plumbers and pay them if necessary. Ask how the work happens now, what the next-best alternative is, where it breaks, and what language they use. Do not pitch.

The plumber details he imagines, including joint inventory and time accounting, are speculative. That is the point. A founder should discover which details are real before building the product or the campaign.

Crawford describes a dishwashing-robot company that struggled with restaurants, then focused on specialized dishwashing hubs and reportedly booked about seven meetings from ten messages. The copy was bad and almost purely descriptive. The market shift did the work.

"If go to market is hard for you, you're too wide," he says. It is a useful diagnostic, not a law. A narrow product can still fail because it is weak, expensive, mistimed, hard to trust, or painful to adopt. But a company that cannot name a recurring workflow will not solve that problem by sending more messages.

Claude should compile a research method, not invent one

Crawford's local-business workflow runs backward from known-good records. Start with perhaps 50 verified customers whose owner, email, and phone are known. Ask deep-research tools where each fact could have been found publicly. Repeated source classes become the seed set. He describes discovering a Florida database with dentist records and giving Claude roughly ten good sources from which to build forward.

If no seed set exists, he recommends manually researching 10, 20, or 50 leads while recording the screen and narrating the trust decisions: why this PDF is credible, why that page is stale, and why one owner match is stronger than another. The recording is not merely a tutorial. It is the trace from which an agent can abstract the method. In one example, the work reveals that a state dataset can be purchased directly for $100.

His Claude Code practice follows the same pattern. He speaks rather than types because typing encourages self-editing. He asks Claude to request missing information. He researches first, then forks a subagent with the assembled context. He structures instructions as if teaching an adult clone who has no background knowledge: define the object, locations, validation rules, and patterns.

The guardrails come from failure. Bypass-permissions mode once deleted his home folder. He now uses auto mode and hooks that stop remove or publish operations. He is comfortable orchestrating 100% of his work through Claude Code, but refuses to let it update an entire CRM unchecked because it makes mistakes.

Cost per right answer is an escalation ladder

Crawford does not provide a fixed vendor ladder, but his examples establish an escalation rule:

That is why cheap data changes his targeting strategy. Blitz can pull a broad universe of sales and marketing titles, after which the system disqualifies and ranks. The problem definition stays narrow while candidate retrieval becomes broad. Crawford contrasts this with the arbitrary "50 to 200 employees" ICP: a CEO does not hire employee 201 and suddenly acquire a different accounting problem.

Behavioral evidence can be more useful. Crawford relays one customer's preference for procurement leaders who change roles within two years rather than those who have stayed for 25. Exa's Websets product can search a large profile index semantically, while Parallel offers entity resolution from company names to domains. FullEnrich handles email and phone enrichment; Crawford discloses that he is an investor, adviser, and user. Open Web Ninja provides structured endpoints for reviews, maps, contacts, and commerce data. Apify offers scraping tools and residential proxies for harder sites. Crawford also uses code-pattern matching on downloaded HTML before escalating to a model.

Crawford estimates that a whole addressable market can be enriched for under $500, perhaps $500 to $1,000 excluding cellphone numbers. He claims local downloading can cover about 80% of a market and Apify can help with the Cloudflare-protected remainder. These are useful operating claims, not benchmarks supplied with error rates.

The right-answer problem does not end with retrieval

The episode contains several tensions a tool tour would miss. Crawford promotes tool agnosticism while investing in or advising Clay and FullEnrich and selling his own product. He praises Claygent's research quality but says its then-manual prompt-editing tax outweighed the quality gain. More directly, he recommends ChatGPT or Claude deep research and Claude Code for discovering sources, then later says he would "never use Claude or OpenAI's models for doing search." He does not define a boundary that reconciles those statements.

More seriously, customer empathy sits beside aggressive data collection. The same workflow that aims to send messages a recipient would be proud to receive can aggregate public records, enrich cellphone numbers, scrape sites, and inspect client APIs. Crawford offers a broad reading of U.S. scraping law for public pages not behind login. That is not legal advice, and it does not settle terms of service, privacy regimes, copyright, database rights, or ethics.

The "cost per right answer" metric is sound only if rightness is measured. The interview does not provide audited precision, recall, or source-error rates for the 316-government-source agent Crawford describes. A cheaper wrong answer can be more expensive once it enters targeting, messaging, or a CRM.

Why this matters for Diffie

The interview contains no discussion of Diffie, so this application is a hypothesis rather than Crawford's advice. If Diffie is positioned broadly as AI browser testing for frontend engineers, his framework would force a narrower question: which repeatable team workflow produces a costly, observable browser failure that Diffie can already reproduce and verify?

Build dossiers before buying a larger list. Combine the strongest users, lost conversations, support threads, reproducible bugs, and product usage into timelines. Look for teams where browser regressions delay frequent releases, escape into production, or require expensive manual replay. Do not count every React team as evidence. The analogy to a costly surgery breaks because frontend-regression cost is diffuse, and the person feeling it may not own budget. Customer language and workflow consequence matter more than a synthetic dollar figure.

Make outbound re-describe observable release risk. Useful signals may include release cadence, a large frontend surface, multi-browser commitments, public incidents, design-system work, QA hiring, or visible Playwright/Cypress maintenance. Those signals prove complexity, not dissatisfaction. The message should present the observation and offer a narrow artifact, such as a reproducible test plan, rather than claim to know the prospect's pain. Testing a private or authenticated application without permission would cross a boundary; public evidence does not grant operational consent.

Use interviews to select one wedge. Ask frontend engineers, QA owners, and engineering leaders separately about the last browser-specific defect: who found it, how it was reproduced, whether it delayed release, what the existing suite missed, and what counted as verified. A candidate wedge might be reproduction and verification of cross-browser UI regressions. It remains a hypothesis until the same costly workflow appears across several teams. "Frontend engineer" alone does not create homogeneity; framework, application state, CI, browser matrix, and team maturity vary sharply.

Optimize for cost per verified bug, not agent activity. Start with deterministic DOM, console, network, screenshot-diff, and browser checks. Escalate ambiguous states to vision or language models. Preserve the evidence and require approval before filing an issue or changing code. Here Crawford's enrichment analogy breaks again: an email address has a discrete ground truth, while a browser failure can be stateful, nondeterministic, environment-specific, or subjective. Diffie must measure reproducibility and missed regressions, not only the cost of producing an answer.

Speed moves the bottleneck backward

The practical test is simple: before scaling a campaign, can the team name the recurring workflow, identify who has its worst version, show how that condition was observed, and explain why the evidence is trustworthy? If not, faster execution will only produce more unsupported messages.