Signal Stacking for Outbound Sales: Find Non-Obvious GTM Intelligence

Parking-lot imagery is the example that made signal stacking click for me. Investors and researchers have used satellite-derived car counts to estimate retail activity, but the photograph was never the real asset. The inference came from car count, lot capacity, timing, trend, and company context.

A peer-reviewed retail study applied car counts from more than 1.5 million satellite images to 33,848 store locations across 15 general-merchandise retailers. The researchers found that normalized parking traffic helped predict forward-looking retailer performance (Journal of Retailing record). The imagery was one imperfect observation. Context made it useful for a decision.

GTM teams face the same problem at a smaller scale. Funding, a new executive, a job post, a page visit, or a pricing change tells you that something happened. It rarely tells you what it means.

I run into the same trap whenever I build or review a signal workflow at Cheetah. The first request tends to be about data: find companies hiring AEs, changing their pricing, or talking about a competitor. I push the work back one step. What business situation are we trying to detect, and what would we do differently if we were right?

Brandon Charleson offers a good pattern: more account-executive openings plus no sales-development openings may indicate that closing capacity is growing faster than prospecting capacity. The missing hire changes the meaning of the visible hires. This is a practitioner interpretation, not proof, but it gives a rep a specific situation to investigate (Brandon Charleson).

Eric Nowoslawski's signal ranking was the nudge for this piece. He ranks company-specific triggers and new-in-role above generic events, while treating funding as more useful as a filter than a universal trigger (Sales Signals Rankings). Patrick Spychalski strips away some of the magic: a packaged signal often exposes a provider call plus change detection or deduplication through a usable interface (Patrick Spychalski). Charleson puts the missing piece between them. The message comes from what independent observations mean together.

Signal stacking for outbound sales combines independent observations, relevant context, and alternative explanations to infer a hidden business state worth investigating.

My practical rule is to test the equation before investing in the machinery. Clay is useful when I want to inspect the evidence in a table. Deepline fits when I'm already working in Claude or Codex and want an agent to orchestrate the same provider calls. Both are cockpits. Neither can decide what the evidence means for you.

In short

• Start with a hidden business state worth detecting, not a catalog of available alerts.
• Combine observations from sources that fail in different ways, including meaningful absences.
• Write the best alternative explanation before automating the story.
• Test 20 to 100 accounts in Clay UI, Clay CLI or MCP, or Deepline, then label each result useful, ambiguous, or wrong.
• Move to direct providers or a custom monitor only after the inference changes a real decision.

In this guide

• Why the edge lives in the inference
• What GTM can borrow from alternative data
• How to build a signal equation
• How to test it in Clay or Deepline
• When to use direct providers
• The five-day signal sprint

Everyone can buy the event. The edge is what it means.

Alerts are easy to buy. I care about the theory that tells a rep what an alert might imply, what else could explain it, and whether it deserves any action.

Eric ranks the raw ingredients

Nowoslawski evaluates signals through effectiveness, accessibility, and scalability. His job-description example shows why that matters: a title tells us less than the mission language inside the description. A role asked to grow enterprise logos reveals a priority that can shape an offer. Even then, he warns that a strong offer with no signals can beat a high-signal campaign with a weak offer. This is practitioner evidence, not a controlled study, but it is the right boundary for any buying-signal program.

Patrick removes the magic from the wrapper

Spychalski's provider-call plus deduplication model explains both the limit and the value of a wrapper. The wrapper doesn't invent the observation. It makes it cheaper to try a hypothesis, inspect rows, swap sources, and return only new events. In his reported experience, direct website intent combined with ICP fit is more defensible than an abstract funding event because the first observation adds timing and the second adds commercial relevance.

Brandon puts the inference in the middle

Charleson's other combinations make the distinction clearer. A new revenue leader plus inherited CRM language in job descriptions may suggest a stack-review window. A pricing-page change plus a spike in enterprise roles may suggest an upmarket motion. Neither conclusion is proven. The second observation matters because it changes how you interpret the first. It isn't merely another point in a score.

Jordan asks whether the result creates value

Jordan Crawford calls a programmatically identifiable problem situation a Pain-Qualified Segment. His Permissionless Value Proposition, or PVP, combines public data into a non-obvious, product-relevant insight that is useful before a buyer agrees to a call (Jordan Crawford). I use PVP as a downstream test here: does the inference create something useful, or only a clever opener?

Borrow the alternative-data habit

Signal stacking isn't unique to sales. Other fields already treat each source as a partial view of a hidden state.

