How to Find B2B Buyers Who Have the Problem Now

Published 2026-10-20 · Afield

An ICP is a description of who could buy. It is a filter, and a filter is a poor substitute for a signal. A company that matches your ideal customer profile perfectly may have solved the problem you address six months ago, may be mid-migration to a competitor, or may simply never have felt the pain badly enough to act. Meanwhile a company that only half-fits your profile is posting publicly, this week, about the exact thing your product handles.

The instinct when outbound feels weak is to tighten the ICP: add a revenue band, add a tech-stack requirement, add a seniority filter. That produces a smaller list of people who look more like your best customers and still says nothing about whether they have a live problem. The more useful move is to treat the ICP as a gate you pass through once, and then rank the survivors by evidence of current need.

This article sets out a working method for that second stage. It is written for an early-stage B2B SaaS founder doing their own outbound, and it assumes you are working with a modest list rather than a database. The method has five parts: screen for signals rather than attributes, verify each signal at its original source, actively look for counter-evidence, deduplicate before you write anything, and keep a human decision on every message. It is a process for producing a short list worth reading, not a claim that any particular list will convert.

Why profile fit and problem fit are different filters

Profile fit is static. It is built from attributes that change slowly or not at all: industry, headcount, business model, the tools a company runs. Problem fit is dynamic. It is built from what a company is doing right now — hiring for a role that implies a new process, publishing a job description that names a pain, asking a question in a public forum, shipping a change that creates a gap.

The two filters answer different questions. Profile fit answers “is this the kind of company we serve?” Problem fit answers “is something happening here that our product is relevant to?” A list built only on the first question is a list of plausible names. A list built on both is a list of plausible names with a reason attached to each one.

The practical consequence is that a signal list decays. A job posting is a live signal while the role is open and a historical curiosity once it is filled. A public complaint is a live signal while the thread is active. This is why signal-based outbound rewards a short cycle: the value of the list is tied to how recently you checked it, and a list assembled a month ago and worked through slowly is mostly a list of expired evidence.

Step one: screen for signals, not attributes

Start from the ICP you already have, because it is a cheap way to cut an enormous universe down to something you can actually read. Then, within that set, look for the handful of signal types that plausibly indicate the problem is live. Which signals are worth watching depends on what your product does, but the categories are fairly stable:

• Hiring signals. A company hiring for a role that only exists once a process has become painful — the first dedicated person for a function, a role that names a specific tool or workflow, a backfill that suggests churn in the function.
• Public questions and complaints. Someone from the company asking how to do something your product does, or describing the failure mode your product prevents, in a forum, community or social thread.
• Product and pricing changes. A changelog entry, a new pricing page, a repositioning that creates a gap your product sits in.
• Organizational change. A new leader in the function you serve, a stated expansion into a market that changes their requirements, or a public announcement that reshapes what the team needs next.
• Stack signals. Evidence that a company has adopted or abandoned a tool adjacent to yours, which changes what they need next.

Two disciplines make this stage useful. First, write down the signal types before you start looking, so that you are testing a hypothesis rather than collecting whatever happens to be findable. Second, record the signal type next to each company, because different signal types carry different weight and you will want to sort by that later.

This is also where a tool with connected context earns its place, and where it can mislead you if you let it. Afield’s Market Analyst researches competitor pages, public discussions and search questions, keeping links to the material behind each finding. The links are the important part. A finding without a source you can open is not a signal; it is a suggestion, and it belongs in a separate pile until you have checked it.

Step two: verify the signal at its original source

Every signal has an original location: the job posting on the company’s own careers page, the thread in the community where it was posted, the changelog entry on the product’s site. Verification means opening that location and confirming four things.

1. The entity. Is this actually the company you think it is? Similar names, subsidiaries and rebrands are common, and a signal attached to the wrong entity is worse than no signal.
2. The author. Is the person posting affiliated with the company in a relevant role, or is this an unrelated individual with the same employer name in their bio?
3. The date. When was this published? A thread from two years ago is not evidence of a current problem, however precisely it describes one.
4. The content. Does the source actually say what the summary claims? Paraphrase drift is the most common failure in signal research — a post about a related annoyance becomes, three steps later, a post about your exact use case.

Verification is unglamorous and it is where most of the value sits. A short list of ten verified signals is worth more than a long list of a hundred unverified ones, because the verified list is the only one you can write from without guessing.

A verification test that catches most errors: before you write anything, open the original source and read the sentence you are relying on out loud. Then read your own summary of it. If the summary adds a conclusion the sentence does not contain — that the company is unhappy, that they are evaluating options, that they are likely to buy — the summary is your inference, not their statement. Keep the two separate in your notes.

Step three: look for counter-evidence before you look for a reason to write

The natural failure mode of signal research is confirmation. Once you have found a promising signal, every subsequent search tends to confirm it, because you are searching for reasons the company needs you. The corrective is to spend a fixed amount of effort trying to disqualify the company before you spend any effort writing to them.

Counter-evidence takes a few predictable forms:

• They already solved it. A changelog entry, a published case study, or a job posting that has since been filled suggests the problem the signal pointed to has been addressed.
• They chose a different approach. A partnership, an internal build, or a stated preference for a category your product is not in.
• The signal is stale. The thread is closed, the role is filled, the announcement is old enough that the situation has moved on.
• The signal belongs to someone else. The person who posted is a customer, a prospect of theirs, or an unrelated commenter — not an employee with standing to act.
• The problem is real but not theirs to solve. The pain exists in a part of the business that does not own the decision, or at a scale where your product is not the relevant answer.

