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.