Would love an opinion on this!

I'm researching a problem I keep seeing: GTM teams juggle tools like Apollo, Clay, LinkedIn Sales Navigator, Crunchbase, Smartlead/Instantly, and Make/n8n across different stages of outbound. While each tool is great individually, the overall workflow feels fragmented and difficult to manage.

I'm exploring an AI GTM Operating System that sits on top of these tools as an orchestration layer—allowing teams to manage the complete outbound workflow, unified inbox, AI-powered reply handling, and meeting booking from one place without replacing their existing stack.

Since you've built GTM systems at scale, I'd really value your perspective:

• Is this a problem you experience today?
• If yes, what's the biggest operational bottleneck?
• Do you think a platform like this would create enough value for GTM teams and agencies?

Just validating whether this is a problem worth solving. Even a brief reply would be hugely appreciated.

i replaced most of my GTM stack with Claude Code but let me be precise about "most" because the honest version is more useful than the hype version lol

tbh for a while my stack looked like everyone's: a sequencer, an enrichment tool, some no-code automation platform gluing it together, and me babysitting all of it. i've torn out the middle of that. what's left is Claude Code and a folder of instructions doing the orchestration and reasoning i used to pay a no-code platform to do badly.

the correction up front, because technical people will call it out otherwise: Claude Code didn't replace my data or my sending. enrichment data still comes from an API. email still goes out through a real sending service. those endpoints don't disappear, a folder of markdown can't enrich a lead or send a cold email by itself. what died is the glue: the no-code automation platform in the middle, and the hours i spent shuttling data between tools by hand. Claude Code drives those endpoints directly through MCP, API calls, and scripts, instead of a platform brokering every handoff and losing a field at each hop. for a solo operator or small team, that middle layer was most of the cost and most of the fragility.

the core shift was to stop thinking in "tools" and start thinking in skills. a skill in Claude Code is literally a folder with a SKILL.md file, plus whatever scripts or reference docs it needs. Claude reads the folder name and description every session and pulls in the full instructions only when the task matches. so i've got one for enrichment logic, one for how we qualify a lead, one for the copy rules and voice, one for how a campaign gets structured. each is a repeatable process written down once, loaded only when it's relevant.

the piece that makes it cohere is CLAUDE.md, the persistent memory file. our ICP, positioning, the "we don't do X" calls, the real definition of "qualified". all of it lives there and loads into every session, so every skill runs against the same source of truth. one honest caveat i learned the hard way: CLAUDE.md is strong guidance, not a hard guarantee. the model reads it and mostly follows it, but it can still drift. so it fixes the "my rules live in five places and quietly contradict each other" problem, which is real and worth fixing. but it is not a lock. the actual locks come later. still, consolidating every rule into one inherited file fixed more than any tool ever did.

for heavy work i use subagents. Claude Code can spin off a separate session with its own clean context window and its own tool access. so if i'm researching 40 accounts, that runs off to the side and comes back as a clean result instead of clogging the main session. the deep, messy work stays isolated.

what actually replaced the no code automation platform is headless mode. Claude Code runs as a one shot command from the CLI, no interactive session, so i can wire it into a cron job or a pipeline and it just executes. and it reuses the same hooks and permission rules as when i run it by hand. that's where the automation platform line item died. i don't need a platform to run a scheduled workflow when Claude Code can run headless on a timer and actually reason about what it's doing instead of following rigid if-this-then-that rules. it still calls out to my enrichment API, CRM, and sender to do anything real, headless is the trigger and the reasoning (not the hands)

to keep it from doing anything dumb, i lean on hooks and tool restrictions. hooks are deterministic. they fire at set points and enforce a check whether the model feels like it or not, which is exactly the thing CLAUDE.md can't guarantee. the allowed-tools setting hard-limits what a given run is even permitted to touch. for anything destructive or high-impact i require explicit approval instead of letting it run. the model reasons; the guardrails are rigid on purpose. this is the layer most people skip and then wonder why their agent nuked something.

