Christ First | AE @Airtable | Host - MSP Revenue Secrets

Rhondre Giscombe

I've been studying GTM engineering workflows in my free time.

Across the stack, I'm seeing three layers:

And across the stack it’s Three Layers.

Layer 1: Data
Your CRM. Data warehouse. Product usage data.
The foundation every software company has.
Mostly accessed by Data, Engineering, and some GTMEs.

Layer 2: Intelligence
Where orchestration happens.
Accounts get enriched, scored, routed.
Messaging gets prepped. Emails drafted.
This is where RevOps, Marketing Ops, Sales Ops, and GTMEs live.

Layer 3: Engagement
Where reps actually work.
Most salestech is fighting to own this layer.

I use five tools daily: Airtable, LinkedIn, Outreach, Claude, Salesforce.
Trying to get it down to three. Ideally one.

Here's the thing: the better my intelligence layer works, the less time I waste figuring out who to talk to and what to say.

Intelligence feeds me the signal. I send smarter outreach. That becomes pipeline. That closes.

Am I thinking about this right? What am I missing?

Would love to hear from folks building or operating in this space.

brendan short Brandon Smith Chris Balestras Joe Rhew

Disciple of Christ | GTM @Airtable | Building apps & agents for Operators

I've been trying to understand how Claude Code impacts GTM work. Still early in my research, but one thing keeps standing out.

The compounding intelligence piece.

From what I'm seeing, it's not just about build speed. It's about how context accumulates over time.

Feed it call transcripts and it updates your ICP definition. Feed it more data and it refines what you thought was true. It challenges your assumptions and suggests new angles you might have missed. The system doesn't just store information. It iterates on what you know.

A few other initial observations:

1️⃣ The build speed is real. Clay tables, n8n workflows, JSON configs all ship noticeably faster.

2️⃣ Every Claude Code project pulls context from markdown files. ICP definition, messaging framework, competitor intel. Modularizing your GTM knowledge this way should make outputs more accurate and consistent across projects.

It's designed to compound intelligence, not just automate tasks. The system learns your business over time and gets smarter with every input you feed it.

3️⃣ It's not as "non-technical" as advertised. You still need to understand APIs, JSON structure, and how to set up proper context. There's a learning curve if you haven't touched these concepts before.

Would love feedback if I'm heading in the right direction here.

Matteo Tittarelli ⚡️ Jordan Crawford Jacob Dietle Joe Rhew Taimoor Tariq Javeria Shah

Over the next 4 weeks, I'm building an AI-powered call brief system in Airtable.

Not because I need another project. Because I used to spend 15 minutes before every call scrambling to remember what matters.

Here's what my prep used to look like:

Open the CRM to check deal history. Fire up Perplexity for recent company news. Review Gong history for previous calls. Check product usage data. Skim LinkedIn for the contact's background. Then tie together the core questions I should ask.

Every. Single. Time.

I built a system that does this for me. One hour before any scheduled call, an automation kicks off. It pulls everything I need, synthesizes it with AI, and drops a call brief in Slack with a link to an Airtable interface.

I already use a version of this, but I'm rebuilding it in public so you can see how this actually works in Airtable.

Quick note on scope: This leans into what Airtable does well: centralizing data from different sources. Company news, CRM deal history, Gong call summaries, product usage signals, all synthesized through AI. If you need third-party intent signals (job changes, website visits, LinkedIn engagement), other platforms handle that better.

Before I touch a single automation or field, I need to answer three questions. Skip this, and you'll build something you don't actually use.

⚫️ What's the desired outcome?
✔️ A call brief one hour before every first discovery call. Not raw data. A synthesized view: What's happening at this company? What's our history? How are they using the product? What should I focus on in this conversation?

⚫️ What's required to make this work?
✔️Company news (AI field agents or Perplexity) 
✔️ Deal history (Salesforce) 
✔️ Gong call summaries 
✔️ Product usage data 
✔️ Contact context (LinkedIn) 
✔️ Core discovery questions 
✔️ AI synthesis on what to focus on

⚫️ What does the workflow look like?
✔️ Trigger: Calendar event detected
✔️ Process: Automation pulls data, AI synthesizes the brief
✔️ Output: Slack notification with link to Airtable interface

I open the interface, scan the brief, and show up prepared.

Once I have clarity on those three, then I get into the fun stuff: table structure, automations, integrations, and the interface layer.

Next week: Starting the build. I'll show you the data model and first automation.

Most Airtable users don't know you can enrich LinkedIn profiles natively.

Here's how:

Use Airtable Field Agents to pull LinkedIn profiles as long as you have their Full Name and Company Name.

Back in November, one of my customers was manually finding LinkedIn URLs for 3,000 contacts. Every time a new prospect was logged into their system, they'd pull the profile by hand.

We built with an Airtable Field Agent and ran it across all 3,000 records in 5 minutes.

Coverage landed around 60-70%. Accuracy on matches was about 80%.

Not perfect. But good enough for their use case.

