Most GTM teams have implemented some version of AI: email writing, AI SDRs, intent tools, signal-based outbound, automated research, deal reviews, and so on.

AI should be making these teams dramatically more productive by now: measurably higher rep efficiency, pipeline and closed won revenue.

But for most teams, the results are still underwhelming.

Ask AI to work an account and you’ll get something like:

“Acme is hiring SDRs and had a closed-lost opportunity last year. Reach out about renewed pipeline growth.”

Technically accurate, but completely generic. It generates the exact kind of message a buyer deletes instantly, and gives us a snapshot of why AI isn’t moving the needle: reps are still forced to do manual research, prioritization remains a guessing game, and the outreach feels predictably synthetic.

The issue is that most teams are asking AI to make GTM decisions without the two things it needs to make those decisions well: context and logic.

GTM’s North Stars

Before getting into the weeds, it’s worth clarifying what AI should actually improve.

If we start from first principles, go to market teams should be focused on three things: a) more pipeline, b) faster pipeline progression, and c) more closed-won revenue.

For the sake of this article, we’ll focus on a) pipeline generation.

Going one layer deeper, the “outcome” of a sales organization’s pipeline generation efforts comes down to three “inputs” they can control (ignoring demand, market awareness, etc.).

1. Targeting: which accounts and people you focus on

2. Hypothesis: what problem(s) you articulate and offer to solve

3. Execution: how well you turn that hypothesis into outreach, calls, presentations, etc.

Each of these three areas is a place AI could add leverage. The question is where it’s actually showing up today – and that’s where things start to break down.

The Problem: most GTM AI tools focus too much on the third layer, “Execution”.

They help write emails, summarize accounts, generate call scripts, or automate activity. That can be useful, but it is not where the real leverage is.

The Reality

The real “alpha” in go to market is actually upstream.

The quality of your a) targeting and b) point of view matters significantly more than the quality of the email you send.

If you pick an account based on a commoditized signal and craft a weak hypothesis (see my post on the Shift from ‘Signal-Led’ to ‘Scenario-Led’ Outbound), a “great” email does nothing.

Whereas if you target the right account with a sharp hypothesis, the copy does not need to be perfect. It just needs to be relevant.

That is precisely why AI GTM initiatives underperform. Today’s agents aren’t experts at deciding:

• Which account matters

• Why that account matters now

• Which person is most relevant

• What pain is most likely

• What message would actually be credible

And I believe there are two different, but related root causes here:

1. Context: The agent does not have the right GTM context.

2. Logic: Teams are outsourcing the logic that should be their in-house edge.

Let’s unpack these.

Problem One: AI Doesn’t Have the Right Context

Most people know this by now – GTM stacks are fragmented.

Good sellers know exactly what signals drive their buyers’ decisions, how to spot them, how to prioritize them, and how to understand relationships between them.

And they use all information available to them to carefully craft their targeting strategy, hypothesis, and messaging:

They’re digging through the CRM, call recordings, intent activity, mutual connections, job postings, reddit, online forums, and more, to decide who to target and what to say.

An agent is no different.

If an LLM is asked who to target or what to say, and it’s working with either a) limited pieces of the puzzle or b) doesn’t know they fit together (or worse, both) – it’s not going to be effective.

Here’s an Example

Imagine two companies in your territory recently posted SDR roles:

An agent that isn’t equipped with the right context or logic would detect the same hiring signal at both accounts, prioritize both, and generate similar outbound.

In reality, the fit, intent, situation, and therefore prioritization of these two accounts may be entirely different:

Company A might be hiring SDRs because they’re scaling outbound, use tools you integrate with, have pain points your product solves well, recently visited your website, and just hired a past champion.

Company B might also be hiring SDRs, but already uses an incumbent tool you struggle to displace, has a workflow you do not integrate well with, and told an SDR that cold called them that they signed a 3-year agreement last month.

If your agents don’t have access to all data, know where you win, where you fall short, how you compare to incumbent tools, what systems you integrate with, which pain points you solve best, and which buying scenarios are actually worth pursuing, it’s impossible for them to be effective.

That is the gap.

Feeding signals to AI is the easy part, the hard part is ensuring it understands your business well enough to know which signals matter, how to rank them, and what to lead with.

Problem Two: Borrowed Logic Can’t Be an Edge

This is the strategic flaw: Teams are outsourcing what should be their core competitive advantage.

They’re buying their upstream intelligence (targeting, hypothesis generation, etc.) from AI GTM vendors.

When you outsource this, you’re now running the same decision logic as everyone using that model or vendor. And by definition, a signal or strategy everyone has access to cannot, by definition, be an advantage.

The only thing that can be proprietary is what you do with it: the layer that decides which signals matter, how they combine, and what they mean for your business specifically. The edge was never the signal. It’s the interpretation on top of it.

So when you also buy that interpretation layer from a vendor, you’ve commoditized the last thing you had left. The signal was already shared; now your reading of it is too.

However, buying makes sense for parts of the workflow.

It’s arguably silly to build tools that enrich accounts, find job posts, scrape websites, generate drafts, summarize calls, route leads, sync data, or send emails.

Those are execution layers.

But the upstream (and most important) parts of your GTM motion should not be outsourced:

• Which accounts are worth prioritizing

• Which signals actually matter

• Which combinations of signals indicate a real buying scenario

• Which personas are likely involved

• What pain hypothesis should be used

• What proof points should be attached

• What the system should learn from wins, losses, replies, and meetings booked

This is where your GTM edge (or lack thereof) stems from.

The simple rule:

• Buy: tools that execute the work (identifies job posts, enriches contacts, generates email copy, sends emails, etc.).

• Own: logic that informs any decision making (what to search for in job posts, which signals to scrape, how accounts are prioritized, etc.).

The Fix: Build a GTM Context Layer

The teams winning with AI have figured out where the edge actually lives. They build an intelligence layer that sits between their raw data and their execution tools – the layer that takes signals and turns them into a point of view only they can produce.

This is your “GTM Context Layer”. A proprietary system that tells humans and agents which signals matter, how to interpret them, what scenario they suggest, who likely cares, and what message fits.

A strong GTM context layer has three parts:

First, a “data foundation”; this is where you bring together the raw ingredients: CRM data, opportunity history, closed-lost reasons, product usage, website activity, enrichment, job posts, news, technographics, call notes, email engagement, partner notes, and rep activity.

Second, GTM decision logic: This is the rules-based layer that defines your ICP, personas, account scoring, signal weighting, routing logic, buying scenarios, disqualifiers, and playbooks.

Third, an AI orchestration layer.

This is the workflow layer that coordinates retrieval, tool calls, prompt routing, agent skills, context assembly, and output generation.

It decides what context to pull, which sources to check, which signals to rank, which playbook to apply, and which skill to run for the task.

Do these three things right, and your agents go from:

“Acme is hiring SDRs and had a closed-lost opportunity last year. Reach out about renewed pipeline growth.”

To:

“Acme is hiring SDRs and RevOps, uses a stack we consolidate well, and lost last time due to timing. Prioritize RevOps with a tooling-efficiency angle, Sales with a pipeline-growth angle, and tailor outreach to the pain each team owns.”

Where to Start

You don’t need to rebuild your entire GTM stack overnight.

Start by auditing three things:

1. Audit where your Decision Logic lives: Are you letting third-party AI algorithms decide who you target and how you position your value? If yes, move your ICP definitions back internal.

2. Shift from signals to Scenarios: Stop triggering outreach based on a single isolated event. Instruct your data team to build models that find combinations of events that equal undeniable pain.

3. Constrain the Orchestration payload: Stop asking your tools to guess what to say. Pass them a highly restricted, hyper-contextual payload for every single prospect.

You don’t have to do all three at once. Even one of these moves a real decision back inside your business, and ahead of every competitor running the same default logic.

Closing

AI for GTM underperforms for a boring reason: teams automate the execution and under-invest in sharpening the upstream judgment behind it.