• Retail investing: Parking-lot car counts plus lot capacity, time trend, and company fundamentals can form a directional estimate of retail activity. The peer-reviewed study above supports the aggregate method, not a claim that one image predicts one company's earnings.
• Insurance: Nearmap documents peril scores that combine imagery-detected roof and vegetation features with geographic, historical, claims, and damage data. The output is a property-level vulnerability estimate, not simply postcode risk (Nearmap Perils).
• Logistics: A Spire customer case describes fusing satellite AIS, port geofences, and EDI messages to improve vessel-arrival completeness and reduce latency. Each feed covers gaps in the others (Spire case study).
• OSINT: Bellingcat geolocated a social image by cross-checking neighborhood context, satellite geometry, and map photos from nearby businesses. The sources corroborated one another instead of repeating the same claim (Bellingcat).

The part I borrow from these fields is source independence. Two vendors reselling the same job feed don't create two pieces of evidence.

Consider a prototype hypothesis for venture sourcing. GitHub stars may be bought or inflated. Contributor growth, release cadence, hiring mix, and evidence of live product adoption fail in different ways. Joined together, they can prioritize a startup for investigation. They still don't prove momentum, and they may favor visible founders. The result is a queue for human judgment, not a verdict.

Build signal equations, not a signal catalog

A useful equation begins with the hidden business state. Monitor job posts is a data task. Detect companies expanding closing capacity without expanding prospecting capacity is a decision problem.

1. Name the hidden state

The state must change whom you contact, what you offer, when you act, or whether you do nothing. If discovering it changes none of those decisions, it isn't worth monitoring.

2. Choose independent observations

Write the hypothesis in plain language:

Observation A + observation B + relevant context = hidden-state hypothesis

Then add the line that keeps a neat story from becoming fake certainty:

Best alternative explanation = what could make the story wrong

3. Use positive, negative, and absent evidence

A new role is positive evidence. No complementary SDR hiring may be meaningful absent evidence. A hiring freeze, a contradictory executive post, or a stale page can be negative evidence. Absence only matters when your coverage and time window are good enough that the event should have appeared.

4. Define the smallest useful decision

The output doesn't have to be send email. It can be research, manual review, nurture, route to an account owner, build a useful analysis, or do nothing.

Six examples show how the pattern works:

• More AEs plus no SDRs: Charleson's practitioner play suggests prospecting capacity may lag closing capacity. Check hiring history and the company's demand model before acting.
• Several job descriptions plus repeated initiative language: Lorcan O'Rourke's practitioner workflow groups roles by account and month to detect a coordinated program before an announcement. Duplicate and evergreen jobs are the obvious failure modes (Lorcan O'Rourke).
• SOC 2 announcement plus compliance-site changes plus CISO hiring: Clay documents this as a Vanta monitoring workflow. It suggests compliance is becoming an operational and executive priority, but the page publishes no precision or revenue denominator (Clay Signals).
• Lease expiry plus social engagement: Clay documents a Density workflow that joins a facilities decision window with warmer relationship context. The next step is to investigate the likely move, not declare intent.
• Competitor price increase plus mapped installed base: Patrick Spychalski reports a Mark Colgan practitioner play for finding a temporary migration window. Customer maps are incomplete, and price pain may still be tolerable (Patrick Spychalski's field note).
• Public tree inventory plus species, diameter, urgency, and arborist proximity: Crawford demonstrated a roughly 680,000-tree source universe, a 12-tree cluster within 0.8 mile, and an estimated $9,600 opportunity. Treat those figures as his demonstration, not an audited campaign or current quotation (primary post and transcript).

These aren't recipes to copy. Each example shows how another observation narrows the interpretation of the first.

Prototype in the cockpit you already use

Clay UI, Clay CLI or MCP, and Deepline are equal starting points. I choose between them by the way I want to inspect the work, not by a fictional maturity ladder.

Clay UI suits visual operators. If I need to scan 50 accounts row by row, I usually want a table. I can keep the base list, two observations, dates, raw links, and a human verdict on one screen. Clay's native Signals and its provider marketplace make that sort of spike quick to assemble.

Clay CLI or MCP suits Claude and Codex operators who want the same work through an agent-facing interface. Clay's Agent Plugin bundles API, CLI, MCP, and skills for coding agents. The agent can compose functions and inspect results, but it still needs a clear hypothesis and review rule (Clay Agent Plugin).

Deepline suits agent-native provider orchestration. Its official surfaces support Claude Code and Codex through CLI and MCP, and its quickstart recommends piloting a small number of rows before scaling (Deepline surfaces, Deepline quickstart). I use the term "cockpit" deliberately. Deepline makes provider research repeatable, but it isn't a native signal-stacking product and doesn't supply the strategy.

The connection model matters once you move beyond the demo. In Clay, native Signals and Clay-managed functions sit beside marketplace integrations. Sumble is a managed integration, while CrustData and Signaliz have documented bring-your-own-key paths. Clay's HTTP action covers providers outside the catalog. A marketplace logo doesn't automatically mean Clay manages the data, credentials, or billing for every action.

In Deepline, a native provider means the provider is exposed through the CLI or MCP workflow. It doesn't mean Deepline owns the underlying data. The current provider directory includes TheirStack, CrustData, PredictLeads, BuiltWith, Adyntel, DataForSEO, Exa, Parallel, ScrapeCreators, and Apify. Some providers still need their own account or key. The direct path is different again: you call the provider API or run the collector yourself and take responsibility for history, retries, monitoring, and provenance.

For the AE versus SDR hypothesis, a quick Clay version can use TheirStack or PredictLeads, with CrustData connected for team context. The matched Deepline version can use its built-in TheirStack, CrustData, or PredictLeads adapters. If the equation survives, go direct to the chosen jobs endpoint and keep historical snapshots so the ratio means the same thing every week.

At Cheetah, my rule is wrapper first, direct source second, and custom logic only when the question has stopped moving. That sequence keeps the early test cheap without pretending the wrapper is where the eventual data advantage lives.

The afternoon spike stays the same in all three surfaces:

1. Choose one hidden state and write three competing equations.
2. Pull 20 to 100 ICP accounts.
3. Collect two observations, dates, and raw links.
4. Label each result useful, ambiguous, or wrong.
5. Ask whether a knowledgeable rep would change behavior because of the inference.

Suppose a fintech adds KYC language to several job descriptions while changing product pages toward enterprise controls. Test that combination in the cockpit you already use. Before calling it an enterprise motion, check whether the jobs are routine compliance hiring and whether the page change is only a copy refresh. That discipline turns intent signals into pipeline without turning every coincidence into outreach.

Providers are the sensor rack behind the wrapper

The cockpit isn't the sensor. Once a spike has a clear equation, I match each observation to the narrowest source that can answer it and make the connection model explicit.

• Jobs and headcount: In Clay, TheirStack and PredictLeads are quick documented integrations; CrustData is a connected-key option. Deepline exposes native TheirStack, CrustData, and PredictLeads workflows. TheirStack is the cleanest first stop for role, description, technology, date, and location filters. After validation, poll the selected endpoint directly, retain each full description, and compare historical snapshots. Job text shows intent to hire, not proof that a project has been purchased (TheirStack data, CrustData Jobs).
• Technology adoption or replacement: Clay can use BuiltWith, Sumble, or hiring-derived technology evidence from PredictLeads. Deepline can pair BuiltWith and TheirStack with PredictLeads, while Sumble uses a connected key. A direct monitor becomes useful when additions and removals matter over time. A public tag still doesn't describe the complete internal stack (BuiltWith API).
• Social engagement and public posts: Trigify is a Clay path for topic engagement filtered by role, company, industry, and recency. Deepline can use ScrapeCreators or CrustData for public posts and context. Apify covers the long tail in either cockpit when a maintained Actor fits. Bright Data is another direct collection path for public professional data. A like alone is weak. A buyer describing a problem while the account undergoes a related change is more interesting (Apify Actors, Bright Data collection options).
• Company events and relationships: Clay's native news and fundraising signals can be joined with Owler or PredictLeads. Deepline can use PredictLeads for structured events and Exa or Parallel for open-web retrieval. Exa Websets and Parallel become direct monitoring candidates when the event class and verification criteria stop changing. Generic news volume isn't an advantage. The useful part is the decision the event creates for that account.
• Ads, search, and demand: Clay lists Adbeat for channels, creative, publishers, and estimated spend, while Similarweb can add estimated traffic and engagement. Deepline exposes Adyntel for paid-media intelligence and DataForSEO for search, rankings, content, backlinks, and estimated traffic. When this equation works, collect the creative and landing pages on a schedule and compare changes. Competitive spend and traffic figures are estimates, not first-party analytics (Similarweb visits).
• Maps, reviews, and niche sources: Clay lists Google Maps and Apify, and its HTTP action can call a places API. Deepline can run an appropriate Apify maps or review Actor. After the geography and cadence are proven, use Google Places, Bright Data, or another licensed local-data provider directly. RapidAPI can help you test a narrow API, but it is a marketplace rather than one uniform source (Google Places, Places policies, RapidAPI consumer guide).

Satellite and aerial imagery sit further outside the normal GTM catalog. A controlled Clay experiment can call a direct API through HTTP. An agent can orchestrate the same call from a Deepline workflow. If imagery becomes part of a proven decision process, use Sentinel Hub, Nearmap, or another licensed source directly and build the comparison outside the wrapper (Sentinel Hub API).

Maps photos, reviews, social posts, and imagery remain subject to terms, privacy, attribution, freshness, and licensing constraints. Technical access isn't permission. Good GTM engineering preserves provenance and a no-action path.

When a hypothesis works, deepen one layer

Stay in the wrapper while the hypothesis changes after every review, the sample is small, or humans still disagree about what the evidence means. Go direct when the same equation keeps producing useful verdicts and one source is too stale, shallow, costly, or opaque.

My default is to deepen one layer, not rebuild the whole stack.

1. Upmarket motion: Test pricing-page change plus enterprise hiring in Clay or Deepline. If the equation survives review, deepen with a focused page monitor and job data from TheirStack or CrustData.
2. Influencer-created demand: Test creator promotion plus estimated traffic or branded-search movement. If it works, deepen with ScrapeCreators or Bright Data, then compare against first-party conversion timing. Without exposure matching or a control, the result remains correlational.
3. Local expansion: Test review growth plus recent customer photos and category demand. If the pattern is useful, move to a licensed Maps or local-data provider and add human verification.

The custom build should cover the one proven sensor or inference that creates an edge. It shouldn't become a pre-emptive internal signal platform.

Make the output useful, not creepy

A stack answers why investigate this account now? A useful output answers why should the buyer care?

Crawford's construction example combines a transport permit with nearby idle fleet capacity to produce a real lead for an equipment-rental operator. His tree demonstration packages public inventory, regulation, and provider proximity into a routable map. In both cases, the value is the opportunity itself, not a sentence announcing that the sender tracked a permit or tree.

Compare the difference:

Weak: I saw you added KYC to three job descriptions.

Useful: I mapped the controls those roles appear to own and found two places where the new enterprise motion may create duplicate review work. Here is the one-page map.

The second message still needs honest caveats. It doesn't claim the jobs prove a strategy. It turns the evidence into a useful artifact and lets the recipient inspect the reasoning.

Nowoslawski's offer warning matters here. Signals cannot rescue a weak proposition. Crawford has also published a failed Segment campaign reflection: technically impressive research attracted questions about the analysis without producing the buyer behavior he needed (failed-campaign reflection). The evidence should shape the offer, but the message should deliver value rather than narrate surveillance.

Run a five-day creative signal sprint

For a first pass at Cheetah, I use a small human-reviewed sprint rather than a production system. The labels stay intentionally boring. Useful, ambiguous, and wrong tell me more at this stage than a score with two decimal places.

Day 1: Write three hypotheses

Start from a repeated customer pain or closed-won pattern. Name the hidden state, write three equations that might reveal it, and add the best alternative explanation to each.

Day 2: Build the smallest spike

Choose Clay UI, Clay CLI or MCP, or Deepline based on working style. Pull 20 to 100 ICP accounts. Keep the raw evidence visible and resist the urge to create a complex score.

Day 3: Review by hand

Label each result useful, ambiguous, or wrong. Record the failure: stale source, duplicated evidence, bad entity match, weak proxy, or irrelevant problem. Kill an equation that needs a heroic explanation for most accounts.

Day 4: Turn the best inference into value

Create a small analysis, benchmark, map, checklist, or opportunity the recipient could use without buying. Send it manually to a small set or route it to the account owner. Keep the offer and desired buyer behavior explicit, then make sure positive outbound replies do not get lost.

Day 5: Decide what deserves depth

Evaluate human-reviewed precision, whether the inference changed an action, freshness, recurrence, permissionless value, source cost, and maintenance burden. The decision is kill, revise, keep in the wrapper, or deepen one source. One positive reply isn't evidence for a permanent system.

Where signal stacking breaks

Two providers can report the same upstream event. That is duplication, not corroboration. Jobs, estimated traffic, headcount, reviews, and technology fields can be indexed, modeled, stale, or wrong. Preserve dates and raw links.

Correlation isn't causation. Influencer activity plus traffic growth still needs a baseline or control. An old photo, evergreen job, or copied description can create a beautiful false story. Physical-world data can also be too expensive, stale, or low-resolution for a casual workflow.

Public availability doesn't remove terms, privacy, attribution, or data-protection obligations. I use one blunt test here: if a stack produces a persuasive story for every account, it isn't intelligent. It is incapable of saying no. A precise signal also can't fix an offer that doesn't solve the inferred problem.

The message lives in the inference

The satellite image became useful only after context turned it into a testable estimate. Outbound signals work the same way.

Start with a hidden state. Combine independent observations. Write the alternative explanation. Spike-test a small account set. Ask a human for a verdict. Turn the surviving inference into something useful, then deepen only the source that creates an advantage.

Write three equations for one painful customer situation this week. If you want to turn the best one into an operating workflow, the GTM Brain Sprint is the focused next step, with the signal-to-pipeline use case showing where it can lead.

One signal tells you something happened. A good inference tells you what might matter next.

About the author

Fedor Kovalev writes GTM Frontier and builds practical GTM systems at Cheetah.