Now every new contact logged into Airtable automatically pulls their LinkedIn profile.

I'll drop the exact prompt in the comments.

Call sentiment alone doesn't tell you if a customer is at risk. 

You need the full picture. 

Airtable integrates with Gong so RevOps teams can cross-reference call transcripts with product usage, CRM health scores, and support ticket trends in one place. 

→ Spot sentiment shifts in calls 
→ Layer in product adoption signals 
→ Surface real risk before it shows up in churn reports 

Complete customer intelligence in one system. 

Check it out today.

I'm going through HubSpot's RevOps Academy in my free time.

As I'm learning more about GTM engineering, I realized I needed deeper RevOps knowledge to understand how revenue operations actually work across the business.

Here's what's landing so far:

1. RevOps makes growth exponential by improving operational efficiency across the business

It's not just sales efficiency. It's marketing, customer success, product, everything that touches revenue.

2. Flywheel model beats funnel model

Customers don't disappear after they buy. They fuel growth if your systems are set up right.

3. Force and friction benefit the organization, even when it doesn't feel like it

The right friction in the right place keeps bad data and bad process from spreading.

4. You need the right number of leads as you scale, not just more
Volume without qualification breaks everything downstream.

5. The buyer's journey: Awareness (problem aware), Consideration (solution aware), Decision (provider aware)

Targeting certification by late Jan / mid Feb.

That said, what else should I be paying attention to? Any core lessons or principles I need to add?

Brandon Smith Jeff Ignacio Haris Odobasic Stefan Mersch 💭 Sebastien van Heyningen

I've been building AI-native apps on Airtable, Lovable, and Replit.

Here are 9 lessons that changed how I approach rapid app development:

1️⃣ Build in layers, not one-shot builds
Nail one component, then move to the next. It's easier to fine-tune and catch issues early.

2️⃣ Clarity of outcome is essential
AI platforms need clear targets. Vague inputs get vague outputs.

3️⃣ Edge cases require knowledge, not just prompts
AI handles standard paths well. Edge cases need platform expertise to close the gap.

4️⃣ Platform flexibility is the real unlock
Airtable lets you reshape your data model mid-build. That flexibility is the foundation of rapid app development.

5️⃣ AI is core to how these platforms work
It's not tacked on, it's foundational to what's possible and how fast you can move.

6️⃣ Advanced functions require platform familiarity
Formulas, automations, and integrations aren't plug-and-play. Expertise accelerates shipping.

7️⃣ Building happens in minutes. Production-grade takes weeks.
The first version is fast. Making it reliable and scalable is where the real work is.

8️⃣ Operators can build without waiting on IT
Quick wins in weeks vs waiting quarters for engineering to pick up your ticket.

9️⃣ The best builds are simple
The apps that stick solve one problem really well.

Rapid app development still requires expertise; it just shifted where it matters. But platforms like Airtable, Lovable, and Replit are unlocking what operators can build on their own.

Build with Airtable today. Link in the comments.

I asked AI to build a competitor to SpaceX.

It came back with a full competitive analysis deck in 20 minutes.

We just launched Superagent, a whole new Airtable product.

I gave it one prompt: "Create a competitive analysis deck of the commercial space market and opportunities for differentiation."

Multiple specialized AI agents deployed. Each tackled a different piece: market analysis, competitive positioning, timeline synthesis, regulatory requirements, technology comparisons.

20 minutes later: rich visuals, interactive charts, full citations. Ready to present.
This isn't another AI summary tool. It's a research and design team working in tandem.

If your team is blocked on competitive analysis or market research that requires real depth, give Superagent a try: bit.ly/3ZC0m40

Most AI roadmaps in 2025 started with the wrong question.

They asked "What can AI do?" instead of "Where are my teams spending time on work that doesn't require a human?"

With AI adoption moving past experimentation in 2026, companies are deploying actual use cases and getting tremendous gains.

So let's look at where AI is getting deployed:

1️⃣ Summarization & Synthesis 
Product teams are condensing product feedback from support tickets, sales calls, and user interviews into actionable themes that inform roadmap prioritization.

2️⃣ Classification & Prioritization 
Product Operations teams are ranking feature requests by revenue association so teams build what impacts the bottom line first.

3️⃣ Personalization at Scale 
Marketing teams at retail companies are generating email copy drafts across multiple campaigns, each one tailored to customer segments and purchase history.

4️⃣ Workflow Automation 
Marketing Operations teams are turning campaign performance data from static reports into automated budget reallocation recommendations for next quarter while there's still time to act on it.

5️⃣ Data Enrichment 
Revenue Operations teams are finding LinkedIn URLs and contact data for prospect lists in minutes instead of hours of manual research.

6️⃣ Generation & Content Creation 
Marketing teams are creating localized campaign content across 12 regions while maintaining brand voice and compliance standards.

If you're building an AI agenda in 2026, start with the workflows you already have. The best AI implementations don't require new systems. They make your existing ones smarter.