Everyone has the same models and the same off-the-shelf signals now. What separates the teams that pull ahead is what they own upstream of execution: the custom signals they build and the context layer that knows why this account, why now, who to reach, and what to say. That’s the difference between the Acme email no one answers and the one that earns a reply.

AI doesn’t replace your strategy. It just exposes how good it actually is – and most of today’s implementations are proof of this.

Most go to market teams run on fragmented knowledge.

The information that sales, marketing, RevOps, and leadership need to do their jobs usually lives across Slack threads, Google Drive folders, Notion pages, and people’s heads.

With AI agents available to us, this is a very costly way to operate.

When company knowledge is scattered, your team pays for it in three ways:

Lost selling time: Reps spend hours searching for answers: “Do we support this integration?” “How do we compare to this competitor?” “What’s the best case study for this account?” Every minute spent digging for information is time not spent selling.

AI hallucination. You connect an AI assistant to your Google Drive and expect it to work. Instead, it finds three different versions of your positioning doc, tries to “average” them into an answer, and confidently returns false information. This cost compounds when someone acts on it in a customer conversation.

Slower onboarding. New hires take months to become productive because knowledge is not documented clearly. They absorb it through Slack, customer calls, and osmosis.

Why Traditional Wikis Don’t Solve This

Most teams already have a wiki across tools like Notion, Google Drive, Confluence, or a combination of the three.

The problem is that these tools were built for human browsing, not machine knowledge retrieval. When you try to layer AI over a traditional wiki, you usually hit three walls:

• First, the AI struggles with ambiguity: It can technically read the content, but it does not always know which page is current, which version is canonical, or whether a definition is still relevant. Machines need a clear file hierarchy.

• Second, there is no enforced structure: Version history may exist, but ownership, freshness, metadata, and review workflows are rarely consistent. Important changes get buried. Outdated pages keep ranking in search.

• Third, Wikis are graveyards: That battle-card from 2022 still exists, polluting your search results. Without the forced hygiene of a repository (where outdated code is explicitly deprecated or deleted) your AI will eventually prioritize stale data.

The takeaway here is that company knowledge should be stored in a format machines can reliably read, search, validate, and act on.

The same way software teams have been storing code for years.

The Better Way: Knowledge-as-Code

A Knowledge-as-Code system stores company knowledge in a GitHub repository as structured Markdown .md files.

Every policy, playbook, definition, proof point, process and positioning document lives in a clear file hierarchy. Every file has metadata. Every change is reviewed. Every important definition has an owner.

This isn’t theoretical. It’s how software companies manage their codebases. We’re just applying the same discipline to unstructured company knowledge.

A simple Knowledge-as-Code repo gives you four major benefits:

1. Version Controlled and Auditable

In GitHub, every change requires a pull request (“PR”). This means you can see:

• What changed (the diff)

• Who changed it and who approved it

• When it changed

• Why it changed (the PR description)

This turns your company policy into a traceable audit trail. When Finance asks “Why did our ARR calculation change?” you can point to the exact commit with relevant details.

That level of traceability is hard to maintain in a traditional wiki.

2. Machine-Readable for AI (RAG-Optimized)

Traditional wikis are formatted for human readers. Markdown files with YAML frontmatter are easier for machines to parse.

For example, every file can include metadata like:

slug: revenue-recognition-policy
status: canonical
owner: @finance-lead
last_reviewed: 2026-04-15
review_interval: 6m

This matters because LLMs need to know what topics a file covers, whether a file is canonical, and when it was last reviewed.

Instead of forcing the AI to synthesize an answer from three conflicting drafts (and confidently “hallucinate”), you point it to a single governed source of truth. The answer becomes:

According to revenue-recognition-policy, owned by Finance and last reviewed on April 15, 2026, revenue is recognized when...

This is the difference between generating plausible answers and retrieving governed company knowledge.

3. Automated Governance

Most documentation fails because it lacks a maintenance loop. Knowledge-as-Code fixes this by making maintenance part of the system. Here are the three key parts:

• Every file has a designated “Subject Matter Owner” that’s responsible for its accuracy.

• Automated checks that flag any file that hasn’t been reviewed in six months. Pull requests can route updates to the right reviewer.

• A designated “Librarian” that’s responsible for keeping the knowledge base clean. They review pull requests, enforce naming conventions, prevent duplicate documents, resolve conflicting definitions, and make sure new knowledge does not create more ambiguity.

4. Headless Knowledge Architecture

Once your knowledge lives in structured Markdown, it can be surfaced anywhere.

GitHub becomes the source of truth, but the knowledge can be piped to wherever your team is working:

• AI assistants for drafting, strategy, and Q&A.

• Slack bots for instant internal lookups.

• Sales enablement and onboarding portals.

• Applications such as programmatic outbound tools.

This is the power of a headless architecture. The knowledge lives in one governed place, but it can be consumed by many applications.

What Your Knowledge Base Should Include

This will differ from organization to organization, but most GTM knowledge bases should cover seven core categories.

The goal is to document the information your team repeatedly needs to make decisions, answer customer questions, create content, and run sales processes.

1. Start Here (README.md)

This is the entry point. It should explain what the knowledge base is, how it’s organized, who owns it, how to contribute, and what standards people should follow when creating or updating documents.

Include:

• Folder structure and naming conventions

• Contribution and review processes

• Examples of good documentation

• Instructions for how AI tools should read the knowledge base

2. Company Context

This is the foundational information every GTM team member should understand.

Include:

• Company overview

• Mission and narrative

• Target customers

• Brand voice and approved language

• Design guidelines

This is the base layer for consistent communication.

3. Positioning and Messaging

This is where your market-facing strategy lives.

Include:

• Core positioning

• Category narrative

• Value propositions

• Persona-specific messaging

• Competitive playbooks

• Customer proof points

This is one of the highest-leverage sections because it directly impacts sales conversations, outbound messaging, website copy, sales decks, and AI-generated content.

4. Products and Offerings

This section explains what you sell, who it is for, how it works, and when to position each offering.

Include:

• Product overviews

• Packages, plans and services

• Feature descriptions and technical details

• Pricing information

• Implementation notes

• FAQs

• Roadmap where appropriate

The key is to make this practical. A rep should be able to find answers to the questions they’ll receive from technical buyers.

5. Processes and Operating Rules

This is where internal GTM execution gets documented.

Include:

• Inbound lead routing

• Sales process

• Qualification criteria

• Handoff rules

• CRM hygiene

• Forecasting guidelines

• Data models

• Source-of-truth definitions

This section is less glamorous, but it prevents tribal knowledge from becoming operational debt.

6. Content, Skills, and Templates

This is where your knowledge base becomes an execution layer, not just a documentation library.

Include:

• Outbound email frameworks

• LinkedIn post writing prompts

• Call prep templates

• Sales deck generation prompts

• Case study transformation prompts

7. Definitions and Metrics

This section prevents confusion across your humans and agents.

Include:

• Rules of engagement

• Revenue definitions

• Sales stage definitions

• Qualification definitions

• Account scoring definitions

This matters because AI is only as useful as the language and definitions it’s grounded in. If terms are defined inconsistently, LLMs will inherit that confusion.

How to Build It Without Writing Hundreds of Files Manually

You don’t need to manually create hundreds of Markdown files from scratch.

I recommend these three phases for your initial implementation:

1. Start With Knowledge Archaeology

Identify tribal knowledge bottlenecks and high-frequency questions:

• Start with the questions people ask repeatedly in Slack, sales calls, onboarding sessions, deal reviews, and manager one-on-ones.

• Interview subject matter experts to capture nuance that is not documented anywhere else.

2. Use AI as the Transpiler

Have your subject matter experts dump knowledge in whatever format is easiest for them (voice memos, docs, screen recordings, raw notes, etc.). Then use AI to convert that raw material into structured Markdown with standardized frontmatter, clean headings, consistent formatting, and clear ownership.