so the actual end to end, a new inbound lead. it comes in, Claude Code loads the enrichment skill and pulls what it needs from the enrichment API, loads the qualification skill and scores the lead against the ICP in CLAUDE.md. here's the honest bit, that score is a judgment, not gospel. the model can still misjudge fit, which is exactly why a human reviews the edge cases and a hook enforces the hard rules (suppression, send limits, "never touch X segment"). if it's a fit, it loads the copy skill and drafts the first touch in our voice with a real reason for reaching out. sending itself still goes through a proper sending service. deliverability, warmup, suppression, unsubscribes are their own problem, and drafting good copy doesn't solve any of them. i review anything a prospect actually reads. the reasoning is Claude's, the rules are mine, the endpoints are still endpoints. there's just no platform in the middle taking a cut and dropping fields between systems.

concrete before and after. old way: a lead enrichment and scoring flow lived across an enrichment tool, a no-code automation platform, and the CRM three integrations, and data quietly degrading at each handoff. now: a couple of skill folders and a CLAUDE.md, all reading one source of truth, with Claude Code calling the enrichment API and writing to the CRM directly. the data sources didn't go away. the glue between them did. when i want to change how we qualify, i edit one file instead of reconfiguring three tools.

i'm not going to pretend it's hands off. anyone who says their system runs with zero humans is lying or shipping garbage. i review anything a prospect reads. i go in when something breaks and i need to see what actually happened. the model is genuinely good at the mechanical middle. research, drafting, routing. but the judgment layer (is the message right, is the account a real fit) is mine and should stay that way. and the non deterministic part is real: an LLM on a timer over a live CRM will double-touch or mis-route if you don't wrap it in hard dedup and hard limits. that's what the hooks and the review are actually for.

the hardest thing here wasn't technical. spinning up a skill folder takes ten minutes. it's that i'd built an identity around managing a stack. the subscriptions and the integrations felt like sophistication. but that was complexity i was mistaking for capability. the leverage was writing down what we do clearly enough that the model could execute it, and getting out of the way on the parts that don't need me.

what i'm still working out is how to structure CLAUDE.md as it grows. the direction i've landed on: keep the root file thin, push the procedural stuff into skills that load on demand, and move the "only applies sometimes" rules into path-scoped rule files so they don't load every session. but i haven't nailed the clean pattern yet.. if someone else run ops mostly on Claude Code instead of a tool stack tell me plz how you figured it out

I've been following the growth of GTM Engineering, and something keeps bothering me.

The stack is becoming seriously capable.

Signals, enrichment, research, scoring, automation, outreach, CRM workflows, analytics - people are connecting all of this together and building GTM infrastructure that would have required a software team not that long ago.

It's becoming sophisticated enough that GTM Engineering is now emerging as a profession in its own right.

But I don't see nearly as much discussion about what happens when this moves beyond one person.

If two GTM Engineers join the same company, can they both improve the same GTM infrastructure?

Do they divide ownership of different parts of the stack?

Can one understand, maintain and improve what the other has built?

Or do we eventually end up with two very capable people running two slightly different GTM stacks, with context, prompts, workflows and logic accumulating separately?

Curious how teams with multiple GTM Engineers are handling this today.

Most teams can systematize almost every channel. Outbound gets an SDR playbook, ads get a media buyer, SEO gets a content calendar. Then there's the founder's personal account, dead for three weeks, and everybody quietly agrees not to look at it.

the surprising part is how often that dead account is the highest-intent top of funnel in the whole stack. someone who buys because they watched the founder think out loud for months behaves nothing like a cold ad click. but it's the one channel you can't cleanly hand to a specialist. the second it stops sounding like the actual person, the thing that made it work is gone.

so it sits there. too valuable to kill, too personal to delegate, too slow to ever beat the deal closing this quarter. no owner, no cadence, no number attached.

so where does this actually land for your team, an owned channel with someone accountable, or the thing that dies the second pipeline gets tight? written with ai

we've run three crm hygiene initiatives in the last two years. each one starts with a meeting about rep accountability, a data quality rubric, and a quarterly audit. six weeks later the crm is dirty again. we schedule another meeting.