Harvard studied 100,000 AI agent users. The pattern is clear: AI that's siloed in chat gets abandoned. AI that's integrated into actual workflows gets stickier.

The reason?

Context engineering.

Most companies buy AI tools that can't touch their CRM, their Google Drive, or their project tracker. Then they wonder why adoption stalls.

Here's the thing: AI's real value isn't answering questions. It's completing tasks. But to complete tasks well, it needs the right information at the right time. When AI is disconnected from your tools, you're getting 10% of its potential. You're stuck with a Q&A bot, not a system that can actually execute.

The breakthrough happens when AI can pull context from across your tools, take action based on that context, and learn as it completes more tasks.

This is why platforms that integrate deeply with Google Drive, email, and project management tools see higher stickiness. Users don't just ask questions. They complete workflows. The AI has context, so it can act. And as it acts more, it gets better.

When evaluating AI tools, ask yourself: Can it access the context it needs? Can it take action, or just suggest it?

Context plus action equals 10x the impact of chat alone.

(Read Will Sullivan’s full breakdown of the Harvard study, link in comments)

Week 1 of building the call brief system. If I mess up the data model now, I'll be fighting this thing for months.

And the whole point of this is to stop scrambling before calls, so I need the data to flow cleanly from the start.

I'm building seven core tables:
1️⃣ Calls (the main hub): Tracks every scheduled call. Links to Call Briefs, Contacts, and Accounts.
2️⃣ Call Briefs (the generated output): Stores the synthesized intelligence for each call. One brief per call. This is what I actually read before the call.
3️⃣ Accounts: Company-level data. Links to Deals, Product Usage, and Company Intelligence.
4️⃣ Contacts: Individual people I'm talking to. Linked to Accounts and Calls.
5️⃣ Deals: CRM history. Deal stage, notes, last activity. Linked to Accounts.
6️⃣ Product Usage: For existing customers. Bases, users, activity trends, automations created. Linked to Accounts.
7️⃣ Company Intelligence: AI-pulled company news, strategic priorities, recent developments. Linked to Accounts.

Each table does one thing. Calls are for tracking the event. Call Briefs store what I actually need to know. Accounts are where all the context lives.

Calls and Call Briefs are linked one to one, so every call gets exactly one brief. There's no duplicates or confusion on which brief belongs to which call.

Linked records mean when I update deal history in Salesforce, it flows through to the brief automatically. When product usage data refreshes, the brief reflects it. I'm not copying and pasting data across tables.

The Accounts table is the hub. Everything connects through it. Company Intelligence, Product Usage, Deals, all linked to Accounts. So when I pull a call brief, it knows which account I'm calling and it pulls everything associated with that account.

I tested this with a fake call record. Linked it to a contact and an account. Added some deal history. Data flows where it should.

Next week: Building the first automation. Can I actually pull company news and deal history on a schedule?

If your tables don't talk to each other cleanly, your automations will break. And you'll be right back to scrambling before every call.

Built this entire base structure with Airtable's Omni in 10 minutes. The hard part isn't building the tables anymore. It's knowing how they should connect.

Most AI projects fail midway through.

Not because the tech doesn't work. Because the scope was never clear.

"Measure twice, cut once" was a principle from traditional trades. Carpenters and tailors used it to avoid irreversible errors and wasted materials.

Today's builders are AI engineers, FDEs, GTM operators, and non-technical people shipping apps and agents.

AI collapsed build time from months to hours. But it also means you can build the wrong thing really fast.

For AI builders, it's "Scope twice, build once."

Before you commit to a critical build, scope what you're actually trying to solve:

⚫️ The Workflow 
Not "automate project management."
But, "Our team spends 2 hours every Monday syncing status across HubSpot, Sheets, and Slack."

⚫️ The Impact
Not "save time."
But, "Cut sync to 15 minutes. Give the team 1 hour 45 minutes back."

⚫️ The Capabilities
What does "done" look like? Data sync? Auto-updates? Notifications?

⚫️ Time to Value 
Days or weeks? If it's 6 months, maybe it's not the right first project.

⚫️ The Initiative it Accelerates
Does this help you hit Q1 revenue targets? Reduce operational costs by 20%? Scale without adding headcount?

Tie it to a real OKR or strategic goal. Otherwise, you're just building because you can.

⚫️ The Phases
V1: Automate the sync. V2: Add notifications. V3: Build the dashboard. 
Don't solve everything at once.

Bad scoping: "Let's build an AI agent for project management."

Good scoping: "Our PM updates 3 systems manually every Monday. That's 2 hours. Automate the sync, give them their Monday back, help us hit our Q1 efficiency goal."

The worst thing teams do? Build fast because they can. Excitement takes over. Then they realize midway they're solving the wrong problem.

Resources wasted. Timelines blown. Sometimes people lose their jobs over a bad scope.

Clarity beats excitement.

Scope it twice. Then build it once.

Most teams are deploying AI without asking the right question.

It’s not “can we automate this?” 
It’s “what are we willing to lose?”

