Find the sales signals for any product or service

---
name: find-theirstack-sales-signals
description: Find the TheirStack outbound/sales signals for any product or service offering, not just SaaS. Reads the offering's OWN website to understand the problems it solves, then maps them to TheirStack signals (jobs, technographics, buying intent) a GTM team can run for outbound. Runs end-to-end (no confirmation step) and returns a self-contained report — company summary, the company's products & services, ICP options, competitors, a firmographic overlay, and signals grouped by the company's product/service — each signal a bullet that starts with a live company count linking to a ready-made, pre-filtered search URL, under the offering it is used to pitch. It starts from the workspace brand book (products, problems, ICPs as company search filters, customers, competitors) when that brand book describes the offering, and hands the website research to the `research-company-brand-book` skill in a subagent when it is empty, incomplete or about another company — which also saves it when the offering is the workspace's own. Use when the user says "find sales signals", "outbound signals for <product>", "what TheirStack signals should <product> use", "which signals can this offering use", or pastes a product or service URL for signal discovery.
user-invocable: true
argument-hint: <product-url> [extra URLs or free-text context]
---

# Find TheirStack Sales Signals

Given the website of any product or service offering — not just SaaS — produce the TheirStack signals its GTM team should use for outbound: read the offering → derive the tasks, roles, competitors and integrations behind each problem → map them to TheirStack's three data types.

## Input