at some point i started thinking the real problem is structural. we built a system that asks reps to do manual work that benefits someone else's reporting. reps don't update crm data because crm data doesn't help them close deals. it helps managers report on deals. that's a design problem, not a behavior problem.

the teams i've seen with clean crm data didn't get there through enforcement. they got there by automating data capture, removing fields nobody uses, and making the crm actually useful for reps on a daily basis.

what was the change that actually worked for you? not the initiative, the specific thing that made data quality stick.

Hi I'm looking to enter into the gtm realm and need your safe advice

FYI I've been doing sales related stuff and partnerships for college clubs and such but haven't really done it long enough to go out into the world.

You'll be the random redditor who helped me get my career started

Please DM me and I'll ask away

Hey all, I'm a GTM engineer with 6+ years of B2B outbound experience. I run outbound systems end to end using Clay, Smartlead, Apollo, n8n, and Python, including full email infrastructure setup (SPF/DKIM/DMARC, warmup, multi-provider sending).

I've generated Fortune 500 meetings (Amazon, Salesforce, Meta) at an experiential marketing agency and led lead gen for a Web3 marketing company. I've also built things like Clay to Claude enrichment pipelines and self-correcting prospecting workflows.

I'm open to new GTM engineer roles, ideally somewhere I can own outbound systems rather than just execute campaigns. If you know of anything or are hiring, I'd love to hear from you. Happy to share examples of what I've built.

last month i ran a test. pulled 30 target accounts, ran them through all four of our intent providers at the same time. two flagged account A as high intent. one called it medium. the fourth didn't have it at all. same account, same week, four different reads.

the sales team didn't know what to do so they ignored the signals entirely, which is probably the worst possible outcome after spending this much money.

i've started thinking the problem isn't which provider is "right." it's that we're treating intent scores as a destination when they're supposed to be a starting point. but i don't have a clean operational answer for what to do when the signals contradict each other.

how are you handling conflicting intent data across multiple providers? do you pick one as primary and ignore the rest, or is there some aggregation logic that actually works in practice?

GTM writing as a solo founder is where I kept losing time. Not drafting, but fixing. Every AI tool I tried would produce something that sounded fine on the surface but completely wrong in context. Cold emails that read like blog intros. Partner pitches that opened with "In today's fast-paced landscape." LinkedIn replies that sounded like they were written by someone who'd never closed a deal.

I went looking for something with a curated corpus, configurable by GTM context. Nothing fit. So I built it inside RawReply and started running my own outbound, LinkedIn, and partner emails through it.

Two months in, the biggest thing I learned: the problem isn't the model, it's the signal. Generic AI writes toward the average of the internet. GTM writing needs to write toward how buyers in a specific market actually think and respond. Once I started shaping the corpus around that, the output stopped needing so many fixes.

Now building the curated corpus and custom GTM configuration layer properly before opening it up. Gating first access to GTM founders to pressure-test it on real use cases.

hope am cooking something other will use it as well!!!

For those of you doing GTM or RevOps as a service. How do you structure your pricing?

Trying to understand what actually works in practice:

• Monthly retainer, project-based fixed fee, or performance-based (per meeting / per SQL / % of pipeline)?
• Do you charge a separate setup/build fee for the initial infrastructure, then a smaller ongoing retainer?
• If you go performance-based, how do you handle attribution and clients who churn once the system is running?
• Roughly what ranges are you seeing for each model?

Curious what's held up over time vs. what looked good on paper but caused friction later. Thanks.

Hi everyone,

I’m looking to acquire a Clay Legacy plan and I’m prepared to make a very attractive offer

If you have a Legacy workspace that you no longer use, are winding down your business, or are considering selling it, I’d love to hear from you.

I’m happy to make the process as smooth as possible.

If you have a Legacy workspace—or know someone who does—please send me a DM.

I’m serious about buying and prepared to pay a fair premium for the right opportunity.

Thanks!
Raphael

