The ‘Reverse Targeting’ Method That Doubled Our Pipeline in a Month

By Dr. Eleanor Voss — AI Inspired

Let's be honest: most outbound sales motions are a form of pattern matching. We build ICPs, scrape LinkedIn, filter by title, geography, industry, and then fire away with emails that all sound subtly similar. The model behind the motion is "find more of the same." More of the same, though, is a linear growth strategy, and in a market where everyone is optimizing the same funnels, linear is rarely enough.

We wanted a non-linear lever. Something that used the structural advantages of LLMs and retrieval systems to invert the classic outbound loop. The result was a method we internally call reverse targeting. In one month, it roughly doubled our qualified pipeline without adding headcount, and without a single new seat on a CRM vendor.

Below is the method, the math, and the failure modes we had to design around.

1. The Inversion

Classic targeting asks: "Which companies match our ICP?"

Reverse targeting asks: "Which companies' public signals already look like they've been solving a problem we solve — and can we position ourselves as the more efficient version of what they're already doing?"

The difference is subtle but consequential. In the first case, you're predicting fit. In the second case, you're observing fit. You're not guessing that a company might need you. You're inferring that they are already building something, hiring for something, or writing about something that implies they've felt the pain your product removes.

Formally, if we let $S_c$ be the multiset of public signals for company $c$ — job posts, engineering blogs, GitHub activity, product pages, podcast appearances, SEC filings, support tickets, community posts — then classic targeting computes:

$$\ text{score}_{classic}(c) = f(\text{attributes}(c); \text{ICP})$$

where $f$ is a mostly hand-tuned scoring function over firmographics.

Reverse targeting computes:

$$\ text{score}{reverse}(c) = \max{s \in S_c} \text{sim}(s, \mathcal{P})$$

where $\mathcal{P}$ is a curated corpus of problem representations — the set of textual descriptions of the pain state we solve for, written in the language customers actually use. Not our marketing language. Theirs.

This is the key move. You're not scoring companies against your product. You're scoring companies against the state of the world that makes your product necessary.

2. Building the Problem Corpus

This step is where most teams under-invest and regret it.

We spent two weeks building $\mathcal{P}$. The corpus had ~400 problem representations, drawn from:

• Customer success call transcripts (the "before" state, pre-purchase)

• Support tickets from competitors (we reverse-engineered what their customers struggle with)

• Reddit, HN, and Slack community posts from target industries

• Job descriptions of the roles we'd be selling into — the responsibilities section, not the requirements

• Podcast transcripts where practitioners describe their workflow

Each representation was written in first person, present tense, specific. Not "improve developer productivity" but "our CI pipeline takes 47 minutes and the team has started working around it by running jobs locally, which means CI coverage is inconsistent."

We embedded the corpus with a 7B-class embedding model and stored it in a vector index. The corpus is the "lens" through which every company's signals get interpreted.

3. Signal Collection and Normalization

For each company in our candidate universe (~12,000 mid-market companies in our vertical), we collected:

We didn't use an RAG pipeline in the naive "chunk and retrieve" sense. Instead, we used a two-stage approach:

Stage 1 — Sparse retrieval. We built a lightweight keyword + n-gram index over all signals. This was a precision filter: if a company's signals didn't contain even loosely related terms (e.g., "pipeline," "CI," "deployment," "feature flag"), they dropped out. This cut our universe from 12,000 to ~2,400 companies at roughly 85% recall. Cheap, fast, deterministic.

Stage 2 — Dense retrieval + LLM scoring. For the 2,400 survivors, we chunked their signals into ~200-token windows, embedded them, and retrieved the top-k most similar windows from $\mathcal{P}$. We then fed the top 5 matched pairs (company signal + problem representation) into an LLM with a structured prompt asking it to output:

• A 1-sentence hypothesis: "Company X appears to be building/struggling with Y"

• A confidence score (0–1)

• A "freshness" score (how recent the signal was)

• A suggested angle: what specific pain point to lead with in outreach

The LLM was not generating the targeting. It was interpreting retrieved evidence. The retrieval did the heavy lifting; the LLM did the reasoning. This separation kept costs manageable and made the pipeline auditable.

4. Scoring and Ranking

Each company got a composite score:

$$\ text{score}(c) = \alpha \cdot \overline{\text{sim}} + \beta \cdot \text{breadth} + \gamma \cdot \text{freshness} + \delta \cdot \text{specificity}$$

• $\overline{\text{sim}}$: mean similarity of top-5 retrieved pairs

• $\text{breadth}$: number of distinct signal types that matched (a company matching on job posts + engineering blog + a podcast is stronger evidence than one matching on a single job post)