AI should not be the final approver, but it is very good at turning messy knowledge into usable first drafts.

3. Designate Your Librarian Early

Designate your “Librarian” to own the quality of the repository early. They’ll begin by reviewing all PRs and are ultimately responsible for enforcing standards, resolving conflicts, keeping the structure clean, and making sure new docs do not duplicate or contradict existing ones.

Without this role, your knowledge base will eventually recreate the same mess you were trying to escape.

Once your repo has been created with processes in place, your next task is to connect your knowledge base to AI.

Connecting Your Knowledge Base to AI

Finally, you’ll have to decide how the AI actually "consumes" your GitHub knowledge base. Most teams either over-engineer too early or pick an integration that doesn't fit their daily workflows.

There are three practical levels:

A Note on Manual Uploads: I’ve omitted manual methods like dragging .md files into a chat or using URL-based scrapers. These create immediate "knowledge debt" because they lack a sync engine; as soon as your GitHub repo evolves, your manual context becomes an outdated liability.

Level 1: Local Workspace

This is the simplest (mostly automated) starting point.

Tools like Cursor or Claude Code operate on a local clone of your GitHub repo.

The flow looks like this:

GitHub → Local Repo → AI reads files directly

When the knowledge base changes in GitHub, you run git pull in your local repo to bring down the latest files. If you edit locally, you commit and push those changes back to GitHub. The AI reads whatever version exists in your local workspace at that moment.

The important piece is a root instruction file, such as CLAUDE.md or an equivalent repo-level guide. This file acts like the system prompt for your knowledge base and tells the AI what the repo contains, which files are canonical, how to cite sources, and how to behave.

Pros:

• Zero infrastructure

• Great for drafting, strategy, and iteration

• Easy to maintain

• Strong context when the repo is clean

Cons:

• Limited to local workflows

• Does not automatically live inside adjacent tooling or applications

For most operators, this is the right place to start.

Level 2: Retrieval System

This is the standard production-grade RAG (Retrieval-Augmented Generation) setup.

The flow looks like this:

GitHub → Sync → Database → Chunk + Embed → Retrieve → LLM

When a user asks a question, the system searches your documents, pulls the most relevant chunks (i.e., “Positioning”), and feeds only those chunks to the model.

Pros:

• Scales across larger document sets

• Works inside custom apps

• Can power Slack bots, internal tools, and CRM workflows

Cons:

• Requires engineering work

• Requires a database or vector store

Build this when you need the knowledge base to serve a broader team through a shared interface.

Level 3: Enterprise Retrieval

Enterprise retrieval adds hybrid search, reranking, permissions, evaluation, and more advanced governance.

The flow looks like this:

GitHub → Ingestion → Chunk + Embed → Hybrid Search (Vector + Keyword) → Reranking → LLM

The key addition is reranking. A second model or ranking system evaluates the retrieved results and makes sure the most authoritative content is surfaced before the LLM generates an answer.

Pros:

• Higher precision

• Better for thousands of documents

• Better for complex permissioning and enterprise-scale knowledge systems

Cons:

• More expensive

• More complex

• Requires dedicated engineering support

Unless you have thousands of documents and a dedicated AI engineering team, you probably do not need this yet.

Where MCP Fits

The Model Context Protocol (“MCP”) is often misunderstood. MCP does not upload your knowledge base to a model’s brain. It gives the model a remote control to your tools.

Use MCP for actions like:

• Opening pull requests

• Fetching a specific file from GitHub

• Querying a live database

• Updating a system of record

• Triggering workflows

MCP is inefficient for teaching the model your entire positioning, brand voice, sales process, or competitive strategy. It’s better for finding a needle in a haystack than for understanding the haystack itself.

Recommended Setup

My advice for most operators is don’t over-engineer. Start with GitHub as the source of truth, then:

1. Use Cursor or Claude Code for strategy, drafting, messaging, and internal Q&A.

2. Add MCP when you need AI to take actions inside your repo or tools.

3. Build a retrieval system when you need to expose the knowledge base to the broader organization.

4. Add enterprise retrieval only when scale and complexity justify it.

Final Thoughts

If your GTM knowledge is scattered across Slack, Drive, Notion, outdated decks, and people’s heads, AI will inherit that mess.

Instead, create a clean, governed, machine-readable knowledge base in GitHub.

Start with a simple seven-section Markdown repo. Add ownership, metadata, review workflows, and a root instruction file. Use local AI tools first. Add retrieval and agents later.

When you structure knowledge properly, everything downstream gets easier: onboarding, sales execution, content creation, internal Q&A, outbound personalization, and AI automation.

It becomes the critical infrastructure you need to succeed in today’s environment.

Subscribe now

-Cam Wright

P.S. if you enjoyed this article, feel free to leave a “like”, “comment” or “subscribe”. I read every comment and will make sure I get back to you.

Most outbound fails for one reason: You’re targeting companies, not problems.

In this post I’ll walk through what that means, how to fix it, and some real-life examples from Grafana Labs.

Before we dive in, some quick background on why targeting matters so much in 2026:

Why Targeting is Crucial

Targeting and ICP (and other basics) aren’t “sexy” topics right now – everyone is trying to figure out how to deploy agents and automate their GTM motion wherever possible.

Ironically, I think that’s why it’s now more important than ever:

AI and agents amplify what you’re already doing. Period. If you have the basics down, automation can be extremely effective, but if not, you can be amplifying spam that gets your domain blacklisted.

Today's outbound playbook looks nothing like it did five years ago. Back then, high-volume templated sequences worked – landing in the primary inbox wasn't a challenge, and volume was the game.

But in the last few years, email providers have cracked down on spam, made it much harder to land in the “Primary” inbox, started banning domains, and have even limited the amount of emails you can send.

This means that today, you have a smaller, finite number of at-bats for cold email.

And as a result, targeting has become the main bottleneck for effective cold email: If your targeting is broken, no amount of AI or automation can save you.

Targeting via First Principles

Eric Nowoslawski, founder of Growth Engine X, teaches three strategies for list building: ‘Forward’, ‘Backward’ and ‘Circular’. Each has its place, but if you’re an early-stage founder or sales leader without many customers to analyze, you need to rely on the “forward” (in other words, first principles) approach.

First Principles Targeting Mistakes

The first (and obvious, surface-level) targeting mistake is being too broad.

Companies will define their ICP as “Series A-B fintech companies in the US with 200-500 employees” and then get confused when their email campaigns don’t convert.

Now, the fix may seem simple (“narrow your criteria”) but being too broad is actually just a symptom of the actual, fundamental issue behind most targeting definitions:

Not building your targeting criteria based on the actual problem(s) you solve.

This is the biggest re-frame: company filters ≠ problem indicators.

A Series B fintech with 300 employees might have your problem. Or they might not. Industry and company size doesn’t tell you.

You need to start with the problem, and then work upward to define aspects of your target profile. Not the other way around.

There’s three parts to doing this effectively: “Problem Definition”, “Solution Fit” and “Economic Drivers”.

Let’s start with Problem Definition.

Layer 1: Problem Definition

You need to ask yourself three questions:

1. What specific problem do you solve?

2. What’s evidence a company is experiencing this problem?

3. What’s evidence they’re actively trying to solve it?

Here are a few examples for Grafana Labs (note: Grafana Labs provides an observability platform built on open-standards that enables companies to keep their software up and running):