None of these disqualifications is a judgment about the company’s quality. They are reasons the timing is wrong, and timing is most of what a signal is for. A company excluded today because they just signed a competitor is a company worth revisiting when that contract comes up for renewal — which is a note for your list, not a message for their inbox.

This is the stage where a founder’s judgment matters more than any automation. A tool can surface a signal and keep its source. Deciding whether a signal means “act now,” “watch,” or “drop” requires knowing your market, your product’s real fit, and how much of your week you can afford to spend on a maybe.

Step four: deduplicate before you write a single word

Signal research produces duplicates at three levels, and each one needs a different fix.

Deduplication is not just tidiness. It protects you from the most damaging outbound error available to a small company: writing to the same person twice, with two different framings, in the same week. It also protects your own reading of the list. If three signals for one company are counted as three prospects, your list looks larger than it is and your prioritization is wrong.

Keep one record per company, with the signals attached to it rather than the company repeated against each signal. Record the source link, the date checked, and the decision — keep, watch, or drop — for each. That record is what you will write from, and it is also what you will review when you decide whether the method is working.

Step five: keep a human decision on every message

The last step is the one that determines whether any of the previous four were worth doing. A verified signal is a reason to prepare a message. It is not a reason to send one.

Before anything goes out, a person should be able to answer, in one sentence each: why this company, what the public evidence was, who the right recipient is, and what happens next if they reply. If any of those answers is missing, the message is not ready. This is the structure Afield’s own company research to outreach draft example uses: a campaign brief narrows the audience first, each company is kept, excluded or deferred with the reason recorded against it, and the resulting email draft is paired with the decision it depends on — including an explicit note that no recipient or email address has been selected.

That last detail is worth copying even if you never use the product. The draft and the recipient decision are separate steps, and collapsing them is how a well-researched message reaches the wrong person. Afield describes the automation level as something you control: research, organization and preparation can run automatically, while publishing, outreach and other consequential actions can sit behind approval gates. Whether or not you use a tool for this, the arrangement to aim for is the same — the machine prepares, the founder decides.

What this method does not do

It is worth being precise about the limits, because signal-based outbound is a category that invites overclaiming.

• A signal is not intent. A company hiring for a relevant role, or complaining about a relevant problem, is a company where the problem is plausibly live. It is not a company that has decided to buy anything, and treating a signal as intent is how founders talk themselves into bad sends. A funding round or a new hire is context, not a purchase order.
• Verification reduces error; it does not eliminate it. You can confirm that a source says what you think it says and still be wrong about what it means for your product.
• Deduplication is only as good as your record-keeping. A list maintained in three places will drift, and the drift will show up as a duplicate message.
• The human review is the quality ceiling. An approved message nobody read carefully is still a bad message, whatever produced it.
• Worked examples are demonstrations, not results. The published examples show how a brief, a decision and a draft fit together. They are not customer engagements and do not establish that any campaign produced a particular outcome.

A short list you can defend

The shift this method asks for is small and it changes the character of the work. Instead of asking “who fits my ICP?” — a question with a large, static answer — you ask “what is happening at this company that makes my product relevant this month?” That question produces a shorter list, and every name on it comes with a reason you could say out loud to the person you are writing to.

Start with one signal type and one bounded pass of checking. Screen within your existing ICP, verify each candidate at its original source, spend a fixed effort trying to disqualify it, merge duplicates into one record per company, and write nothing until a person has signed off on the reason, the recipient and the next step. If the resulting list is short, that is the method working as intended — a list of ten companies with live, verified, defensible reasons is a better use of a founder’s week than a list of two hundred that fit a profile.

Start with Afield — connect your website and one data source you already trust, and read the diagnosis before you write to anyone.

Frequently asked questions

What counts as a strong buying signal for an early-stage SaaS founder?

The strongest signals are specific, recent, attributable to a person with standing at the company, and tied to the problem your product actually solves. A job posting that names the workflow, or a public question from an employee about the exact task, usually beats a general funding announcement, which tells you a company has money but not what they are struggling with.

How do I verify a signal without spending all week on research?

Set a fixed budget per candidate and check four things: the entity, the author, the date, and whether the source says what your summary claims. If any of the four fails, drop the candidate rather than resolving it later. Verification is cheap when it is bounded and expensive when it becomes open-ended.

What should I do with a company I exclude because of counter-evidence?

Record it with the reason and a revisit date if the reason is temporary — a competitor contract, a role that has just been filled, a migration in progress. Excluding a company is a decision about timing, not a permanent judgment, and the note is what lets you pick it up again at the right moment.

Can Afield find these buyers for me automatically?

No. Afield can research companies and contacts, explain why a match fits, keep links to the material behind each finding, and help prepare a relevant first message. It does not remove the need for verification or the human decision about whether a signal is worth acting on. Afield’s published examples are demonstrations of the workflow, not records of campaign performance.

How many signals should one company have before I write to them?

One well-verified signal with a clear reason for contact is enough to prepare a draft. More signals make the reason stronger and the message more specific, but they do not change the underlying question, which is whether a person at that company has a live problem your product is relevant to.