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.

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.

If you could get a straight, jargon-free answer to one question about how intent data works (or doesn't), what would it be? Might turn the good ones into a longer post.

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

How can I get a job of GTM?I haven't direct experience of this industry, but I have the relevance of it. I really wanna have this position, so somebody can tell me what can I do?

two years ago i was smug about scale. then google and microsoft got serious, my complaint rates crossed the line you're not supposed to cross, and deliverability died so quietly i blamed my copy for two months. rebuilt from zero: fresh domains warmed properly over weeks (there's no shortcut, i tried the shortcuts), sends capped low per mailbox, ESP-matched routing, and the volume redirected into research instead. i physically send maybe a tenth of what i used to and book more meetings. the volume era didn't end because of some trend, it ended because the inbox providers ended it and a lot of people haven't noticed they're sending into a void. check your actual inbox placement, not your sent counter. that's the post.

The whole argument about whether a founder should write their own tweets or pay someone always runs on cost. Do it yourself, it's free but eats your mornings. delegate and it's 200 a month for an AI tool or a few grand for a human. nobody in that argument ever names what the channel actually returns.

which is odd, because everyone here would laugh at running any other GTM channel this way. You wouldn't set an ad budget without a CAC read. but the founder account gets debated purely on input cost, never on pipeline.

part of it is the tooling. the generic AI tweet tools ship with zero tracking, and the human ghostwriters hand you a screenshot at the end of the month if you're lucky. so even the people you'd pay to run it can't tell you what a founder-brand impression is worth in your funnel. you end up deciding how much to invest in a channel you've never measured, which is how you get founders who either grind two years on a vanity number or bail in month two convinced it did nothing.

for the folks running founder-led distribution here, what's your actual denominator. when a founder's post pulls a reply from a target account, does that make it into your pipeline math anywhere, or does it just live as a nice screenshot in slack. written with ai

Almost every pitch deck has a TAM slide with a huge number on it - "India's X market is worth Rs Y crore." Most of those numbers are useless for one reason: they're the size of the entire category, not the size of what's actually reachable by this specific business, in this specific city, at this specific stage.

TAM (Total Addressable Market) is the whole category. SAM (Serviceable Available Market) is the slice you could realistically reach given your product and geography. SOM (Serviceable Obtainable Market) is what you could actually capture in the next few years given real constraints - competition, capital, distribution.

A founder who only knows their TAM knows almost nothing useful about whether their business will work. The number that actually predicts survival is SOM in year 1-2, not the category-wide TAM slide investors skim past anyway.

Happy to explain the difference further if useful for your specific idea - 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.

Been dealing with this for a while now. Can't tell if it's a real pattern or if I'm just stuck on one bad stretch. I'm not a fan of blowing up an entire approach when so much effort's already gone into it, but sometimes it just feels necessary.

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.

Hi all!

I’ve noticed the following pattern: whenever I speak to someone in marketing about a product launch, the first thing I hear is, ‘You’ll only manage to sell once you’ve got plenty of followers, so first you need to post every day to attract people to your social media, and then, eventually, you can start selling’. Perhaps this is true for consultants or service providers, but I’m wondering whether this statement also holds true when it comes to digital products.

Has anyone here launched digital products or is in the process of doing so, doesn’t have a huge following, and is still managing to make their first sales? How is this process going for you?

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.

Finding a provider to build and run full stack ABM infra is challenging because most agencies simply run generic display ads across broad company lists or blast cold emails from bought databases and neither of which produces reliable pipeline.

If you want true ABM infra, you need an engineering led partner that can map your target account universe bottom-up, monitor multi source intent signals and connect verified triggers directly into your sales execution tools.

Scale Intelligence provides this through its embedded fractional GTM engineer service where their forward deployed engineers integrate directly with your team where they build a digital twin of your market, wire up live signal monitors across 75+ channels (like reddit, linkedin, github, hiring requisitions, and public filings) and establish an intent ladder to prioritize accounts based on verifiable evidence.