Specific problem: “Companies with high mean-time-to-resolution ("‘MTTR’) caused by observability data fragmented across multiple proprietary-agent tools, leading to slow correlation and troubleshooting during incidents”.

Note this is specific, not just “companies struggling with observability”.

Evidence of problem(s): “Several observability platforms listed on job postings and employee LinkedIn profiles, customer complaints on G2/Gartner/Reddit, downtime, distributed cloud architecture (this drives up complexity), an engineering blog mentioning fatigue, etc.” The list goes on.

Evidence of effort to solve: “Adopting Open Telemetry (vendor neutral code instrumentation that enables a migration), increased SRE job posts and/or recent hires, consolidation initiative on job posting, etc”.

I recommend starting with 1x problem and 3x evidence of the problem / effort to solve. Here’s a quick exercise:

Exercise: Problem Evidence Mapping

Problem I solve: _________________

3 observable signals a company has this problem:

1. _________________

2. _________________

3. _________________

3 observable signals they’re trying to solve it:

1. _________________

2. _________________

3. _________________

Layer 2: Solution Fit

The tough pill to swallow: not every company with the problem you solve is ‘right’ for your solution. Lots of ICP frameworks fall apart here.

They identify the problem but ignore the competitive context.

Answering these three questions will help you determine which companies dealing with these problems favourably map to your solution:

1. How else could they solve this problem? (List alternatives)

2. In what scenarios is your approach superior?

3. What’s evidence of those scenarios?

For example, if you’re selling a Prometheus and Grafana native observability solution (Grafana Labs 3-4 years ago before our SaaS platform was built out), you’re not superior for everyone with observability problems.

You’re superior for companies already invested in Grafana and Prometheus who want to maintain cost effectiveness and avoid vendor lock-in. If a company doesn’t care about these things, another solution may be a better fit.

Evidence of this scenario could be: Active Grafana doc views, GitHub repos showing Prometheus deployments, blog posts about open-source observability philosophy, job descriptions mentioning “Prometheus expertise required”, etc.

ICP isn’t “companies with observability requirements”. It’s “companies with observability requirements AND a Prometheus-first architecture AND dense engineering talent AND preference for open standards”.

See the difference?

Here’s the second exercise:

Exercise 2: Competitive Positioning Matrix

Alternative solutions to my problem:

1. _________________

2. _________________

3. _________________

My solution is superior when (be specific about conditions):

1. _________________

2. _________________

3. _________________

Observable evidence of those conditions:

1. _________________

2. _________________

3. _________________

Layer 3: Economic Drivers

Budget is a rough proxy for cost of pain.

A perfect-fit company with a $5K budget (low cost of pain) is a bad prospect if your ACV is $50K.

You’ll want to reverse-engineer where your biggest deals will come from (and in turn, where the most “pain” is), and focus your outbound efforts there. The people most willing to give you money are also the most willing to respond :)

Here are the three questions to predict propensity to spend:

1. At which types of companies does this problem have the highest cost of inaction?

2. What are the drivers of larger deal sizes?

3. What’s evidence of those scenarios?

Note: there’s typically a strong correlation between company size and deal size but that’s not all this is about. A 500-person company might have a tiny problem (budget: $10K) or a massive one (budget: $500K).

Here’s how I’d think about the economic-drivers of our ICP at Grafana Labs:

Highest cost of inaction:

Companies with customer-facing software tied to revenue (i.e., SaaS). Bonus points for low-switching costs (ease of losing a customer due to slowness/downtime). Inaction (or continued poor product performance/uptime) is expensive as it results in customer churn and slower feature development (slower customer acquisition rate).

Drivers of large deal sizes:

Observability is typically purchased via the consumption model, so more data → larger deals.

Evidence:

Company has customer-facing software, they have a large customer base, they’re expanding rapidly (headcount, revenue or funding) they run a distributed cloud architecture (higher telemetry volume, all else equal).

It might seem obvious because it’s OpenAI, but this is why OpenAI spends $200M/year on their observability vendor: Customer facing product, tons of users, growing fast, runs on the cloud, and low switching costs for a user to move to Anthropic, Gemini or xAI.

Extended downtime could be existential.

Exercise 3: Financial Fit Mapping

Company characteristics that imply high cost of inaction:

1. _________________

2. _________________

3. _________________

What are your drivers for larger deal sizes?

1. _________________

2. _________________

3. _________________

Observable evidence of these characteristics:

1. _________________

2. _________________

3. _________________

From Criteria to Scoring: Making It Operational

Now you have a list of characteristics – but there’s one more step.

Not all characteristics are ‘targetable’ until you translate them into objective ‘criteria’ or ‘signals’. This is where you separate “static” from “dynamic” criteria:

• Static criteria tell you who could buy

• Dynamic signals tell you who will buy now

Static criteria → company characteristics that define your universe (industry, headcount, tech stack, funding stage).

Dynamic criteria → time-sensitive signals that indicate urgency (recent funding, new job postings, leadership changes, product launches).

Exercise 4: Build Your Scoring Framework

Static Criteria

• _________________

• _________________

• _________________

Dynamic Criteria

• _________________

• _________________

• _________________

Next Steps

Once you’ve completed these exercises, you’ll have a well-defined and easily targetable ICP. To validate, I recommend plugging this framework and your flagged criteria/signals into a few LLMs to get feedback and refine what you’ve built.

You can then translate this into an internal source of truth or skill (.md file) that can be read by LLMs and used to start building your outbound campaign targeting.

-Cam Wright

P.S. - if you enjoyed this article, feel free to leave a “like”, “comment” or “subscribe”. I read every comment and will make sure I get back to you.

It’s February 2026 and other reps keep telling me that they’re booking less and less meetings through email.

On one hand this is no surprise. Buyers’ inboxes are being flooded with poorly AI-generated and automated emails. The bar to stand out keeps getting higher and higher, which forces most reps into a vicious feedback loop: after response rates drop, the instinct is to increase quantity to compensate, so quality falls, delivery is damaged and response rates drop even more.

However, with quality falling as everyone struggles to make the channel work, an opportunity has opened up for organizations that do three things extremely well:

1. Targeting: Account selection, specificity and timing

2. Content: Subject and email body text

3. Deliverability: Frequency of landing in the primary inbox

This article focuses on maximizing outbound email results through #2, Content.

Let’s dive in:

The Goal of Outbound Email

Before getting into the strategies, let’s make sure we’re on the same page.

At the fundamental level, a rep’s goal with an outbound email is to get a positive reply: a meeting, a referral, or at a minimum, helpful information.

Assuming the email is relevant and seen (targeting and deliverability working), buyers respond positively when two subconscious “green flags” flash in their brains:

1. Expertise: ‘This person knows their stuff and might help me’

2. Detachment: ‘Talking to them won’t be uncomfortable or pushy’

People actively avoid pushy reps, even when the product seems useful, because they don’t want to deal with aggressive follow-ups and pressure tactics.

With expertise and detachment as our ‘North Stars’, we have two levers to pull within our copy:

1. Information (the ‘What’): The specific facts and insights you share to prove you’re an expert.

2. Delivery (the ‘How’): The tone and formatting that signal you’re not a pushy solicitor.

“Information” is why they should care, but “Delivery” is why they actually reply. Let’s start with the ‘What’: Information.

Information

The best way to position yourself as an expert with information only is to:

1. Demonstrate you understand their world

2. Highlight a problem worth solving

3. Introduce a benefit associated with responding

And the simplest way to achieve these three objectives is to structure every cold email around four pillars:

1. Observation

2. Impact

3. Solution

4. Call-to-action

These are the four pieces of information you’ll try to “check off” with every cold email you send.

Observation

The observation is your “earned” entry into their inbox. It’s your reason for reaching out – something you saw, heard, or read about their business that proves it’s a targeted email.

The ideal observation: A company initiative or goal that implies they should care about the problem you solve.

Every company has dozens of problems but limited resources to solve them. When you lead with an observation that suggests it would be reasonable for your problem to be prioritized, you align your interests with theirs and earn the right to pivot into a ‘negative’ topic without seeming assumptive or insulting their current approach (no one likes their ‘baby being called ugly’).

Some common observation sources:

• Conversations you’ve had with their coworkers

• Company or department initiatives

• Product announcements or changes

• Job openings and descriptions

• Industry news or shifts

As an example, let’s say I’m selling an AI SDR to a VP of Sales:

