CLAUDE CODE FOR MARKET RESEARCH
Claude Code for market research
Market research runs at two speeds in most marketing teams. There is the annual project that produces a deck nobody opens by month four, and there is the Slack thread where somebody needs a competitor's pricing before a call in twenty minutes. Claude code market research work sits between those two, and it closes the gap by making research something that runs on a rhythm instead of something you commission. Claude Code is Anthropic's agentic command-line tool (Claude Code docs); it reads the public pages you point it at, reads the files and exports sitting in your repo, connects to your own systems through the Model Context Protocol, and writes findings back as files your team can read, diff, and quote. The unit of value is a research skill you own: fixed sources, a fixed rubric, and an output file shaped the same way every run, so the September teardown and the March teardown compare line by line instead of vibe by vibe.
What Market Research Can Claude Code Handle Well?
The research tasks that suit an agent share three traits: the sources are bounded, the question is the same every time you ask it, and the output has a shape you can specify in advance. That covers more of the research calendar than most teams expect.
- Competitor teardowns from public sources: homepage, pricing page, docs, changelog, and job postings read together, summarized against the same rubric each month.
- ICP research: closed-won and closed-lost lists turned into a profile with firmographics, trigger events, the titles that sign, and the objection that ends deals.
- Review mining: hundreds of public reviews read for the phrases customers use, the features that draw complaints, and the switching reasons that repeat.
- Pricing page tracking: a monthly snapshot of tiers, limits, and packaging across your set, with a diff that names what moved since last time.
- Win and loss synthesis: call notes and interview transcripts read as a set, clustered into themes with the supporting quotes attached to each one.
- Survey open-ends: free-text responses coded into categories with counts, so the qualitative half of a survey stops being the part nobody reads.
Each of those becomes a file in your repo rather than a document in someone drive folder. That distinction matters more than it sounds: a file the agent can read is an input to the next piece of work, so the teardown you ran in September feeds the messaging refresh in October without anyone re-reading it.
One caution about fit. Research that turns on private conversations, on judgment about a category nobody has written up yet, or on reading the room in a customer call sits outside this list. The agent covers the gathering, the reading, and the structuring. The parts that need a person in the room stay a person job, and pretending otherwise is how teams end up confident about a market they have never spoken to.
How Do You Build a Research Skill?
A research skill is a set of instructions for one recurring question, saved where the work happens. Four parts make it repeatable, and the discipline is in defining them before the first run rather than after the third disappointing one.
| Part | What you define | Why it matters |
|---|---|---|
| Inputs | The question, the named subjects, and the time window | A vague question returns a vague answer; a named list returns a comparable one |
| Sources | The exact pages, exports, and connected systems allowed | Bounded sources are what make two runs comparable and every claim checkable |
| Rubric | The same dimensions, assessed the same way, every run | Consistency is what turns a one-off report into a trend line |
| Output | One file, fixed sections, sources cited inline with dates | A file your team reads, diffs against last month, and quotes in a doc |
Sources are where the system earns its keep. Claude Code fetches the public pages you allow, reads exports you drop into the folder, and connects to your own tools through the Model Context Protocol, an open standard for wiring an agent to external data (Model Context Protocol). Point the skill at your CRM for closed-won data, your support tool for ticket themes, and a fixed list of URLs for the competitive set, and the same run pulls all three.
The skill itself is a folder with a SKILL.md file holding the instructions, plus reference files such as your rubric and your list of subjects. Project skills sit in a .claude/skills folder in the repo, so they are version controlled and every teammate runs the identical rubric. That is the difference between research as a person and research as a process: when the analyst is on holiday, the September report still looks like the August one.
Start narrower than feels satisfying. A skill that tracks four competitors across five pages each will still be running in a year. A skill that tries to cover the whole category on its first pass produces a report nobody finishes and a rubric you quietly abandon by run three. Add subjects and dimensions once the run is boring, because boring is the sign it has stabilised.
What Does a Monthly Competitor Teardown Look Like?
Here is the whole run for a teardown that publishes on the first Monday of every month, written as a skill you trigger by name.
- A fixed subject list: four competitors, named in the skill, so the set stays stable even when a loud new entrant shows up in your feed for a week.
- A fixed page set per subject: homepage, pricing, docs, changelog, careers page, and the last two months of their blog. The careers page is the underrated one, because the roles a company is hiring describe what it is building next.
- The same rubric every run: claimed positioning in their own words, the audience the copy is written for, packaging and price points, the proof they cite, and the gap they leave open.
- A diff against last month: the skill reads the previous file and calls out what changed, such as a new pricing tier, a rewritten headline, or three roles posted in a region they were ignoring.
- Sources inline: every claim carries the URL and the date it was read, so anyone reading the file can check the line rather than trust it.
- One output file, committed: written into the repo, so the history of a competitor positioning becomes a git log you can scroll.
The first run takes an afternoon, because that is when you write the rubric and argue with yourself about what belongs in it. The twelfth run takes minutes and is worth more than the first, because by then you hold a year of positioning changes in one comparable format. Marketers running teardowns this way report cutting a multi-hour manual sweep to well under an hour; treat that as a practitioner field report rather than a promise, since it depends on how many subjects you track and how stable their sites are.
How Do You Keep the Sourcing Honest?
Research is the area where a fluent wrong answer does the most damage, because the output travels. It lands in a battlecard, then a sales call, then a customer inbox. Five rules keep the system trustworthy, and they belong in the skill file rather than in your head.
- Primary sources for every fact: the pricing page, the changelog, the docs, the filing. Press coverage is a pointer toward a primary source (SEC EDGAR holds the filings for public companies).
- A link and a date on every claim: pricing moves, positioning gets rewritten, and a claim without a date carries an expiry nobody can see.
- Observed separated from inferred: the report marks which lines are quoted from a page and which are the analyst read, so a reader knows what they are trusting.
- No number without a source: market sizes, headcounts, and revenue estimates come with a link or they come out of the report.
- A spot check before it travels: pull three claims at random and verify them by hand before the file reaches a sales team.
The honest limits sit right next to those rules. A model writes an equally confident paragraph about a market it misread, so the prose gives you no signal about accuracy. Public pages tell you what a company claims, and customer conversations tell you what is true; the second one stays a human job. Deciding which gap is worth attacking and which competitor to ignore is strategy, and a rubric cannot make that call for you. Anything that reaches a customer-facing asset needs a named person accountable for it being right.
Used that way, the agent takes the reading, the gathering, and the formatting, and hands you back the part that needs your judgment. That is the trade worth making, and the sourcing rules are what keep it from turning into fast nonsense.
How Do Research Outputs Feed Positioning, Content, and Outbound?
A research file that sits in the same repo as your other marketing systems stops being a deliverable and becomes an input. Everything downstream reads it, which is where the compounding shows up.
- Positioning and messaging: the teardown supplies the claimed positioning of every alternative, so the difference you assert is one you can defend in a room.
- Content: review mining hands you the exact phrasing customers use, which becomes headlines, briefs, and objection sections. See Claude Code for content marketing.
- SEO: the gap analysis feeds a brief queue ranked by what your competitors rank for and you do not cover yet. See Claude Code for SEO.
- Outbound: ICP research and per-account notes feed personalization at volume rather than one flattering sentence per email. See Claude Code for outbound.
- Paid: competitor ad angles and the objection language from reviews give you the variant axes worth testing this quarter.
One research file feeding four systems is the argument for keeping research in the repo. Update the file and every system downstream starts working from the new picture on its next run, without a round of forwarded documents and a meeting to explain what changed.
The other direction matters as much. When outbound replies surface an objection nobody had written down, that goes back into the research file, and the next teardown looks for it in competitor copy. The loop closes when your systems write to each other instead of only reading, and that is the point where research stops being a project and starts being infrastructure.
Where Does the Workshop Fit?
The first research skill is the hard one. Writing a rubric that survives twelve runs, bounding the sources properly, and shaping an output your team reads takes a couple of attempts alone, and the second attempt is much better than the first.
Claude Code for Marketers (CC4M) is a live workshop where marketers build go-to-market systems in their own repo and keep them. It is taught by Hank Taylor and Mitchell Wright, operators who have built GTM at GitLab, Vercel, Laravel, Neo4j, and ClickHouse. It runs as one live five-hour session, with two office-hours sessions afterward. In it you build four working systems: a UTM Builder, a Content Engine, an AI SDR and outbound flow, and Automated Ad Generation, and the research patterns above feed directly into the outbound and content builds. No coding background is assumed. Private and team cohorts are available on request. For the full picture of the tool, read Claude Code for marketers.
Questions