• $\text{freshness}$: exponential decay on signal age, half-life ~6 months

• $\text{specificity}$: LLM-assessed: how specific the matched problem representation is (a match on "CI pipeline slow" is more specific than a match on "improve developer experience")

We tuned $\alpha=0.4, \beta=0.2, \gamma=0.2, \delta=0.2$ after a 2-week calibration on a holdout set of 200 companies where we knew the ground-truth fit.

This produced a ranked list. We didn't blast everyone. We took the top 500, reviewed them in batches of 25, and hand-wrote the first email for each.

5. The Outreach Template (The Part That Actually Converts)

This is where most "AI-personalized" outreach fails. The template is generic; the personalization is a single sentence grafted on top.

Ours was structurally different. Because we had the evidence chain — the specific job post, the specific blog post, the specific GitHub issue — the email wasn't a greeting. It was a demonstration of attention.

Structure:

Subject: [Specific signal reference]

Hi [Name],

[Sentence 1: Reference the specific signal. Not "I saw you're hiring for
a DevOps role." But: "Your JD for the Staff SRE mentions a 12-minute
deployment target. That's aggressive for a monorepo of your size."]

[Sentence 2: Connect it to the problem representation. Not a product
pitch. A shared observation. "Most teams at that scale find the
bottleneck isn't the CI runner — it's the artifact cache invalidation.
We saw the same pattern at [anonymized peer company]."]

[Sentence 3: One concrete, low-friction CTA. Not "let's hop on a
call." But: "If you want, I can put together a 10-minute analysis of
your current pipeline topology. No deck, no sales. Just the math."]

[Name]

The CTA is a work sample, not a meeting. We were giving them the first deliverable for free. The second email, if they replied, was the actual analysis. The third was the pitch.

Open rates: 34% (industry avg for B2B SaaS is ~21%). Reply rate: 12% (avg ~5%). Meeting booked: 4.1% (avg ~2%).

6. The Results

One month, 500 emails, 46 replies, 24 meetings, 11 demos, 6 POCs, 3 closed-won.

Funnel (n=500)
Open        ███████████████████████████████ 34.0%
Reply       ████████ 12.0%
Meeting     ███ 4.1%
Demo        ██ 2.2%
POC         █ 1.2%
Closed      █ 0.6%

Pipeline value: $1.4M (weighted). Compared to our baseline month: $0.7M. Roughly 2×.

The interesting part: 19 of the 24 meetings were with companies that had no traditional ICP match. Different industry, different size, different geography. Reverse targeting found them because their behavioral signals matched the problem corpus. They were solving our problem with a workaround, and we were the first vendor to describe their workaround back to them with specificity.

7. Failure Modes (And How We Handled Them)

Signal staleness. A job post from 8 months ago tells you the company was building something. It doesn't tell you they still are. The freshness decay in the score helps, but we also added a "corroboration" check: if a company's only matching signal was a single stale job post, we down-weighted them.

False specificity. The LLM occasionally generated a "hypothesis" that was plausible but wrong. A company posting for a "platform engineer" wasn't necessarily struggling with CI. They might be building an internal developer portal. We mitigated this by requiring at least 2 matching signal types before a company qualified for outreach.

Corpus drift. $\mathcal{P}$ is a snapshot. Customer language evolves. We refresh the corpus quarterly by pulling the last 3 months of CS call transcripts and re-embedding. It's a maintenance cost, but it's the difference between a 2× and a 1.3×.

Cost. Total inference cost for the 500-email campaign: ~$380. For a $1.4M pipeline, that's not the interesting number. The interesting number is the human review time. We spent ~18 hours reviewing the 500 companies. For a 2× pipeline, that's a very good ROI on analyst time.

8. What This Actually Is (And Isn't)

Reverse targeting is not a new algorithm. It's retrieval-augmented inference applied to a sales motion. The LLM is not doing the targeting. The vector index is. The LLM is doing the interpretation and the language generation. The retrieval system is doing the evidence gathering.

What's new is the structure of the pipeline:

1. Build a problem corpus in customer language

2. Collect behavioral signals at scale

3. Sparse filter → dense retrieve → LLM interpret

4. Score on similarity, breadth, freshness, specificity

5. Hand-write outreach that references specific evidence

6. Lead with a work sample, not a meeting

It's a retrieval pipeline, a scoring function, and a copywriting template. None of it is a research paper. All of it is a product.

The deeper point: we stopped asking "who is our customer?" and started asking "who is already living the problem we solve?" The first question is a segmentation problem. The second is a recognition problem. And recognition, it turns out, is something you can engineer.

Dr. Eleanor Voss

AI Inspired