I find a LinkedIn post from their SDR Manager, Dave: “Hiring 4 SDRs to support our 100% revenue growth target in 2026.”

Instead of leading with “your SDRs aren’t good enough,” I reference the hiring plans and growth goal. Same problem (pipeline capacity), but now I’m aligned with their priority rather than criticizing their team.

If you can’t find a relevant initiative, default to a pain-related observation, but remember the bar is higher for making it land without defensiveness.

Impact

This is where you call out the pain or missed opportunity – the downside of their current approach.

Three rules for writing impact sentences:

1. Match their seniority level

Executives care about business outcomes (revenue, growth rate, valuation). Practitioners care about process pain (time wasted, manual work, frustration). Tailor accordingly.

2. Imply a cost of inaction (‘COI’)

The strongest impacts have a “negative consequence” if nothing changes factor built in. This is easy for cost savings (wasting money), but harder for things like process improvements. Either way, try to think of something that your reader can quantify as they read.

3. ‘Soften the blow’

Try not to sound accusatory or overly certain – this can trigger defensiveness. Use wording like “what usually slows teams down” or “the challenge I’ve seen” instead of direct “you’re doing this wrong”-type phrasing. Remove anything that suggests blame or fault.

Here’s an example of “Impact” building on our AI SDR example:

Long ramp cycles delay pipeline by 4-6 months (pushing revenue into future quarters), compounded by the fact that SDRs are bottlenecked by manual research, lots of sales leaders are finding it hard to achieve their plans.

Solution

This is where you introduce the alternative way of doing things or new opportunity that your solution enables.

Effective approaches:

• Customer stories (”how Company X solved this”)

• Metrics (”increased pipeline 30% in 60 days”)

• Workflow explanations (”here’s what changes”)

Your solution statement should also be tailored to your prospects seniority:

At the executive level customer stories and statistics are typically most impactful (“[competitor] increased [metric] by 30%” by doing…”), whereas at the practitioner level a specific explanation of the new workflow (“here’s what changes”) can land well. Especially with technical buyers.

I recommend mixing approaches: a customer story + specific workflow details often lands best.

AI SDR example:

Automates targeting, research, hypothesis generation and email drafting, providing the pipeline output of 3-5 ramped SDRs immediately, without the hiring timeline, onboarding cost, or performance risk.

Call to Action (‘CTA’)

This is where you ask for the next step.

The CTA is where most reps lose the “Expertise + Detachment” balance. They build credibility through the email, then ruin it by sounding “needy” at the end.

The Data: Interest vs. Time

Gong’s data shows us that interest-based CTAs (asking if they care about the topic) outperform time-based CTAs (asking for a spot on their calendar).

Why? Asking for a meeting before they’ve agreed it’s valuable feels presumptuous – like you don’t respect their time or care whether this actually helps them.

The goal: Make your buyer feel in control of the entire interaction.

When you ask for interest instead of time, you give them an out. Ironically, by giving them an out, they are more likely to lean in.

Asking “would this be worth exploring?” or “interested in hearing how [Competitor] tackled this?” keeps them in charge and makes grabbing time with you feel low pressure.

Delivery

Delivery is the emotional perception of your message. You can have the best “Information” in the world, but if it’s wrapped in a formal, dense wall of text, your buyer will instantly categorize it as “Spam”.

To nail your delivery, focus on these three levers:

1. Scannability

Most emails are opened on cell phones. Keep it under 100 words so the entire message fits on the screen without scrolling.

2. Reduce cognitive load

Write at a 5th-8th grade reading level on the Flesch-Kincaid scale. Short sentences. Common words. One idea per sentence.

If you find yourself using complex vocabulary, it’s usually a sign you don’t understand what you’re selling well enough to explain it in simple terms. Busy prospects won’t work that hard to decode your message.

3. Be casual

Be conversational, not corporate. Use some lowercase words in the subject line. Use contractions (it’s, don’t). Write like a person who is busy, but helpful.

• Bad: “I hope this message finds you well.”

• Good: “Saw your post about the new GTM hire.”

Putting it All Together

Here’s what a cold email to a VP of Sales selling an AI SDR looks like using this framework.

As an experiment, I asked Gemini to write this email with only a single prompt and didn’t change anything. The prompt I used was:

“Can you follow the strategies outlined in this article to write a cold email to a VP of sales if you were an AI selling an AI SDR? [Entire article up to “Putting it All Together” pasted here]”

Here’s the output:

The Verdict

Not bad for an AI one-shot. Is it perfect? Not quite. If I were sending myself I’d make a few tweaks:

• I’d try to make the “observation” a bit more specific: can I find anything that the 2026 growth targets unlock? (i.e., funding round, IPO, etc.).

• The “impact” is strong but the two sentences could be tied together better (i.e., adding something about ramping in the second sentence).

• I’d mention AI or automation in the “solution” line somewhere so it’s clear I’m not selling a service.

• Make the CTA more specific: “framework” doesn’t seem like a great word choice here.

Wrapping Up

By establishing expertise and detachment through the four pillars instead of leading with a pitch, you create emails that ‘earn’ replies rather than demand them.

Writing is the easy part. The hard part is research: finding relevant observations, understanding the true impact and knowing which solution angle will resonate. This is where AI should be focused: surfacing signals, connecting initiatives to pain points and identifying timing triggers.

-Cam Wright

P.S. - if you enjoyed this article, feel free to leave a “like”, “comment” or “subscribe”. I read every comment and will make sure I get back to you.

I’ve seen dozens of recent takes about the rise of the GTM Engineer (‘GTME’) and the death of the SDR:

“The rise of the $200K SDR”, “GTM Engineers are the future”, and “I replaced my entire SDR team with Claude Code” are typical headlines.

These comparative takes miss the point.

Each role plays a crucial but different part in your go-to-market motion – and the top AI-native companies seem to agree. OpenAI, xAI, even Clay (who coined the term "GTM Engineer") are all hiring for both roles right now.

The debate shouldn’t be “GTM Engineer vs. SDR”. It should be “how do I get the most out of each role at my current stage?”

This article provides a framework for deciding when your outbound should be GTM Engineering-led (automated) versus SDR-led (human-in-the-loop) – and when that should change.

Let’s dive in.

First, Let’s Review the Differences Between GTM Engineers and SDRs

The GTM Engineer:

GTM Engineers have a unique skillset that sits at the intersection of technical chops and go to market strategy. They create lists, set up email infrastructure, build automations with code, and orchestrate automated signal-based outbound at scale (we’re talking 5,000+ accounts at a time). Today, most GTMEs report through RevOps.

SDRs:

SDRs are typically aspiring Account Executives (and should be your talent pipeline). Good SDRs excel at account based prospecting, cold calling, relationship building, and formulating hypotheses. They sometimes report to Marketing but should (in my humble opinion) report to Sales.

Comparison:

The main difference between the two skillsets as it relates to outbound can be captured by this chart:

For those who didn’t take Economics 101: each line represents the relationship between “Quality of Touches” (i.e., how effective/thoughtful the attempt to break into the account is) and “Number of Accounts Covered” (i.e., how many accounts the rep is working).

The main takeaway: SDR (human-in-the-loop) quality is higher when focused but GTM Engineers (automated) can cover much more ground at a decent quality.

Going a step further, you can see there’s an “inflection” point when the GTM Engineer-led automated approach becomes more effective than human-in-the-loop:

Of course, this depends on industry and company-specific factors (i.e., market awareness, available signals, competition, etc.), but the inflection point is usually in the range of 250-500 accounts per rep.

If you accept this, the outbound strategy question becomes a lot easier to answer:

It shifts from ‘philosophical’: “should I automate outbound or take a human-in-the-loop approach” to ‘economical’: “when does it make business sense for my reps to target more than 250-500 accounts each?”

The Decision Framework

This all depends on market penetration, deal economics and go to market budget:

1. Market Penetration: Extent of awareness, message and product-market fit.

2. Deal Economics: Average cycle complexity, cost and transaction size.

3. Budget: How much you can afford to invest in outbound and top-of-funnel.

These three variables (typically) have some level of correlation and leads to companies falling into one of four go to market “zones”.

This chart shows the four go to market “zones” and which channel should own outbound for each zone:

When GTM Engineers Should Own Outbound:

GTMEs should automate outbound (to >250-500 accounts each) in two scenarios:

1. Early-stage startups with low market penetration (tons of targets, low budget).

2. Low-ticket solution ($10-$25K ACV range) that can’t justify a higher CAC.

GTMEs can target 5,000+ accounts through systematically tailored outbound, and in the two above scenarios, the economics of this approach works best:

Let’s say you have 5,000 target accounts, get 1% conversion, and close deals at $15K ACV. That’s $750K in pipeline. If a GTM Engineer costs $150K fully loaded, that’s a 5:1 pipeline-to-cost ratio. The same budget gets you two SDRs who can cover 1,000 accounts combined. Even if conversion triples to 3%, you’re still getting worse economics with only $450K in pipeline generated.

When GTM Engineers Should Support SDRs/AEs:

Reps should own outbound (and cover <250-500 accounts each) in two scenarios:

3. Proven product market fit and moving upmarket (SDRs own it).

4. Established enterprise vendor (AEs own, SDRs support).

Once you have proven product-market fit and are moving upmarket, human-in-the-loop becomes the better choice for outbound execution.

At this stage, you’re shifting from “cover the entire TAM” to “penetrate key accounts deeply.”

The multi-channel approach starts to matter – calling, social, email and in-person events are all required. SDRs and AEs can multi-thread into accounts, build relationships, and establish early champions in ways that automation can’t.

But here’s the key: GTM Engineers shouldn’t disappear. Their role just changes. Instead of owning outbound execution, they shift to building infrastructure and the systems that make each rep 2-3x more effective.

I’ll double down by saying I think it’s a mistake to hire SDRs without first investing in GTM Engineering (i.e., the automation infrastructure they need to succeed).

GTMEs should support AEs and SDRs by building automated:

• Research and signal detection

• Account and contact prioritization

• AI-generated email drafts for reps to review

• Execution of manual workflows

• Analytics for continuous improvement

This is what GTM Engineers are being hired for at established organizations like Notion, Snowflake and Glean as I’m writing/posting this.

Wrapping Up

The companies building the most efficient go-to-market motions aren't choosing between GTM Engineers and SDRs. They're deploying each at the right stage: automation first to cover ground, then human touch to deepen relationships, then both working in tandem as the motion matures.

-Cam Wright

P.S. - if you enjoyed this article, feel free to leave a “like”, “comment” or “subscribe”. I read every comment and will make sure I get back to you.

Most AI-native sales tool looks identical: identify signals, scrape LinkedIn, write an email – and every single one fails in production for the same reason.

These tools are flooding the market with promises to automate prospecting, account scoring, outbound, forecasting, and CRM updates. The reality: pilot fatigue, low rep adoption, poor results, and the perception that AI is nothing more than a research tool.

The problem isn’t the software. It’s that we’re trying to solve a data engineering problem with a UX layer.

The “GTM Engineer” Is a Powerful Wedge – Not the End State

The “GTM Engineer” represents real progress – technical operators who use tools like Clay, n8n and Claude Code to achieve the results of 5 reps. But the role is being sold as the final evolution of sales ops, when it’s really just the next phase.

GTM Engineers excel at building outbound engines and data pipelines, but this works best at organizations when demand outweighs capacity, in other words, when volume beats precision. This is most common today at early-stage and AI-native startups.

As markets mature and these companies grow into their demand, the “bar” to generate pipeline rises and revenue teams will need to shift to account-based selling (‘ABS’) to continue scaling.

The bottleneck shifts from the engineer building systems to the rep responsible for driving and executing a territory strategy. At this point “more touches” isn’t the problem – context is.

This recently played out with Ramp sunsetting its Outbound Automation Teams.

What Ramp discovered is that ‘more touches’ stops working when your market knows who you are. The playbook that generated 30% of pipeline in 2022-23 hit diminishing returns in 2024-25:

As Ramp matured in a crowded market, generating new conversations became harder and humans became a requirement because they could pull from unstructured context.

Quote from Gene Lee, Ramp’s co-founder:

“There are dozens of automated outbound solutions, all operating on similar data which our competitors also have access to… We have multiple flagship products to sell which means our selling motions are more complex. And the world is experiencing cold-outbound fatigue. As a result, the return on fully automated outbound began to plateau as the world changed. Over the last two years, we shifted our strategy.”

See the full post: here.

In other words, it required a level of context and strategy that automation couldn’t provide.

The AI Adoption Challenge

We’ve spent the last year piloting various AI tools at Grafana Labs. On paper, they look great. They can scrape LinkedIn, read a 10-K, and draft “personalized” emails in seconds.

And yet, in almost every case, I’m struggling to get more value than I do directly from Gemini or ChatGPT.

This is because, as a seller, I’m thinking through all of this when I approach an account:

• What’s happening in this account right now

• What technologies are they using and what’s our confidence interval

• What we’ve tried before and why it didn’t stick

• What nuggets can I find in Slack, Gong calls, CRM or support tickets

• Who’s important and what do they care about

• Do we have mutual connections or overlapping investors/board members

• What’s my best hypothesis based on all of this

AI GTM tools have external signals, an overview of our business and access to a few CRM fields, but they don’t have the internal context required to be effective in complex selling environments.

In practice, the tool becomes another tab I have to sanity-check – so it doesn’t save time, it shifts effort into QA. Reps look at the tool and think: “This is fine, but I can do better… and faster… because I actually know what’s going on.” And they revert back to manual.

Building the “Context Layer”

This leads us to the main requirement for the future of GTM: The organization-wide “Context Layer”. We need a “Brain” that connects every piece of tribal and digital data into a single, queryable source. This brain should power every tool and “outcome” of the GTM tech stack:

• CRM (data hygiene, updates)

• Prospecting (account and contact identification, ranking)

• Account hypothesis

• Email personalization and sequencing

• Deal strategy

• Forecasting

The difference between a tool with external signals and one with full organizational context isn’t incremental, it’s transformational.

Take “Account hypothesis” as an example. A generic AI tool might say: ‘They just posted a DevOps Engineer job that references observability tooling – good timing for outreach.’

A context-aware GTM tool would say:

‘They posted a DevOps role that references Datadog. Their new VP Engineering came from a customer – and she’s connected to our Director of Sales Engineering on LinkedIn. On a recent cold call a DevOps Engineer mentioned “visibility gaps in microservices” due to budget limitations. Recommended play: Warm intro through our Sales Engineering Director, position as the cost-effective alternative with a message acknowledging the VP’s Grafana experience.’

The SaaS Gap: Why “Total Context” is a Services Problem

Bridging the “Context Gap” isn’t a feature you can ship – it’s a data engineering project.

It requires connecting systems like data warehouses, vector databases, and unstructured data into a unified, queryable layer that understands relationships between accounts, people, deals, and signals. This is why services are non-negotiable: you cannot self-serve your way into a GTM Brain.

You can see this struggle playing out in real-time with the industry’s biggest player: Salesforce.

With the launch of Agentforce, Salesforce attempted to solve the GTM problem by promising “autonomous agents” that could be deployed across the enterprise with a few clicks. In theory, the ultimate AI solution. In reality, it has faced significant headwinds. As of early 2026, adoption remains sluggish, and many pilots have stalled.

Agentforce’s struggle in the market validates this thesis. Salesforce built world-class AI infrastructure, but even with their resources, they’ve hit the same wall: you can’t ship organizational context as a feature.

Salesforce built a powerful technical engine, but they underestimated the difficulties of addressing the “Context Gap”.