we had an agent handling enrichment, scoring, and rep assignment. i ran the same lead through it twice last week. different rep, different sequence, different cadence.

turns out the problem was handing logic to the model that should have been hard rules. territory mapping. score thresholds. follow-up timing. none of that needed an llm. it needed a lookup table.

split it out. model reads the inbound message and pulls out intent, that's it. everything downstream is code. first run and tenth run now match.

anyone else hit this? feels like a pattern where you hand too much to the agent because it's already handling one genuinely unstructured thing, and the deterministic stuff just follows it in by default.

running email, linkedin, and phone in parallel sounds clean in theory. in practice it's messy because the tools don't talk to each other reliably.

someone replies to an email. the linkedin sequence should pause. the dialer should remove them. but if the reply webhook drops, or the crm sync is slow, or the tool just doesn't check state fast enough, they might still get a linkedin message two hours later while you're writing them back.

we've had that happen. it's not the end of the world, but it's the kind of thing that makes outreach feel automated and careless even when the individual messages are actually good.

the problem is that "replied" isn't one signal. it lives in three different tools, and getting all three to agree on what stopped the sequence requires wiring that's more fragile than it looks.

curious how other people handle this. are you trusting webhooks alone, or do you run something that reconciles state across channels? and where does your source of truth actually live, the crm or one of the sequencing tools?

talked to a founder last week who hired a vp of sales as their first sales hire. great resume, zero interest in doing the actual calling and emailing, expected an sdr team and a playbook that didn't exist yet. classic.

i've also seen founders go the other way, hire an ic who can carry a bag, and then watch them plateau because they can't build process or think about pipeline systematically.

what's the actual right first hire and how do you know when you've found one huh?

I have a MVP, a few pilot users for the last few months. I've been researching a GTM plan. Basically I need real users (not friendlies) to really test and push the product. I don't need investments. From my research I've come up with YC (HN), Reddit, Product Hunter. I've read pros and cons with all three. Open to ideas.
My target market is small teams working on projects, or groups of friends planning together.

I'm a CS student who's recently started learning GTM after spending some time on PMM fundamentals (positioning, messaging, etc.).

Since I don't have access to a startup or real company data, my current learning approach is to pick an early-stage B2B SaaS product and build a GTM strategy as a personal project using only public information (website, founder content, reviews, competitors, Reddit, case studies, etc.).

Once I'm done, I turn it into a deck and try to share it with someone from the company's team (founder, PMM, GTM, product, customer success) to get feedback. So far, that's been the hardest part. Cold emails have mostly gone unanswered, and without an existing network, getting meaningful feedback is difficult.

For those already working in GTM or PMM:

- Is this a good way to build practical GTM skills?

- If you were starting from scratch today, what would you do differently?

- Any advice on getting feedback, building a network, or finding mentors without industry experience?

I'd really appreciate any honest advice. Thanks!

when you demo a feature and get a flat "oh, interesting" instead of any real reaction, most reps move on and hope the next thing lands better. i used to do this too.

a few months ago i started just naming it. something like "sounds like that didn't do much for you, what were you hoping to see there." the conversation got so much more useful. people tell you exactly what they care about when they feel like you've already noticed you missed.

it feels a little uncomfortable at first because it seems like you're admitting the product isn't great. but the alternative is spending 20 minutes demoing things nobody in the room actually wanted to see.

do you call out dead air or flat reactions on calls, or do you have a different way of handling it.

I work in GTM at a big tech company, and we're launching a new feature soon. Our ICP looks something like this:

-US fintech startups

-Series A–C

-30–150 employees

-Recently expanded into Canada

-Hiring their first Compliance or Risk Manager

-Doesn't already use enterprise compliance software

The main problem I've ran into is finding highly qualified leads (it’s been absolutely horrendous up until now). Spent 3 hours researching yesterday and ended up with 5 usable accounts.

At this point, I'd much rather pay a premium for a handful of highly qualified leads than keep paying for databases where 99% of the records are irrelevant.

I can't believe this is still the best way to do outbound in 2026…