Market Signals for B2B SaaS Founders

A market signal is an observable change that makes a company more likely to be worth researching now. It is not evidence that the company needs your product, has budget, or will buy. This distinction matters most with a small customer base: you do not yet have enough conversion data to assume that every seemingly relevant account behaves like a buyer. Use signals to answer a narrower question: “Which account should receive the next 20 minutes of research?” A useful signal changes either the urgency of a problem, the ability to act on it, or the likelihood that a relevant owner is identifiable. If it changes none of those things, it may be interesting news but should not move an account up your queue.

• Urgency signals suggest a problem may have become more expensive or visible.
• Capacity signals suggest the company may have people, budget, or systems to address a problem.
• Ownership signals reveal who may be accountable for the change.
• Access signals indicate a practical route to learn more, such as a new leader publishing a strategy or a team advertising related roles.

When you have only a few customers, avoid pretending you have a complete ideal customer profile. Instead, write a provisional hypothesis that can be tested. Define the job your product helps a team do, the operating conditions that make that job difficult, and the role most likely to feel the difficulty. Keep it specific enough to guide research but flexible enough to revise. For example, a founder selling software that standardizes security questionnaire responses might hypothesize: “Mid-market B2B software companies with growing enterprise sales teams need a repeatable way to coordinate security-review answers; likely owners are security, revenue operations, or sales engineering leaders.” This does not mean every company hiring an account executive is a prospect. It tells you which changes are plausibly connected to the job you solve.

• Write one sentence for the job: “We help [role] accomplish [outcome] without [cost or friction].”
• List two to four conditions that make the job more pressing.
• Name the likely economic buyer, daily user, and internal champion separately.
• Mark each assumption as observed from a customer, inferred from a conversation, or untested.

Prefer signals that sit near the workflow you affect. A generic funding announcement can mean many things: expansion, hiring, runway extension, or a change in priorities. A job post for a security compliance manager, a public launch of an enterprise plan, or documentation about a procurement process is closer to the work in the earlier example. Closer signals are usually more useful because they give you a concrete research question. Use broad signals as filters, not triggers by themselves. Suppose a company announces a new funding round. Do not immediately send it to outreach. First look for a second signal: enterprise-focused hiring, new customer-facing security documentation, a revised pricing page, or a leader discussing larger deal requirements. The tradeoff is volume versus relevance. Broad signals create a larger list; paired, work-adjacent signals create a smaller list that is easier to research well.

• High-value examples: a relevant job opening, product packaging change, new integration, leadership hire, regulatory deadline, expansion into a new customer segment.
• Lower-confidence examples: funding, office expansion, a general brand refresh, or a broad “growth” announcement.
• Use a two-signal rule for ambiguous events: research an account deeply only after one broad signal is supported by one work-adjacent signal.

Do not create a complex lead score before you have enough evidence to justify it. A lightweight worksheet is enough. For every observed account, score the signal’s relevance to your hypothesis, its recency, the evidence that the company can act, and whether you can identify a likely owner. Use a 0–2 scale for each criterion. The purpose is not mathematical precision; it is to make tradeoffs visible and prevent the loudest news from dominating your attention. As a hypothetical, imagine you sell a tool for managing customer implementation handoffs. Company A raised funding last week but has no visible implementation team or customer expansion activity. Company B posted roles for implementation managers, launched a services page, and added onboarding language to its product documentation. Company B should score higher even if Company A is better known. Its signals are closer to the workflow, provide an owner to research, and imply a more immediate operational change.

• Relevance: 0 = loosely related, 1 = plausible connection, 2 = directly tied to the workflow.
• Recency: 0 = older than six months, 1 = within six months, 2 = within 60 days.
• Ability to act: 0 = unclear, 1 = some evidence of investment, 2 = hiring, new team, budget-adjacent activity, or active initiative.
• Reachability: 0 = no likely owner, 1 = likely department only, 2 = named leader or clear role to investigate.
• Prioritize accounts scoring 6 or more out of 8; keep lower-scoring accounts in a watchlist rather than forcing outreach.

Once an account clears your threshold, research the change itself before searching for contacts. Capture the source, date, what changed, and what that change might mean for the relevant workflow. Then actively look for disconfirming evidence. A role may be posted because a team is replacing an employee rather than expanding. An integration launch may be a minor partnership rather than a strategic move. This short validation step protects a small team from spending time on false positives. Turn the evidence into two or three testable hypotheses, not a fully formed sales narrative. For the implementation example, one hypothesis could be that rapid customer growth is making handoffs inconsistent. Another could be that the company is building a new implementation function and needs processes before adding tools. Each points to different people and different questions. If public evidence cannot support a useful hypothesis, stop after the account research and return it to the watchlist.

• Record: source URL, observation date, exact language, related teams, and confidence level.
• Ask: What changed? Which workflow might be affected? Who would notice first? What would make this interpretation wrong?
• Identify one primary role and one adjacent role. For example, research a VP of Customer Success and a head of implementation rather than collecting ten loosely related contacts.

Your process should produce learning even when it produces no meeting. Set aside a weekly block to review newly observed signals, score accounts, research the highest-priority few, and prepare a limited number of outreach drafts. Puffle helps teams find relevant people, research them, and prepare email and LinkedIn outreach for review; regardless of the tool used, keep a human review step so that each message reflects the actual evidence rather than a generic trigger. After outreach, label the result by signal type and hypothesis. A non-response does not prove the signal was poor: the role, timing, message, or channel may have been wrong. But after several attempts, patterns become useful. If accounts with implementation hiring consistently yield better conversations than accounts with funding news, shift your research time accordingly. With a small base, treat this as directional evidence, not a universal conclusion.

• Monday: collect signals and add only observable sources to the queue.
• Tuesday: score accounts and research the top five to ten, depending on team capacity.
• Wednesday: select one or two relevant people per qualified account and prepare reviewed outreach.
• Friday: log outcomes, objections, missing assumptions, and signals that led nowhere.
• Every month: remove one weak signal from the process and add or refine one signal suggested by real conversations.

If you want help doing this work, these Puffle pages show the product in more detail.

• How Puffle works
• Outbound automation
• Browse all GTM guides