Reports from the field suggest that Agentforce is less effective when it lacks the total context required for seller-level execution. The agent can see the CRM and Slack, but not historical deal patterns, product usage, support history, call transcripts or social connections, and as a result, struggles with nuance.

To Salesforce’s credit, they’ve acknowledged this publicly – their implementation guidance now explicitly states that Agentforce requires ‘clean data, unified context, and workflow mapping’ before deployment.

In other words: services.

The Palantir Parallel: Forward Deployed GTM

Once you accept that GTM transformation is a data engineering problem disguised as a sales problem, you realize that the traditional SaaS model is insufficient. We need a new model: Software-led services.

To understand what this looks like in practice, we have to look at Palantir.

Palantir has proprietary software. But they don’t “sell software” in the conventional SaaS sense. They sell transformations – outcomes that are only possible because they pair the platform with forward-deployed engineers (‘FDEs’) who:

• Live inside their customer’s environment

• Integrate messy data

• Configure workflows

• Build bespoke logic

• Embed into the customer’s operating reality

• Make the tool usable in context, not just in theory

Critically, Palantir charges for this. Their FDEs aren’t ‘customer success reps’ – they’re embedded engineers billed as part of the contract. The software and the implementation are one offering.

This model exists because there’s a ceiling to what generic software can do inside highly variable, high-stakes environments like government, defense, and intelligence (and ironically, enterprise sales).

This is the model GTM software needs to adopt. It’s the only model that actually works when every company’s revenue motion is a snowflake – different ICP, different product wedges, different sales cycles, different data quality.

The GTM software companies that win will start to look like software + forward-deployed RevOps/GTM Engineering. These vendors will provide the software, but they’ll also provide the resources to connect the organizational context that is fragmented across systems, inconsistent, and mostly unstructured.

My Thesis For the Next Five Years of GTM Software

The context layer becomes the “oil” of go-to-market technology. It’s what everything runs on – but it requires extraction, refinement, and infrastructure to be useful.

Every downstream workflow needs the same core capability: a shared “brain” that holds external and organization-wide context and can apply it to specific GTM actions.

To be effective, that brain has to address the “Context Gap” by integrating:

• Internal data (CRM, engagement data, product usage, billing, support)

• Unstructured knowledge (call transcripts, internal messages, notes, docs, emails)

• External signals (company and contact details, initiatives, relevant activity, tech stack)

Once you have that context layer, AI generates measurable ROI: faster deal cycles, higher win rates, and predictable pipeline – because the foundational models finally have the raw material needed to be useful.

Wrapping Up

The era of “pure SaaS” in GTM is coming to an end.

As software becomes a commodity, the focus is shifting back to data engineering, tribal knowledge, and the systems integration that actually makes a seller effective.

If you’re a GTM software founder, your moat isn’t your UI; it’s your ability to ingest context. If you’re a sales or RevOps leader, your job is to establish an internal “Context Layer” as fast as you can.

-Cam Wright

P.S. - if you enjoyed this article, feel free to leave a “like”, “comment” or “subscribe”. I read every comment and will make sure I get back to you.

How many times have you heard the outbound advice: “Just pick 3-5 high-fit accounts to focus on this week”?

As a sales practitioner, it’s reasonable advice. The accounts a rep chooses to focus on at any given time has much more impact on their results than the quality of their email copy or cold call talk tracks.

However, if sellers are manually prioritizing accounts in the AI era, they aren’t being set up for success.

Organizations need to move past the basic static account tiering model (i.e., A, B, C) that’s historically been based on basic industry categorizations, financial data and headcount.

It misses the most important ingredient of account prioritization: Propensity to buy.

With a) LLMs being able to make sense of unstructured text and b) the commoditization of intent signals, go to market teams have an opportunity to modernize account scoring and better equip sellers to generate pipeline, faster.

Let’s dig in.

What Sellers Are Doing Today

Good sellers inherently know that at its core, outbound pipeline generation is a “Next Best Action” problem.

The accounts a seller chooses to focus on at any given time is the highest-leverage decision they can make.

So when sellers are provided with an (at-best) semi-accurate static account tier, they a) don’t trust it and b) want to do their own homework to decide which accounts to focus on.

They compensate by monitoring “dynamic” stuff manually: page views, job postings, trial activity, marketing engagement, social activity, tech stacks, promotions or leadership hires, etc., and factoring this into their targeting decision.

Subscribe now

However, there are two downsides to doing this manually:

1. It’s extremely time consuming (it doesn’t scale).

2. It’s very difficult to do it effectively (tons of data points to find/crunch).

And if your reps aren’t focusing on the prospects most likely to buy, the worst-case scenario isn’t just wasted time –

It’s a $250K ACV opportunity that slipped through the cracks because a rep was busy emailing a ‘Tier A’ account that will never buy, while a ‘Tier C’ account just raised $500M and was actively searching for your solution on G2.

How Operators Can Improve Prioritization

Static rankings are useful but they don’t but they don’t answer the only question that matters at 10:07am on a Tuesday: “Who should I contact next, and why?”

This is where go to market teams can improve account scoring by adding a dynamic layer that updates continuously based on real-time data:

• Account-level website visits

• Product usage or trial activity

• Internal promotions and leadership hires

• Relevant information in job postings

• Relevant social activity (posts, comments, community engagement)

• G2 reviews

This enables them to effectively answer three questions:

• Static: Could this be a good account?

• Dynamic: How good is the timing?

• Total: How good of an account is this right now?

And provide reps with holistic rankings (and eventually, recommendations) based on both static and dynamic components.

This can be applied to contacts as well.

The account is the target, but the contact is the entry point. Contact-level behaviour drives the overall account score, so it’s logical to eventually identify, enrich and score high-propensity contacts for sellers.

Examples of ‘static’ contact ranking inputs:

• Seniority and title

• Role relevance and/or department

• Experience with your product or services (scraped from LinkedIn)

• Track record (i.e., promotion quantity, accomplishments listed)

The ‘dynamic’ weighing can come from things like:

• Recent promotions

• Recent LinkedIn, Github, or Slack activity related to your category

• Page views and marketing engagement

The Benefits of This Approach

This shift moves your team from a ‘volume first’ mindset to a ‘relevance first’ mindset. By automating the ‘who’, ‘when’ and ‘why,’ your reps can focus entirely on the ‘how’ and break into accounts by doing things that don’t scale.

The impact is immediate:

• Increased Pipeline: You’ll see an immediate uptick in opportunities sourced as things stop slipping through the cracks.

• Increased Win Rates: Reps’ time savings can be re-directed towards deal strategy and execution.

• Higher Morale: Sellers hate research; they love selling. This can also be used as a selling point for recruiting top reps.

A Simple Framework to Build This:

• Static Fit Score (25-50%)

  • Your baseline score based on the criteria that doesn’t change often (similar to the static ‘tiering’ that’s done today).

• Dynamic Signals (25-50%)

  • Flexible score that continuously updates based on the latest activity and signals.

• Decay Score (for recent unsuccessful outreach; 25%)

  • If you’ve tried to reach an account multiple times recently and nothing happened, your system should (temporarily) de-prioritize that account so reps stop burning touches and move to higher-probability targets. Then, after a cool-down period, the account can recover.

• Other Things to Consider

  • Ignore accounts where there’s an active deal, recently closed lost opportunity, etc.

The Bottom Line

Many sales teams miss pipeline targets because they rely on outdated, static account tiering. By transitioning to a dynamic ranking engine, RevOps can automate research, reclaim weekly selling time, and ensure reps are always focused on the high-propensity targets most ready to engage today.

If you enjoyed this article, make sure to subscribe. You can also let me know with a “comment” if you’d like to see the build of an Account ranking model in Clay.

-Cam Wright

P.S. - I always love meeting people building in the space. Reach out if you’d like to bounce ideas about outbound, GTM engineering, or AI implementations at scale.