I’ve been building with AI for months now, across customers I consult with at Airtable and my own projects. And I keep seeing the same pattern.

AI is incredible for volume and speed. If you need 500 product descriptions written, or you’re generating e-commerce images at scale, it’s a no-brainer. The output is good enough, and you get it fast.

But the moment you need something that reflects your brand, your specific visual identity, your tone, your creative direction, AI falls short.

I’ve tested this with podcast graphics, brand assets, creative campaigns. The output is generic. It doesn’t carry the theme. It doesn’t have taste.

Here’s the tradeoff most people don’t think through. AI gives you efficiency, but it costs you originality. It gives you speed, but it costs you brand equity.

And that’s fine if you’re optimizing for volume. 
But if what you’re building is brand-critical, you can’t afford that loss.

Before you automate something, ask yourself: 
- What am I optimizing for? 
- Speed or originality? 
- What’s the tradeoff?
- What do I gain, and what do I lose?
- Can I live with that loss?

Zoom in on the task. Zoom out on the impact. 

Then decide what you’re willing to sacrifice.

Not everything should be automated. Some things still need a human in the loop.

Prob one of the best decisions I made in 2025. 

Switched from Apple Podcasts to Snipd. 

I listen to 10-15 hours of podcasts a week across faith, mindset, leadership, AI in business, RevOps/GTME. 

Snipd lets me capture insights as I go. Nothing disappears into the ether. 

Check it out if you aren't using it already.

Over the past year and a half, I’ve had the privilege to work alongside Alex. 

Among other things, three things stand out:

1 - He’s a leader that is in the trenches with you

2 - He’s a leader that challenges growing in your skillset

3 - He’s a leader that cares not just for your performance but, you personally

Joining his team is easily one of the best decisions I’ve made since, moving to ATX.

Apply today 👊🏾

P.S. You’re welcome to hmu too

Commercial Sales Leader @ Airtable | AI + Automation ⚡️

My team is growing! 🚀 I’m looking for a seller with natural curiosity, a strong desire to learn, and the drive to make a real impact. This is a hybrid role for someone who enjoys winning new business and thoughtfully expanding existing accounts over time.

You’ll partner closely with customers as they scale, helping them unlock more value with Airtable through strategic, long-term growth.

Airtable is in a pivotal phase as we build toward IPO, and this role offers real ownership and the chance to help shape what’s next.

📍 Austin (Hybrid)

If this sounds like you (or someone you know), I’d love to connect. Feel free to send me a DM.

Account Executive, Commercial Accounts  

How many internal tools is your team building that you could've bought off the shelf?

And what customer value did you trade for that distraction?

Kyle Norton talked about this on his podcast with Everett from Clay. He broke down a framework on GTM Engineering that clicked for me:

1️⃣ Buy is about 
→ Speed 
→ Broad organizational impact 
→ Resources required to support it

2️⃣ Build is about 
→ Fast execution 
→ Low org impact 
→ Or high enough strategic value to justify dedicated resources

Most things? Buy them. Very few things should you actually build.

If you're a sales tech company building an internal HR tool, you're spending engineering cycles on something Deel or Rippling already solved. That's a distraction, not a strategy.

HubSpot CTO Dharmesh Shah put it clearly: "Spend every calorie possible on creating value for your customers."

Build only when it's so unique to your workflows that it becomes a strategic asset. Something no off-the-shelf tool can do.

Everything else? Buy it and move on.

Stop writing better prompts. Start building better context. 

Most teams think the problem is their prompts. They're tweaking inputs and refining instructions, hoping AI gets smarter. It doesn't work that way. 

AI gets smarter when it has better context to work from. 

The problem is your data lives everywhere. Campaign performance in one tool. Customer intel in another. Product catalog somewhere else. 

When you ask AI to help, it's guessing because it can't see what worked last quarter or connect your product data to your customer data to your performance data. 

Every project starts from scratch and every output feels generic. 

Airtable changes this because it acts as the context layer. When everything lives in one system, AI has the full picture with relational data, linked records, and historical performance tied to real-time inputs. 

I built a demo for a fashion brand that was spending weeks aligning on every creative brief. Past performance was buried, brand guidelines lived in someone's head, and competitor research was scattered across tools. 

We moved everything into Airtable as their single source of truth. 

Now when someone starts a brief, they input the basics and the system pulls the rest: past campaigns, personas, product data, and competitive signals. 
AI drafts using what actually happened before instead of generic best practices.

Performance feeds back after launch, so the next brief is smarter because of it. 

The operators seeing results from AI aren't writing better prompts. They consolidated first and stopped fighting tool sprawl by building on one foundation. 

AI doesn't improve because the model changed. It improves because your context got better, and your context gets better when it lives in one place.

One of the features I've been pushing to every customer I work with.

With the latest improvements Airtable just shipped, there's never been a better time to explore what's possible with custom elements.

Network graphs. 3D models. Custom dashboards. If you can imagine it, you can probably build it.

Check out what builders are creating…

