8 Things 200 GTM Operators Told Us About Claude Code and Cowork

The survey: who answered, and how

I read a lot of vendor-sponsored "AI adoption" surveys that exist mainly to sell the tool they are measuring. This one reads differently. Kyle Poyar of Growth Unhinged and Maja Voje of GTM Strategist ran it independently, surveyed 200 GTM operators between March and April 2026, and published the breakdown with the messy parts left in, including the pain points, not just the wins.

The sample is GTM operators specifically, marketers, growth leads, RevOps, and founders running their own pipeline, not developers. That is the part that makes it relevant here. This is not "developers rate their coding agent," it is "the people running GTM motions rate the coding agent they picked up anyway."

Finding 1: adoption splits almost evenly three ways

Among respondents who named a primary Claude product, the split comes out close to even: Cowork around 32%, Claude Code around 31%, and Claude Chat around 30%. Nobody's running away with it yet. That is worth sitting with for a second, because the assumption going in was probably that Chat, the lowest-friction entry point, would dominate. It does not. A third of GTM operators in this sample picked up an actual coding agent, Claude Code, as their daily driver.

That is the headline that matters more than any single percentage: GTM people who are not engineers are choosing a terminal-native coding tool over a chat window, in meaningful numbers, on purpose.

Finding 2: productivity work dominates, but GTM engines punch above their weight

By raw adoption, productivity tasks lead everything, cited by roughly 80% of respondents, followed by content creation around 69%, product marketing around 64%, growth marketing in the mid-50s, and GTM engines or prospecting work around 54%. That ordering is not surprising, productivity tasks are the lowest-effort way to start with any new tool.

The more interesting number is impact, not adoption. When asked which use case delivered the single biggest result, content creation and GTM engines both punch above their adoption share, each cited by roughly a quarter of respondents as their top-impact use case, ahead of plain productivity work. Fewer people build a GTM engine with Claude, but the ones who do rate it as the highest-value thing they built.

Finding 3: content workflows are the daily habit that stuck

Within content, the ranked list of tasks GTM operators actually run is specific: social media posts (about 72%), websites and landing pages (about 66%), structured content pipelines (about 52%), SEO audits (about 38%), and traffic or performance analysis (about 34%). That is not a list of experiments, that is a list of recurring production work.

The pattern across all of it is the same: Claude is doing the first-draft-to-shippable-draft work, not replacing the person who decides what to publish. The respondents who reported the highest satisfaction were the ones treating it as a production tool with a human editor in the loop, not an autopilot.

Finding 4: 92% report time savings, which is the easy number

Time savings is the easiest metric for any AI tool to hit, and 92% of respondents reporting it is not, by itself, a strong signal. What is more interesting is the second number sitting next to it: 67% said Claude let them do something that was previously impossible for their team, not just faster, actually new. That is a materially different claim than "it saved me an hour."

On the GTM-engine side specifically, the most common versions of "previously impossible" were SDR research tooling built by non-engineers (about 79% of GTM-engine users built something in this category) and dynamic, segment-based messaging systems (about 71%). Those are workflows that used to require an engineer's time on the roadmap. Now they do not.

Finding 5: more than a quarter already replaced a paid tool

About 27% of respondents said they had already replaced an existing paid tool or vendor with something they built in Claude, and another 30% said replacement was coming soon. Put those together and you get a majority of this sample either mid-way through, or actively planning, a build-vs-buy decision against tools they were already paying for.

I would not read that as "every SaaS tool is doomed." Most of what gets replaced first is thin, single-purpose tooling: a scraper, a report generator, a Slack bot that pings on a signal. The tools that survive are the ones with real data moats or compliance surface area a script cannot replicate in an afternoon.

Finding 6: Claude Code users write far more context than Cowork users

Here is a finding that is easy to miss but useful if you are rolling this out on a team: 93% of Claude Code users reported writing detailed company or workflow context before using it, versus 72% of Cowork users. That gap tracks with what you would expect from the tools themselves, Code rewards upfront setup more directly than a conversational interface does, but it also means teams evaluating Cowork for its lower floor may be leaving real capability on the table by skipping the context-writing step.

The operators getting the most out of either product are not the ones with the cleverest prompts. They are the ones who wrote down, once, what their ICP actually is, what their brand voice sounds like, and what "good" looks like for their category, then reused that document every time.

Finding 7: credits, not accuracy, are the top complaint

This is the finding that should change how you plan a rollout. Ranked by frequency in the open-ended pain-point responses, the order was: credits and usage limits first, then memory limitations between sessions, then context window and token limits, then integration gaps with tools like Google Workspace and Salesforce, then hallucinations and inconsistent output, and last, weak team collaboration and skill-sharing across a team using the same tool.

Credit and usage limits led by a wide margin, with some Max-plan users reporting they hit restrictions two to three times a day. That ordering matters because most rollout plans I see budget time for prompt training and almost none for usage-cost governance. This survey says you have that backwards. Accuracy complaints came in fifth, behind cost, memory, context limits, and integrations.

Finding 8: the tools GTM teams still reach for alongside Claude

Claude is not replacing every tool in the stack, and the survey shows exactly which ones stay. The most-cited tools GTM operators still pair with Claude were ChatGPT (about 26%, mostly for a second opinion or a different model's output on the same task), Clay (about 21%), and HubSpot (about 19%), with LinkedIn and Apollo also showing up in the top five.

Read that list carefully. Nothing on it is a coding agent competitor. Claude is sitting on top of the data and distribution layer, not replacing it. That matches what I see with clients: the agent changes who can build the glue code, it does not remove the need for a real data source or a real sending infrastructure underneath it.

What this means if you are deciding whether to invest

If you are weighing whether to give a GTM hire real time to learn a coding agent, this survey is a reasonable data point in favor, with three caveats built into the plan from day one. First, budget for usage costs explicitly, do not assume a flat per-seat price covers real usage once someone starts building GTM engines instead of writing emails. Second, require a context document before rollout, the 93% versus 72% gap on Code versus Cowork users is really a gap in whether someone did the unglamorous setup work first. Third, expect the highest-value wins to come from a small number of ambitious builds, not from replacing everyone's daily busywork evenly across the team.

The honest failure mode is not "the tool does not work." It is a team that tries it on the easy 80% (productivity tasks) and never gets to the ambitious 23% (GTM engines) where the survey says the biggest wins actually live.

Where this fits into the stack I run

I do not use Claude Code to replace my sending or lead-data layer, and this survey's own top-tools list backs that instinct: Clay and HubSpot showed up next to Claude, not underneath it. My stack is Salesforge for sending and Leadsforge for lead data, and where a coding agent earns its seat is in the glue between them, the enrichment scripts, the routing logic, the reporting that used to sit on an engineer's backlog for a quarter.

That is consistent with what this survey found for the highest-impact respondents too: the win was not "Claude replaced my sending tool," it was "Claude let me build the thing that made my existing sending and data tools work together properly."

My honest take

The number I trust most in this survey is 67%, the share who say Claude let them do something previously impossible, because it is a harder claim to inflate than "saved time." The number I would plan around first is the credits complaint, because it is the one that will actually derail a rollout if nobody budgets for it. Everything else, the adoption split, the tool list, the context-writing gap, reads like a genuinely independent snapshot of a still-early market, not a vendor's highlight reel.

I have booked 2000+ meetings for B2B clients and I build my own GTM tooling with coding agents, so I read surveys like this one for what to change in my own process, not for a headline stat to repeat. This one changed one thing for me directly: I now write the context document first, every time, before I let an agent touch a new workflow.

FAQ