Today it seems like every AI outbound platform is selling the same promise: ‘Scrape the web for signals to reach out to the right accounts at the right time.’ Easy, right? Just watch for things like:

• Funding announcements

• Promotions and new hires

• Job openings

• Tech stack mentions

• Social engagement

• G2 reviews

Well then why aren’t orgs who’ve doubled down on this signal-led approach booking more outbound meetings?

The problem is that these signals have become commodities. When every rep in an industry has the same “why now”, every message sounds the same. In a world of infinite signals, the signal itself becomes noise.

The competitive edge is shifting.

The winning go to market teams in the AI era aren’t the ones with more ‘signals’. They’re the ones who are identifying ‘signals’ unique to their industry and treating these ‘signals’ like evidence of specific buying scenarios, at scale.

In other words, they’re taking a ‘scenario-led’ approach instead of a ‘signal-led’ approach.

Focus on ‘Scenarios’ Instead of ‘Signals’

A ‘signal’ is just a data point, which is only useful if it points to a reason to buy. Every company, even in complex industries like observability, can distill the core reasons companies buy their software or services into a handful of reasons.

So before you build a ‘signal’ library, you should build a ‘scenario’ library.

A scenario can be defined as: A situation where a buyer feels pain and wants a new outcome that your product (ideally uniquely) solves.

For each scenario, write:

1. The current state.

2. Negative consequences of the current state (why do anything?).

3. What they’re trying to do.

4. How you uniquely help them achieve it.

Here’s an example scenario I use at Grafana Labs, “First Pane of Glass”. We sell an observability platform that helps engineering teams maximize the performance and uptime of their software:

1. Current State: Observability data is siloed across several tools.

2. Negative Consequences: Limited system visibility and difficulty troubleshooting is resulting in platform slowness, downtime and customer churn.

3. Desired Future State: A first pane of glass to identify issues proactively and streamline troubleshooting.

4. How Grafana Labs Helps: Grafana’s plugin architecture provides a ‘first pane of glass’ across observability data without any migrations.

Note: During the prospecting phase, it’s important to note these scenarios are just hypotheses. It’s the seller’s job to validate/adjust these hypotheses during the discovery phase.

‘Signals’ Are Just Observable Evidence of a ‘Scenario’

Once you have key scenarios mapped out, signals become easier to find because you’re no longer brainstorming random intent.

You’re asking a more precise question: “What observable evidence would exist if a company was experiencing this scenario?”

That evidence can show up in a lot of places beyond the standard outbound signal stack.

Here are the four categories of signals most teams underuse and a few examples of each:

• Situational (your basic static signals):

  • Competitive and adjacent tech stack

  • Application instrumentation frameworks

• Execution (they’re trying to achieve an outcome):

  • Social posts about tackling specific projects

  • Infrastructure modernization (i.e., cloud migrations, Kubernetes adoption)

  • New product launch (traffic + risk + complexity)

• Pain (evidence of challenges with the status quo or achieving an outcome):

  • Incidents or outages (status pages, postmortems, social posts)

  • High turnover in the department you sell to

  • Margin pressure or cost cutting initiatives

• Active search (in-market for a solution):

  • They’re comparing vendors on G2 / Gartner-style pages

  • They’re viewing your docs, enablement material and implementation guides

  • They’re asking questions in communities (Reddit, Slack groups, GitHub issues)

The ‘signals’ companies choose to monitor for will differ drastically across industries, business models and unique value propositions.

The Real Unlock Is Signal ‘Stacks’

The real magic is when you combine signals to come up with an informed hypothesis about the buying scenarios you’ve defined.

Single ‘signals’ are weak because they’re ambiguous.

A job opening could mean growth… or churn… or backfill… A bad G2 review could mean they’re starting to look at alternatives… or just switched vendors and now feel comfortable sharing their experience publicly.

So instead of ‘signals’, you want ‘signal stacks’: A combination of signals that, when observed together, suggest one of your buying scenarios is present.

In reality, you probably won’t find enough data to have 100% confidence that a given scenario is true, which is why you treat it as a hypothesis.

Here’s an example of what a signal stack looks like.

Pretend you’re selling Grafana Labs’ open and composable observability platform:

Weak single signal: Hiring a Site Reliability Engineer.

Sales angle: “I saw you’re hiring an SRE. We help SREs maximize uptime…”

You don’t have an educated guess as to why the company is hiring the SRE and are forced to default to a generic uptime pitch.

Strong signal stack: Hiring a Site Reliability Engineer + using three observability tools + recent public outage + customer complaints referencing downtime.

Now you have: A plausible pain, urgency, and a great reason to reach out. This is extremely strong evidence of the Grafana Labs ‘Scenario’ I shared earlier (‘First Pane of Glass’):

The sales angle becomes: “I saw the recent downtime and was wondering if you’re hiring SREs as a band-aid for the fragmented stack. We help orgs unify their data so...”

The rep can infer that fragmented tooling is preventing them from debugging effectively resulting in downtime, that they’re trying to fix it by hiring an SRE, and can propose a hyper-relevant solution.

Challenges Connecting Signal Stacks to Buyer ‘Scenarios’

This is the intuition top sellers use naturally, but it’s historically been nearly impossible for junior reps to replicate at scale.

It takes a significant amount of time, intelligence, product expertise and industry knowledge to come up with detailed account hypotheses from subjective cues.

Most reps can observe signals, but don’t change their messaging based on which signals were present.

This is how you end up with the typical emails with “congrats on funding” or “saw you recently joined as CRO” followed by a generic pitch that doesn’t resonate.

This gap is something our RevOps and AI teams are working on addressing at Grafana Labs. The platform is composed of 14 different products that map to different observability personas, problems and initiatives. It’s a ton to learn, and there’s a significant ramp-up time before reps are able to quickly form accurate hypotheses and position the platform accordingly.

AI Finally Makes This Possible at Scale

This type of ‘judgment’ is a perfect use case for LLMs.

AI can now act as the reasoning layer that connects the dots between disparate data points that a human would take hours to correlate.

If you define your scenarios and give the system a baseline (i.e., ‘these signals tend to imply this scenario, and this messaging should be used for this scenario’), LLMs can do the heavy lifting:

• Continuously scan the web for signals and monitor first-party intent data.

• Turn scattered signals into a ranked list of scenarios with the “why” behind each.

• Trigger/recommend the right outbound play at the right moment.

• Draft hyper-relevant messaging for reps to review and send.

This is how you craft timely, relevant, expertise-driven outreach that stands out, gets replies and converts to qualified pipeline at a higher rate.

Implementation Checklist

I’m not going to provide an in-depth implementation guide here, but here’s what you need to build out to serve as your foundational data and logic layer:

• Start by recording your top 3 ‘Scenarios’.

  • These are the three most common situations that someone buys your product/service. Be sure to include current state, negative consequences, desired future state and how you can help them get there.

• Write down the top signal stacks for each scenario (use AI if you have to).

  • Break them down into execution, pain, pressure and solving signals and include the scenario relationship logic.

• Define 1-2 ‘plays’ (email templates or sequences) per scenario.

  • Craft email frameworks with variables to be filled in.

• Push templates or sequences to reps.

  • Display in internal tooling (recommended) or Slack, and push to engagement platform via API for reps to send.

In practice, you’ll be searching for custom signals, coming up with a hypothesis based on the stack of identified signals, and reaching out with how you can help in that specific situation.

The Bottom Line

Outbound isn’t dying. Generic outbound is dying because signals are now everywhere. The edge is moving to operators who can define scenarios precisely, build custom signals that reflect real-world evidence, combine them into stacks, and craft relevant messaging at scale.

If you enjoyed this article, make sure to subscribe. I’d also really appreciate it if you gave a “like”, “comment” or “shared” with your network.

-Cam Wright

Subscribe now

P.S. - I always love meeting people building in the space. Reach out if you’d like to bounce ideas about outbound, GTM engineering, or AI implementations at scale.