A **product or service URL** (the offering you want signals for). The input may also include **extra URLs** (e.g. a specific feature page, a comparison page, a docs site) and/or **free-text context** (the seller's notes on their ICP, target market, competitors, the offering to push). Treat everything passed in as context: read every URL given, and fold any free-text guidance into the research — it overrides your own inference where the two disagree. If no URL is given at all, ask for one and stop.

**Run end-to-end — do NOT stop to confirm the research.** There is no human checkpoint: research the product, ground the signals, and produce the full report in one pass. State your firmographic inference inside the report (in the overlay header) so the reader can adjust later, but never pause to ask them to validate the input first.

## Pre-check — verify the TheirStack tools and the companion skill (run FIRST, before anything else)

This skill cannot run without the **TheirStack MCP** connected. Before reading any website or running any step:

1. Check whether the TheirStack tools are available in this session — look for `search_companies`, `search_jobs`, `get_catalog_keywords` and the URL builder `generate_app_url` (some clients show them with a prefix, e.g. `theirstack__search_companies`).
2. **If they are present**, continue to the Steps.
3. **If they are missing**, STOP and point the user to the setup guide, then wait — do not attempt the rest of the skill:

    > The TheirStack MCP isn't connected, and this skill needs it to ground signals in real, queryable filters. Follow the setup guide to install it, then re-run: https://theirstack.com/en/docs/mcp

This skill also grounds its **buying-intent / pain** signals (family C) by reusing the iteration loop of the **`job-description-keyword-research`** skill — it reads real job postings and mines the exact phrasings companies use, instead of guessing pain keywords once. That skill is a **hard requirement**:

4. Confirm the `job-description-keyword-research` skill is available in this session.
5. **If it is present**, continue to the Steps.
6. **If it is missing**, STOP and tell the user to install it, then wait — do **not** fall back to catalog-only pains:

    > This skill grounds its buying-intent signals with the `job-description-keyword-research` skill, which isn't installed. It ships with this one — install it from https://theirstack.com/en/docs/mcp/skills/job-description-keyword-research, then re-run.

7. Confirm the `research-company-brand-book` skill is available too. It does the website research of Step 1 (and fills the workspace brand book). **If it is missing**, STOP and tell the user to install it:

    > This skill hands its website research to the `research-company-brand-book` skill, which isn't installed. It ships with this one — install it from https://theirstack.com/en/docs/mcp/skills/research-company-brand-book, then re-run.

8. **Check for the brand book tool** — `get_brand_book`. It is **optional**: when it is missing (some clients list read tools only), skip Step 0 and always run the research of Step 1.

## Hard rules

-   **Write nothing.** This skill never creates saved searches, lists or anything else. The only write in a run is the brand book, and `research-company-brand-book` makes it, not this skill.
-   **Research the product from its WEBSITE only**, through the brand book or `research-company-brand-book` (Steps 0–1). Do **not** use `search_companies`/`search_jobs` to research the product itself.
-   **Trust the connection's own auth.** The TheirStack MCP authenticates itself. Always call the tool directly; if a call fails with an authentication error, tell the user to reconnect TheirStack and stop.
-   **The catalog is for grounding, not prospect research.** Use `get_catalog_keywords` (with `keyword_type: "technology"` for technologies) only to turn human terms ("Pleo", "expense reporting") into real, queryable slugs.
-   **It spends the user's credits.** Every count and every sample read is billed to their TheirStack workspace. Say so in one line before you start, and report the rough total at the end.
-   **Infer firmographics, don't ask for them.** Derive the firmographic overlay (countries, industries, employee band) from the site (and any context passed in) and apply it to every signal so the counts are addressable market, not whole-database noise. State your inference inside the report's overlay header so the reader can adjust later — but do **not** pause to confirm it.
-   **Must-use vs nice-to-have drives scoring.** For every technology, decide whether the product _can't_ serve a company without it (blocking) or it merely correlates with fit. Must-use signals outrank nice-to-have ones.
-   **Pains come from the companion loop, not a one-shot guess.** Discover and ground every buying-intent / pain signal by running the `job-description-keyword-research` procedure (its Steps 2–3) **to saturation**, reusing the product↔pain map from Step 1 here (do not re-fetch the site). The output is grounded `job_description_pattern_or` groups, each validated against real postings and tied to one product feature. A catalog keyword slug (`company_keyword_slug_or`) is a coarse fallback only for a pain with no usable job-description phrasing.
-   **Stack pains with tech via job-search, not company-keyword OR.** To combine a pain with a must-use technology, use `search_jobs` with `company_technology_slug_or` AND `job_description_pattern_or` — these AND across dimensions. Do **not** combine `company_keyword_slug_or` + `company_technology_slug_or` in `search_companies` expecting an intersection: those **union**, which inflates the count above either filter alone.
-   **Ground or drop.** A signal that isn't grounded in real, queryable data isn't actionable — drop it and list it separately as "request missing". Technographic signals ground to a real `technology_slug`; pain / buying-intent signals ground to an iterated `job_description_pattern_or` group (see the rule above), not a single catalog-keyword guess.
-   **Don't trim the catalog.** Output all signal families; mark each high/med/low.

**Run the whole thing in one pass — there is no human checkpoint.** Research the product, ground the signals, and write the full report without stopping to ask the user to validate anything.

## Step 0 — Start from the workspace brand book

The brand book is what the workspace has already recorded about **its own** company: the company profile, its products & services with their value propositions, the problems they solve (with the job titles that own them), its ideal customer profiles (each one a set of company search filters), its customers (as cited in its case studies) and its competitors (with their technology slugs). It is written by `research-company-brand-book` and may have been edited by a person.

1. Call `get_brand_book`. It returns the brand book plus `filter_problems` (ideal customer profiles whose stored filters company search no longer accepts).
2. **It applies to this run** when its `company.website` has the same domain as the URL you were given.
3. **It is filled** when it applies and has a company overview, at least one product, one problem and one ideal customer profile, and `filter_problems` is empty.

## Step 1 — Get the product research

You need, for the offering: what it sells and its value proposition, its products & services, the problems each one solves with the tasks they remove and the job titles that own them, its ICP options, its customers, its competitors and integrations (each with its technology slug and tagged **must-use (blocking)** or **nice-to-have**), and the **firmographic overlay** (target countries, industries to include or exclude, employee band) — inferred, never asked.

-   **When the brand book is filled**, it is your research: take products, problems, ICPs, customers and competitors from it. Anything a person wrote there overrides your own inference, exactly like free-text context. Derive the firmographic overlay from the ICP filters, treat the technologies in those filters as must-use, and read the site's integrations page for the nice-to-have ones. Do not hand the research off.
-   **Otherwise** (the brand book is empty, incomplete, describes another company, or `get_brand_book` isn't available), hand the research to the `research-company-brand-book` skill. Run it in a **subagent** (a separate agent with its own context) when your client can start one, otherwise follow it inline. Pass it the URL, every extra URL and the free-text context you were given, and whether the user presented the offering as their own. Wait for its result: the brand book, the integrations, the firmographic overlay and its closing notes. It saves the brand book itself when the offering is the workspace's own, so the next run takes the first path.

Fold any free-text context passed to you into the research; it overrides the brand book and the subagent's inference where they disagree.

## Step 2 — Map to TheirStack signals

3. **Load the signal catalog.** Read the **Sales signals library** — `https://theirstack.com/en/docs/data/sales-signals.md` — and use it as your checklist. Your **signal sources are the three it defines** (A Technographics, B Jobs and hiring, C Buying intent topics) — every signal you output comes from one of them. **Firmographic and temporal are overlays you apply on top of a signal, not sources**: TheirStack is not a firmographics source, so infer the firmographic overlay only to narrow the counts (never pitch industry/size as a signal), and use temporal filters (first-seen, recency, `min_jobs`, surges — a real TheirStack strength) to prioritize by timing. "Trigger plays" are ready-made combinations. This is the single source of truth for the signal list and the exact filter behind each; do not invent signals outside it.

4. **Ground technographics in the TheirStack catalog** — competitors and integrations usually arrive with their technology slug from Step 1; for any that doesn't, call `get_catalog_keywords` with `q` set to its name and `keyword_type: "technology"` to resolve it. Confirm each slug really exists (and is the right one) by checking it returns a non-zero count in the count-mode search in step 6. Drop unmatched terms (list them).

    **Ground pains with the `job-description-keyword-research` loop (family C).** Do **not** one-shot pains to catalog keyword slugs. Instead run that skill's procedure (its Steps 2–3) **to saturation**, reusing the product↔pain map from Step 1 here — no re-fetch of the site: for each pain, brainstorm a wide set of real-world phrasings (verb/noun forms, regional spellings, tool-agnostic descriptions, the user's other target languages), size each with a count request (`include_total_results: true`, `limit: 1`, ~1 credit each), **read small samples of real postings** (5–10 jobs, ~1 credit/job) to mine the phrasings companies actually use and exclude false positives via `job_description_pattern_not`, then re-run until a round adds nothing new (~3–4 rounds). The output is a set of grounded `job_description_pattern_or` groups, each tied to one product feature — these ARE your family-C signals. A catalog keyword slug is a coarse fallback only for a pain with no usable job-description phrasing.

5. **Apply the firmographic overlay, fill every signal, and score by fit.** Apply the inferred firmographic overlay — countries, industries, employee band — to **every** signal so the counts are addressable market, not whole-database noise. Fill every signal in the library with this product's confirmed values (competitors, integrations, roles, keywords). Then **score each signal by fit, not raw count**: a signal built on a **must-use** technology (a hard prerequisite) outranks one built on a **nice-to-have**; an explicit buying-intent/pain signal outranks a passive technographic one; and a stacked signal (must-use tech + pain + firmographics) outranks any single filter. This fit score — not the company count — decides the ordering of signals **within each product subsection** (highest-intent first), and which ones are the secondary / marginal / ceiling ones that go last. Keep this scoring internal — it drives the ordering only; do **not** print it as an inline fit tag on the bullets. Don't trim families.

6. **Size every signal (one record per count).** For each grounded signal, get the company count with `search_companies` / `search_jobs` as a [count](https://theirstack.com/en/docs/api-reference/features/count-results) — `include_total_results: true`, `limit: 1` — and read `metadata.total_companies`. Size each signal **with the firmographic overlay applied**, so the headline is the addressable number under the ICP; only when you deliberately show a whole-database **ceiling** (e.g. all users of a competitor before geo/size) do you drop the overlay, and you must label that number a ceiling. Hiring counts are a flow within the posted-date window — say so. Always also build and size one combined **core list** — the correct cross is a `search_jobs` query with `company_technology_slug_or` (must-use entry tech) AND `job_description_pattern_or` (a converged pain group from step 4) AND geo + size, since these AND across dimensions. Do **not** build it as `company_keyword_slug_or` + `company_technology_slug_or` in `search_companies` — those union and inflate the count above either filter alone.

7. **Generate one deep-link search URL per signal** so each count opens the live, pre-filtered search in the app — **do NOT create saved searches**. Call `generate_app_url` with `type: "company_search"` (or `"job_search"` for hiring signals) and `filters` set to the same filters you sized with — **minus the count-only flags** (`include_total_results`, `limit`), which don't belong in a user-facing search. It returns a URL of the form `https://app.theirstack.com/search/companies/new?query=<encoded>` (or `/search/jobs/new?…`) that opens the search and runs it automatically for whoever opens it. Put that URL on the company count.

    If `generate_app_url` isn't available, show the counts without links and say so in the closing notes.

## Output

Write the output **in the user's language** (match the conversation; re-run per market since pain phrasing and role titles don't translate 1:1). It is **professional tone, no emojis**. The signals are **grouped by the product/service of the analyzed company that each one is used to pitch** — there is **one subsection per offering**, not a global `High intent` / `Other` split. Inside each product, write the signals as a **bullet list**, ordered by fit (highest-intent first).

The report has this exact section order: **company summary → Products & services → ICP → Competitors → Firmographic overlay → Signals by product/service → closing notes.** Build it as a self-contained report.

**Company summary** — open with a short heading carrying the company name, then a one-line **What they sell** and a one-line **Value proposition** (the core promise to their customer, in their own framing). Draw both from Step 1; keep them tight, one sentence each.

**Products & services** — the offerings of **the analyzed company itself** (what it sells to its customers), drawn from Step 1 — **never** TheirStack's products/features. Use a short heading and one entry per offering: a bold name plus a one-line description in the company's own framing.

**ICP** — the distinct ICP segments/options the company could target, one short paragraph each (e.g. by stack, by vertical, by buying trigger). Make them genuinely different options, not one ICP reworded; tie each to the signals below where natural.

**Competitors** — examples of other businesses in the same space as the analyzed company (its competitors), one short line each. Prefer competitors named on the site; otherwise give well-known comparable businesses and mark them illustrative ("confirm with the seller"). Note that, once confirmed, these become a competitor-displacement signal.

Then add the **structured firmographic-overlay header** — a short heading (e.g. `Firmographic overlay (applied to every count)`) followed by **bullet points**, one per dimension, so the reader knows the ICP behind the numbers. Write it for the GTM reader, **not** as TheirStack query syntax: describe each dimension in plain business language and **never expose filter/parameter names** (no `company_country_code_or`, `industry_id`, `min_employee_count`, etc.). Use these bullets, in this order, dropping any that don't apply:

> ### Firmographic overlay (applied to every count)
>
> -   **Countries (HQ):** `<list>`
> -   **Size:** `<min–max>` employees
> -   **ICP / vertical:** `<one line>` — identified by the stack they run (`<key tools>`) and their hiring activity
> -   **Why no industry filter:** `<one line>` — only include this bullet if you deliberately skipped an industry filter (e.g. LinkedIn's industry tag doesn't expand to sub-industries and dropped most real matches); cite the before/after count
> -   **How to read the counts:** company counts are addressable market under this overlay; hiring counts are a flow within the stated window (e.g. 30/90 days), not a cumulative total

**Signals by product/service** — this is the core of the report. Create **one subsection per offering** from the Products & services list, in the same order, headed by the offering name plus a short italic descriptor of what it is (e.g. `## Freshservice / InvGate Service Management — *ITSM / Service Desk*`). Under each, list the signals used to pitch **that** offering as a **bullet list**, ordered by fit (the combined core list and explicit buying-intent signals first, then must-use displacement, then nice-to-have/secondary, then marginal/ceiling).

Each signal is **one bullet** that **starts with the company count, and that count is the only hyperlink in the bullet**, followed directly by a **verbose, clear explanation** — what the filter finds, why it matters for _this_ offering, the pitch angle, and any nuance or flow caveat (2–4 sentences, not one terse line). Do **not** prepend an italic fit tag (e.g. `— _high intent · displacement_.`); go straight from the count into the explanation:

> -   **[383 companies already running Zendesk](https://app.theirstack.com/workspace/213/search/companies/new?query=eyJxdWVyeSI6…)** — companies of 50+ employees already using Zendesk for customer support. It is the largest CX displacement pool and the pitch is clear: move to a cheaper Freshworks stack with chat and telephony already integrated. Direct fit, shorter cycle than enterprise ITSM.

Output rules:

-   **Group by offering, not by tier.** Every signal lives under the product it is used to pitch (the subsection heading is that offering — one of the analyzed company's real offerings, **never** a TheirStack product). Do **not** add global `High intent signals` / `Other signals` headings, and do **not** use an inline `Recommended product:` — the heading already names the product.
-   Lead each bullet with the linked count; put the link **only** on the count, nowhere else. Go straight from the count into the explanation — do **not** add an italic fit tag (no `_high intent · displacement_`, `_secondary_`, `_marginal / ceiling_`, etc.). Fit still drives the ordering of bullets; it is just not labelled inline.
-   Make each description **verbose and clear** (2–4 sentences): what the signal finds, why it matters for that specific offering, the angle to pitch, and any caveat — including whether the count is addressable market or a hiring **flow** within the window.
-   Order signals **within each product by fit**, not raw count: the combined core list (must-use tech + pain + firmographics) and explicit buying-intent/hiring signals come first; nice-to-have technographics and whole-database ceilings come last. The ordering conveys fit — do **not** label it with an inline tag.
-   If one signal genuinely feeds two offerings, place the full bullet under its primary offering and add a short note there that it also feeds the other — don't duplicate the bullet.
-   Put offerings that have **no grounded signal** last, grouped together under one line (e.g. `## Ringover · Applivery — no grounded signal (request missing)`), with a bullet explaining why (no catalog match / pain too noisy) and the request-missing action.
-   Note any nuance inline (e.g. "ServiceNow is the biggest pool but a heavy enterprise rip-and-replace; treat as long-cycle").

End with: a one-line note that each link opens the live, pre-filtered search in the app (no saved searches are created), a one-line note saying whether the workspace brand book was used as is, or filled or updated by `research-company-brand-book` (or its offer to save it), then a one-line note of any signals dropped for lack of grounding (a technographic with no catalog match — "request these as new keywords/technologies" — or a pain whose sampled postings were mostly irrelevant), and a rough **credit cost** for the run (the pain loop's sample reads cost ~1 credit/job; sizing costs credits too). If the user wants any of these monitored over time, offer to turn one into a saved search with email alerts — but only on request.

## Notes

-   **Firmographics are inferred, not asked.** Derive countries, industries and employee band from the site (and any context passed in), state them in the report's overlay header, and filter every signal count to that overlay. Don't pause to confirm — the user can adjust after seeing the report.
-   **Lead scoring follows must-use.** A blocking technology (the product can't work without it) scores a prospect higher than a nice-to-have; stacked signals (must-use tech + pain + firmographics) score highest of all.
-   Combine signals for precision: _competitor + recently funded_, _target role + pain keyword_. Single-signal lists are broader and noisier.
-   **Pains are grounded, not guessed.** Family C reuses the `job-description-keyword-research` loop — iterate against real postings until phrasings saturate. Reading postings to mine phrasings costs ~1 credit/job, so keep samples small (5–10) and report the rough credit spend; sizing costs credits too (see below).
-   **AND vs OR.** Stack pain + tech via `search_jobs` (`company_technology_slug_or` AND `job_description_pattern_or`). In `search_companies`, `company_keyword_slug_or` and `company_technology_slug_or` **union**, not intersect — never build the core list that way.
-   Sizing is not free: each count (`include_total_results` + `limit: 1`) is charged for the one record it returns (3 API credits per company search, 1 per job search, nothing when there are no matches). Tell the user roughly how many credits the run used, and only spend more if they explicitly ask to pull the actual companies, or for the pain-loop sample reads above.
-   Re-run per market — pain phrasing and role titles don't translate 1:1 (FR / EN / ES passes).
-   **The brand book compounds.** A later run on the same company starts from the saved products, problems, ICPs, customers and competitors (Step 0) instead of re-researching the site, and a person's edits to it steer every run after. To refresh it after the site changes, run `research-company-brand-book` directly.