Introducing Built with Omni: a new showcase for builders to share bespoke AI apps 🚀

Get inspired: Browse bespoke elements created by Airtable builders.

Learn: Inspect real code and prompts to uplevel your app building skills.

Contribute your creations: Share your own apps and interfaces for others to learn from.

Plus, we launched a few key improvements to the custom elements experience:
✔️ Code inspection
✔️ Public interface support
✔️ Multi-developer support

Dive into Built with Omni →   https://lnkd.in/gDY2Kdij

Make your GTM system impossible to copy.

We build bespoke AI intelligence orchestration systems that accelerate decisions and unlock unique approaches.

Joe Rhew

A lot of people sleep on CLAUDE.md.

It's the single most important file in any Claude Code project, and most people either skip it entirely or overcomplicate it.

In this video, I show the difference between having one and not having one. Same folder, same content, same question - but in one case Claude immediately finds what I need, and in the other it fumbles around guessing.

The reason: Claude Code automatically reads CLAUDE.md at the start of every session. No prompting. It just loads that context before you even ask your first question.

So whatever you put in there - project structure, how you like to work, critical instructions - Claude has it from the start.

A few things worth knowing:

You can nest them. Root-level CLAUDE.md for general context, subfolder CLAUDE.md for specific instructions. Claude reads both, prioritizes the nested one.

You can reference other files. If your context is getting long, break it into separate files and link to them.

Start simple. I've seen people use AI to generate massive CLAUDE.md files on day one and then wonder why things feel off. A few lines is fine. Add more as you learn what actually helps.

If you're using Claude Code without a CLAUDE.md, you're probably repeating yourself way more than you need to.

How do you use CLAUDE.md in your projects?

GTM Intelligence Orchestration | The Workflow Company

We rebuilt our entire outbound system from scratch. Before sharing what it looks like, a short story:

A few months ago I started working with a Series B AI company.

Hot product. 
Huge TAM. 
The kind of company VCs love.

But they had a problem: too many possibilities.

Their product worked for dozens of use cases, across multiple personas, in countless industries. They knew what was working - but they had no idea what they were missing.

What other industries might resonate? What use cases hadn't they explored?

So we started testing. And I immediately hit a wall.

The old way - building lists in Clay, writing copy, launching campaigns - couldn't match the pace we needed.

We weren't trying to run 1-2 campaigns a month.

We wanted to test 10+ hypotheses. Fast.

So we rebuilt everything from scratch:

1. Context Repo
A single source of truth: company narrative, product positioning, personas, campaign angles, offers. All documented. All version-controlled.

2. Micro-List Building
Instead of 5,000-person blasts, we build targeted lists of a few hundred people per hypothesis programmatically. Each list tests specific traits we have theories about.

3. Programmatic Copywriting
We feed the LLM the exact context it needs—campaign brief, persona, offer—pulled directly from the repo. No manual copywriting bottleneck.

4. Cost Optimization
Rapid experimentation = high token volume. So we built prompt caching and batching that saves 60-80% on costs.

5. Audit Trails
Every decision is documented. If we targeted the wrong pain point, then we can simply tweak the campaign brief, rerun. The system learns.

The result:

We now scientifically test outbound hypotheses with full traceability.

We're not guessing. We're not hoping our instincts are right. We're not rerunning a playbook that once worked for a similar company.

We're systematically exploring the space to find what actually works - not just what worked before for someone else.

The difference between a local maximum and a global maximum.

And it's why I believe the future of GTM isn't more SDRs running their own experiments in silos.

It's a centralized system that controls the testing - so you're not leaving hypothesis exploration to chance.

---

If you're in a similar situation as our client - drowning in hypotheses and frustrated with how slow it is to actually test them or if any of this resonates with challenges you're facing - happy to chat, DM me. 

I'm always down to go deeper on how we're thinking about this and how we've set things up.

Every time you use ChatGPT or Claude, you're starting from scratch.

"Here's my company. Here's what we sell. Here are our personas. Here's our competitive positioning."

Copy. Paste. Repeat. For every single conversation.

Claude Code solves this by writing files. Which means you can build a context repository - markdown files that capture everything an AI needs to know about your business.

Company overview. Products. Personas. Messaging. Competitive positioning. Voice and tone.

And it's not a black box memory - you know exactly what files exist and what they say.

Once it's saved, you never repeat yourself again. You just say "read the context files" and Claude is already up to speed.

In this walkthrough, I walk through building one from scratch for Anthropic as an example:

> Spinning up parallel research agents to gather intel
> Synthesizing raw research into structured context files
> Using that context to brainstorm outbound messaging

The whole process took maybe 20 minutes. And now that context is permanent - ready for the next task, and the one after that. 

(Granted this isn't production grade, but it's enough to get started with for most teams.)

This is the compounding advantage of Claude Code. Every piece of context you save makes every future conversation smarter.

If you're tired of being a broken record every time you open a chat window, this one's for you.

For those of you already deep in Claude Code - what do you wish you'd set up on day one?

