We hosted a small room of operators, engineers, and founders to talk about something that still does not have a clean name: GTM work that behaves like software work.
Not "AI for sales." That framing is exhausted. What was actually interesting in the room was narrower and more specific: GTM work — lists, scoring, enrichment, RFPs, product marketing, attribution, research, outbound — becoming software you can inspect, edit, and rerun. That was the thing everyone kept circling back to.
Full Event Recording
Video not loading in LinkedIn or your in-app browser? Watch it on YouTube.
Nandika Jhunjhunwala: account scoring is an operating system
Video not loading in LinkedIn or your in-app browser? Watch it on YouTube.
Most account scoring is a spreadsheet exercise dressed up as a system. Nandika showed what it looks like when it's actually a system: scoring as a live decision-making layer, not a static list you enrich once and forget.
Her core distinction was fit versus timing. Firmographics get you to "looks right." Timing signals — hiring, funding, web activity, product usage, category intent, CRM history — tell you whether something has started moving. Pull them into one model and the next action becomes obvious. Keep them separate and you're guessing.
She uses Default as the routing layer: account data flowing through CRM and product signals continuously. Her warning about one-time enrichment runs resonated with a lot of people in the room — they're fine until you need state, retries, scoring logic, and clean handoffs at volume.
Hunter Rosenblume: the RFP is a software problem
Video not loading in LinkedIn or your in-app browser? Watch it on YouTube.
Everyone hates RFPs. Almost nobody fixes them. Hunter's talk was about why they stay broken — and how to actually fix them.
The problem isn't that RFPs are hard. It's that teams treat them as content instead of as a software problem. You end up with a messy doc, a tired AE, and a deadline nobody wants to own. Hunter's version: decompose the work, reuse the institutional knowledge that already exists, route the judgment calls to humans, let the system handle the repetitive parts. His "RFP Gremlin" example came from school lunch procurement — extracting requirements, searching internal context, generating responses, keeping humans in the loop only where it matters.
Hunter writes at hunterrosenblume.com and is building Ordo.
Partner demo: Type.com AI Teammates
Video not loading in LinkedIn or your in-app browser? Watch it on YouTube.
GTM automation usually doesn't break on model quality. It breaks on coordination — who has context, what tools are connected, how work gets handed off.
Type.com showed a different framing: every Slack channel gets a shared virtual machine. Hand it work, give it context, it operates across whatever tools are already in the workflow.
Event attendees get a free two-week trial with $100 in credits — request access at type.com and mention the Deepline event.
Nick Lafferty: the marketing engineer is not a growth hacker
Video not loading in LinkedIn or your in-app browser? Watch it on YouTube.
Nick gave the clearest answer I've seen to "what does a marketing engineer actually do."
It's not a marketer who learned SQL. It's not an engineer on loan to marketing. It's someone who treats distribution, measurement, attribution, and product surface area as one system to build and maintain. His test: if your marketing depends on a signal, build the system that captures it reliably. If attribution is broken, instrument the place where reality actually lives instead of arguing about the CRM report.
He's a founding marketing engineer at Profound and writes at nicklafferty.com. His stack: Default for routing, "how did you hear about us?" fields for attribution, GitHub Actions for automation, and Claude for ads and research workflows.
Kathleen Booth: product marketing should compound
Video not loading in LinkedIn or your in-app browser? Watch it on YouTube.
Every scaling company has this problem. Positioning, customer language, competitor notes, launch plans, sales feedback, and proof points live in separate places. The work gets done. The learning evaporates. The next campaign starts from scratch.
Kathleen's demo was about fixing the evaporation problem. A product marketing brain: knowledge base, intelligence layer, skills, and feedback loop in one place. Using Claude Code as an operating layer rather than a copywriter — so the output of each campaign feeds the next one instead of disappearing into a folder nobody opens.
She leads marketing at Sequel.io and writes at kathleen-booth.com.
Jai Toor: GTM systems should get better every time they run
Video not loading in LinkedIn or your in-app browser? Watch it on YouTube.
Jai closed with a live demo and an argument about why the current model is broken.
The current model is a stack — enrichment tool, sequencing tool, CRM, analytics, data cleanup — and the operator's job is to shuttle context between them. Most of your time goes to the plumbing, not the work. What he's building toward is closer to a compiler: define the outcome, define what a good result looks like, run it. The system figures out the route. Each run leaves state behind so the next one starts from a better position.
The demo covered Deepline: TAM building, enrichment, scoring, and outbound in one environment, with real inspection of what the agent actually did. The part of the talk that stuck for me was about what breaks in production — network reliability, tool failures, reusable state. The gap between a demo agent and something a non-technical operator can rerun next Tuesday is mostly that stuff.
The pattern
Watch the full recording for the conversations between talks — what people are actually building, where things are still rough, and why the best GTM teams are starting to look a lot more like product teams.
The teams doing interesting work aren't collecting tools. They're taking GTM judgment — the stuff that used to live in someone's head or a spreadsheet — and turning it into something they can run again.