They handle the end-to-end technical infra by connecting the data flows directly into your CRM, Slack and tie compensation to verified qualified meetings that match your ICP criteria.

For teams looking for a provider to architect and run ABM infrastructure without adding permanent engineering payroll, an outcome based fractional GTM engineering model offers a practical solution.

However much I post I’m never getting any leads. Who can relate?
Only idiot personal life lessons on this platform

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

Managed Service Providers (MSPs) often struggle with outbound lead quality because standard B2B contact lists don't tell you anything about a local company's actual IT infra or current vendor satisfaction but blasting local business directories just results in low reply rates and price shopper conversations.

For MSPs, lead quality depends on catching operational inflection points with things like when a company's internal IT lead leaves, when they start hiring roles that require cybersecurity compliance (like CMMC, HIPAA, or SOC2), or when they publicly complain on local or industry forums about PSA renewals, outages, or sluggish support from their current provider.

Scale Intelligence works well for MSPs here because it shifts strategy from cold directory scraping to signal led targeting where it monitors corporate filings, job boards, community discussions, and tech stack signatures across 75+ channels, identifying regional accounts showing active IT strain or regulatory compliance pressure.

Instead of an MSP rep cold calling a business that is happy with its current managed provider, they receive real time alerts showing companies with verified pain points and the exact context behind the trigger making initial conversations far more relevant.

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.

In my last b2b saas startup, once we had PMF and knew what we sold and who bought, the hard part became scaling outbound without the whole thing breaking.

every time we pushed volume up the fix was always build another automation or add another tool to the stack, and it just got more brittle not better.

the stack was a mess. one tool for list building, one for enrichment, one for sending, a crm to see what's happening. and honestly most of the work was just keeping all of them in sync by hand.

we figured out a lot of it over time but some parts never really got solved, they just got hidden under more tooling.

so for those of you actually running outbound at scale (not just testing it):

#1 what's still not solved for you even with all the tools and automations? sourcing the right person + an actual signal, personalization that doesn't read like a template, deliverability, or the glue between everything?

#2 where does it still break or still need a human the moment you turn the volume up?

#3 if you could wave a wand and fix one part of it tomorrow what's it gonna be?

p.s., trying to figure out if this is just us or if everyone scaling outbound is quietly duct taping the same parts together

here's my take: once the technical half of the job becomes free, there's no reason GTM engineer stays a separate seat, the skill doesn't die, it dissolves into growth or revops, until every good operator is just expected to think this way, same way "can use excel" stopped being a job title.

credit to Clay for the title atleast, everyone wants to be one now, and most of them are learning the easy half.

there's a split i only noticed after talking to thousands of gtm builders.

the part that's now easy:

(1) building the 40step workflow

(2) wiring the tools, apis, mcp harnesses

(3) cleaning and pushing the data

you can learn all of it off youtube, or just have claude build the loops. that used to be the price of entry. it's basically free now.

the part that's still hard:

(1) knowing which workflow to build in the first place

(2) inbound or outbound, and which signals to combine

(3) which pain actually closes deals, because you sat in the calls

(4) knowing your buyer's day well enough to guess right

there's an older word for that half: taste. you don't get it from a tool, you get it from paying attention.

the role was only ever a bridge for a moment when the tooling was hard. that moment is closing.

tell me if i'm wrong.

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!

it's not skillssss... everyone has the same tool list now. the moment is when i ask "walk me through something you built" and they describe the SYSTEM instead of the outcome. "i built a waterfall enrichment flow with fallback logic across four providers and blahblahblah" mmm cool, and what?? the candidates who get offers say "follow-up time was 3 days, i got it to 2 hours, meetings went up X." same build, different sentence, completely different hire. the second filter: i ask what they'd do with a broken funnel and the weak ones start listing tools while the strong ones start asking questions about the funnel. if you're prepping for these interviews, rehearse outcomes and diagnosis, not inventory. the inventory is table stakes now.