--

This is the second video in a series I'm doing on Claude Code for Sales & Marketing teams. Link to the first video in the comments.

Git is the single best investment you can make when starting with Claude Code.

I know it sounds like a developer thing.

But - Claude Code modifies files on your machine. Without version control, you're one bad edit away from losing work you can't get back.

With Git + GitHub, you get checkpoints you can always roll back to, cloud backup, and the ability to pick up your work from any machine.

Here's the mental model that made it click for me: think of Git like packing and shipping boxes.

▶ git add = putting items in the box
▶ git commit = sealing it and writing a label
▶ git push = shipping it to the warehouse

The reason you "stage" files before committing is so you can group related changes together. If you update your persona doc and that triggers changes to your campaign angles and pain points, you probably want all of those in the same box. That way you can roll back the whole thing if your hypothesis was wrong.

If you're still confused, that's ok. Watching this video will help clarify things for you.

In this video, I walk through:
→ What Git actually is (and why it's more powerful than Google Docs versioning)
→ The add → commit → push workflow
→ How to pull changes when working across machines

What's holding you back from using Git?

---

This is the fourth video in my Claude Code series for GTM teams. Links to the previous episodes below, along with the full 31-min long YouTube version of this video which includes: 
- setup instructions
- protecting your API keys with .gitignore (!!!)
- using Claude Code to run Git commands for you

---

Previous episodes:
- 001 Setup: https://lnkd.in/gyWz4Fm6
- 002 Company Context: https://lnkd.in/g6M9WzbN
- 003 CLAUDE-dot-md: https://lnkd.in/gRCGjbuq

Full YouTube version: https://lnkd.in/gk_qNW_7

Claude Code isn't just for developers.
                                                              
At The Workflow Company, we've been using it daily for GTM work - research, competitive analysis, content, outreach, internal ops - and it's completely changed how we operate.
                                                              
Most people still think of it as a coding tool. It's not. It's an AI assistant that can actually take action on your computer. Write files. Search the web. Run scripts. Chain tasks together.
                                                              
It's a different dimension compared to chat interfaces.
                                                              
If you're in GTM and haven't tried it yet, I made this video to get you started. It's the first in a series where I'll share how we actually use it - not for coding (although we do a fair bit of it), but for the GTM work you're already doing.
                                                              
Claude Code is the single tool I'd recommend to anyone who wants to push the boundaries of what's possible in GTM right now. Hopefully this helps you get over the line.

What's your take on Claude Code? Would love to hear about your experience with it.

I try not to have regrets but here's a big one from 2025.

We went through a complete website refresh - new branding, new pages - last year. The design was great (Thanks team Odama), and we were really happy with it.

Since we already had a site up on Webflow, inertia took over and I made the decision to develop the new website on Webflow. Looking back, this was clearly the wrong decision.

Webflow and other low-code tools were amazing in the pre-AI era. They abstracted away the technical nuisances for the less technical users. Instead of writing code, you could click and drag your way around and build something semi-presentable.

But with the cost of writing code approaching an asymptote of 0, the cost of these no-/low-code abstractions is inversely approaching ∞. 

Why should a user need to learn the idiosyncrasies of a platform that is detached from code, when they can simply ask an LLM to create a coded solution?

The cost of this decision often appears in maintenance and iteration speed.

For us, practically speaking, developing our site on Webflow means...
- it takes longer for us to make tweaks to it
- it takes longer to experiment / iterate - spin up new pages, run A/B tests, etc
- it costs more to change anything (hiring a Webflow developer vs. using Claude Code)

The point isn't to specifically call out Webflow, but just use it as an example to illustrate a point that's becoming more and more obvious:

Given LLMs' current capability, the cost of abstraction continues to increase.

And the flip side: the value of code-based skills keeps compounding. 
Code is portable.  
Code is composable.
Code is extensible.
And perhaps most importantly, AI is really good at working with code.
Platform-specific knowledge is none of these things.

So here's the takeaway. If you're evaluating tools in 2026, ask yourself: 

Am I learning a siloed platform's quirks, or building with code that compounds and gives me leverage?

Initial thoughts on Claude Coworker, the Claude Code wrapper for non-technical folks:

> You can give Coworker access to a file directory with files you want to work with, and in the background it loads up a Linux filesystem sandbox with clear isolation from the rest of your system. Good safety/privacy feature without the user having to do anything on their end

> Coworker, as far as I can tell, does not yet have the ability to revert any changes it makes. I can already see a lot of tears shed over Claude accidentally deleting and overwriting files

> Because Coworker has access to your local file system, I see this first iteration being largely single-player. But what makes Claude Code awesome is that you can sync to git, and make it multi-player and collaborative

> Coworker's interface feels more session-based compared to Claude Code's directory-based. Meaning, Coworker would be great for working on a particular issue at the moment, but the work feels more disposable versus compoundable. Claude Code, with its directory-based approach, feels like it brings more permanence to the work you do, allowing you to iterate on the same set of files and build on top of your previous work

> Feels snappier than Claude Code; most likely has to do with the streaming text - Time-To-First-Token

Coworker will still feel immensely powerful for folks who have not started using Claude Code yet. I still believe that the UI layer is collapsing, and that's the case for Coworker as well. The polished interface compared to Claude Code's terminal is less overwhelming, but to someone used to Claude code, the UI still feels like friction.

Overall, I think Coworker could be a great transient entry point for non-technical folks to eventually graduate to Claude Code. The Anthropic team did mention they released this super early to iterate, so I'm keen to see how it evolves and whether it can stand on its own and have as seismic an impact as Claude Code has had.

We've built a GTM context repo (link to a post with more details in the comments), with outbound being the first use case. 

Here's how we're thinking about extending the application of the contexts.

> Horizontal
We've built the repo to store the contexts and do nothing else on purpose. Fully decoupled from the current application of the context = outbound. Because it's self contained and modularized, we can plug in the same repo to other use cases: 
1. content generation
2. qualification
3. enrichments

> Vertical
The repo is driving outreach sequence generation. For each prospect, we have a clear view into the contexts that were pulled, the resulting sequence and the rationale behind it. But it's not been tied yet to the outcome, i.e. response from the prospect or lack thereof. We want to close the loop, so that AI can help with pattern-matching:
1. Contexts are programmatically retrieved and composed
2. An outbound sequence is generated by an LLM based on 1
3. A positive reply to 2 is received
4. LLM analyzes 1, 2, and 3 and generates a hypothesis to test
5. Back to Step 1, the hypothesis from 4 is fed as a context

Personally really excited about step 4 - it essentially unlocks self-learning.

Claude Code literally 10x'd our iteration speed. 

We don't outsource thinking to it - we're still very much in control of the dialogue and the final decision. But it's great at pumping out different brainstorming ideas that we can apply our judgment against.

It really is as easy as feeding it existing context files and asking it to be a brainstorming partner. We talk through the ideas together, agree on the final output, which Claude generates. 

Another piece of context created that we can feed in a future Claude Code session for further refinement and iteration.

What did we do before CC?

Here's my roadmap for automating context repo updates.

(I'll never reach Stage 4 but that's ok.)

---

First - what's a context repo? A central place where you store everything an AI needs to know about your business. Positioning. Personas. Products. Voice.

Load it once, and you stop repeating yourself in every conversation with an LLM.

The most common question I get after people set one up: "How do I keep it updated?"

Because your business evolves. You refine your messaging after a big client win. You sunset a product line. Your ICP shifts.

Meanwhile, your context repo is stuck in the past. And every AI output built on stale context drifts further from reality.

Here's how I think about the progression:

---

1️⃣ Stage 1: I do, AI helps

I drive the updates. AI assists with the drafting.

"Hey Claude, I've changed my thinking on how we position ourselves. Pull up the last few client calls for context, then update the positioning doc. Show me what you changed before saving."

2️⃣ Stage 2: AI surfaces, I decide

AI monitors my raw context sources - call transcripts, LinkedIn posts, Slack threads - and surfaces drift and decay.

"I noticed your last 3 posts emphasize 'context as code' but your messaging doc doesn't mention it. Want me to suggest changes?"

I'm still in full control. But I'm not the one catching drift anymore.

3️⃣ Stage 3: AI does, I approve

AI makes changes autonomously - but staged, not live. It creates a pull request. I review and merge.

Full audit trail. Full veto power.

4️⃣ Stage 4: AI does

AI updates my context repo directly. No review. No approval. Full trust.

I don't think I'll ever get here. And I don't think you should either.

---

Here's why:

Context is the foundation of every AI output you produce. Content. Campaigns. Etc.

Get the context wrong, and everything downstream is wrong.

The goal isn't to remove yourself from the loop, but rather to remove the tedious parts - the monitoring, the drafting, the formatting - while keeping yourself where it matters: the judgment call.

Stage 3 is the sweet spot. You get 90% of the efficiency with 100% of the control.

Stop optimizing for full automation, and instead optimize for the right level of human oversight.

---

Where are you on this spectrum? Most are between 0 and 1.

What are the building blocks of a great cold outreach message?

I have been building a system to programmatically pull together contexts to generate an outreach sequence. Here are all the types of contexts that go into it:

-------------
Our contexts
-------------
1. Company
> Context about the company, its origin, mission, founders, funding history, etc.

2. Narrative
> The narrative - why now, why us - around the company and the product. More macro than messaging

3. Messaging
> Key messaging pillars, tone of voice, specific phrases to use/avoid

4. Product
> Product overview, both technical details and a JTBD framing

5. Channel Best Practices
> Email / LinkedIn / etc. - unwritten rules around best practices, accepted norms

6. Personas
> Various ICP personas that the company has a hypothesis on. Includes pain points, aspirations, JTBD, buying triggers, owned KPIs, etc. Only the relevant personas get pulled into the final composed context

7. Campaigns
> Campaign angles that specifically go deeper on all of the contexts above - for a specific persona in a specific industry, what product features and pain points do we highlight, what should our messaging tone be, etc. Only one campaign brief gets pulled in

8. Offers
> Different offers we can make in a cold outreach context. Should we ask for a meeting, can we send them resources, could we ask for permission to send them a personalized lead magnet? Offers we want to test get pulled in

--------------------
Prospect's contexts
--------------------
1. Account research
> Deep web-based research; disambiguation is tricky, and verifying all the facts are about the target company is most of the work

2. Contact professional experience
> Mostly based on LinkedIn data. What's their current role, career trajectory, what words do they use to describe themselves?

3. Contact social media presence
> Mostly LinkedIn - works great for active posters/engagers; not so much for lurkers

---

This feels fairly comprehensive to me, but I'm sure there are other considerations that I'm overlooking. So what else should be in this list of contexts?

One thing I think about a lot these days is the durability of our ideas, products, and services.

When ChatGPT 3.5 came out (Nov 2022, only just over 3 years ago) - all of us had this collective expansion of ideas and possibilities. With the help of LLMs, any idea seemed feasible.

Today, working inside of multiple Claude Code terminals for most of the day, every idea feels ephemeral. Most of us are probably feeling some version of this tension - as companies opt to build versus buy, and mature and seemingly resilient businesses go out of business overnight.

What is durable in this age of disposable software?

I've been sitting with this question, and here's where my thinking is landing:

Coding agents compress build time. What took weeks now takes hours. But they don't compress the human elements - trust, relationships, community, domain expertise. These still compound at a human pace.

The tempting advice is "just stay in the game long enough." But I don't think that's the answer - at least not for pure software businesses. If the moat is just code, someone can rebuild it tomorrow.

What seems more durable: businesses where human elements are architecturally intertwined with the software. 

Some examples:

► Marketplaces, where network effects are built on human trust - supply and demand that took years to cultivate. Can't clone that overnight.
► Forward-deployed engineering, where humans are embedded in the value prop itself.
► Service-as-a-software = human expertise + judgment + taste + software

Maybe that's why we're seeing the rise of services-enabled software, forward-deployed engineering as a discipline, and a rethinking of the "pure SaaS" playbook.

I'm still working through this, but I think the question isn't just "what should I build?" It's: how deeply are human elements woven into the business itself?

Curious to get folks' take on this. What feels durable to you right now?

Same workflow. Different clients. Different fit assessments.

We built a person research workflow that passes a client_id into every enrichment request.

client_id=wfco → pulls The Workflow Company context.
client_id=client_a → pulls Client A context.

The research agent sees the same person's LinkedIn activity. But evaluates fit against different criteria.

A technical founder posting about developer tools might be:
→ High fit for our dev tool client
→ Low fit for our enterprise sales client

One enrichment pipeline. Infinite context variations.

Why did we separate this out instead of hard coding our context?

Imagine I have multiple clients. I can pass in their IDs and look at the same person through different lenses. Someone who's not a good fit for The Workflow Company might be a great fit for a client of ours.

Building this composability into your workflows means you don't have to repeat yourself. You don't have to build separate enrichment workflows per client with the same logic duplicated everywhere.

Update one prompt, forget to update the others? Not a problem when the enrichment logic lives once and the context is the variable.

The context about your business should live in a programmatically accessible source. Your enrichment modules just point to it and pull whatever the latest version is.

p.s. the context database is doing a lot of the heavy lifting here - how it's structured, how data is stored, updated, and retrieved. Get that right and this architecture is easy to set up and maintain

My good friend Matteo Tittarelli ⚡️and Jared Waxman are back with the third cohort of GTM Engineer School. 

"GTM engineering" as a discipline is nascent and evolving quickly. If you've been on the fence and unsure of where to start, this course would provide a great starting point to ground yourself and understand the landscape of frameworks and tools - after which you can go on your own and start exploring areas that interest you. 

You'll be learning from some of the most forward thinking operators in the space, how they think about problems and how they use their favourite tools to solve them.

DM me if you're interested in taking the course - I've asked Matteo and Jared to tack on my affiliate fee as an additional discount.

taplio

The Battle

Rhondre Giscombe

Joe Rhew

Followers

Posts

Engagements

Likes

Performance ScoreRhondre Giscombe's LinkedIn Performance

Performance ScoreJoe Rhew's LinkedIn Performance

Ready to grow your LinkedIn presence?

taplio

The Battle

Rhondre Giscombe

Joe Rhew

Followers

Posts

Engagements

Likes

Performance Score.css-goub6s{font-size:var(--chakra-fontSizes-md);font-weight:500;color:var(--chakra-colors-gray-600);display:block;margin-top:var(--chakra-space-1);}Rhondre Giscombe's LinkedIn Performance

Performance ScoreJoe Rhew's LinkedIn Performance

Ready to grow your LinkedIn presence?

Performance ScoreRhondre Giscombe's LinkedIn Performance