For your first SaaS prospect list, choose up to ten companies and record why each might fit your product, what public evidence supports that idea, and what you still need to learn. A spreadsheet is enough.
Ten is a suggested working limit. Reduce it if you cannot research that many accounts in the time available. The finished list should help you decide which companies deserve a conversation, which need another check, and which to set aside.
Define the situation your product can help with
Before collecting names, describe the work your product changes. Include what someone might do today, what your product does differently, and the conditions that make that difference useful.
April Dunford’s positioning method connects customers’ alternatives to differentiated capabilities, their value, and the customers who care most about that value. You can use that sequence to decide whom to investigate. Dunford’s positioning guide explains the method.
Suppose you are building an AI tool that drafts customer handoff notes for implementation teams. “B2B SaaS companies” leaves too much open. A more useful working description is:
US software companies that provide assisted implementation and pass customer context between sales and implementation staff, where a person could review an AI-drafted handoff summary.
Treat this as a hypothesis. You have not established that these companies have a painful handoff process or want AI involved.
Write down exclusions before you search. For this example, exclude companies whose onboarding is entirely self-service and accounts that require integrations your product cannot support. If you cannot check a necessary condition publicly, mark it as unresolved.
Set a research budget and decide what qualifies
Try a 90-minute first pass: 15 minutes to define the segment, 60 minutes to investigate candidates, and 15 minutes to review the list. These are suggested limits, not benchmarks. Allowing six minutes per candidate gives you time to spot an obvious mismatch; a complicated account may need a separate session.
Give every candidate one of three statuses:
| Status | Evidence needed | Next step |
|---|---|---|
| Ready for a fit conversation | A relevant public observation supports a plausible use case, with no known product constraint ruling it out | Identify the appropriate role and ask about the remaining uncertainty |
| Needs verification | A necessary condition remains unknown | Record the specific page to check or question to ask |
| Set aside | Evidence shows a workflow mismatch or a known product constraint | Record the exclusion reason |
The observation must connect to the work. A new office announcement says little about an implementation handoff. A current job description assigning responsibility for the sales-to-implementation transition gives you a more relevant starting point. It still does not establish a need for your product.
Keep excluded accounts and their reasons in the sheet so you can avoid researching them again. Stop when the time budget ends, even if fewer than ten accounts are ready.
Search for evidence about the work
Begin with company websites, help centers, product documentation, careers pages, and announcements. Use directories or search results to discover candidates, then open the company’s own pages to check the details.
For the handoff example, possible discovery queries include:
"SaaS" "implementation manager" "sales handoff""customer onboarding" "implementation services" softwaresite:example.com "implementation"
Replace example.com with a candidate’s domain. Google supports quotation marks for exact phrases, site: for a specific site or domain, and a minus sign to exclude words. Keep the operator attached to its term. These controls narrow a search but cannot establish that you have found all relevant evidence. Google’s search operator documentation explains the syntax.
Open the result before recording a claim. Check whether a job is still listed, whether an announcement describes a current offering, and whether a help article applies to the product you are investigating. Save the page URL, its date if shown, and your check date separately.
Public discussions can help you find language for your questions. Joanna Wiebe’s review-mining method involves reading reviews of existing or similar solutions and retaining people’s wording with minimal abstraction. Her review-mining guide describes the approach.
An anonymous complaint about handoffs does not establish that a particular company has the same problem. Collect recurring frustrations in the FindVex pain-point evidence sheet, and connect only attributable evidence to individual accounts.
Separate observations from your interpretation
“The careers page lists an implementation manager opening” is an observation. “The team is overwhelmed” is an interpretation. “They have budget for our product” is another assumption the opening does not support.
Keep those distinctions visible in the sheet:
| Field | What belongs there |
|---|---|
| Public observation | A specific fact or brief attributed excerpt, with its URL |
| Fit hypothesis | Why the observation may connect to your product’s use case |
| Explicit unknown | A question whose answer could confirm or undermine the fit |
Choose an unknown that could change your next action. For the handoff tool, “Can customer context leave their existing system for processing?” is more useful than “Do they like AI?” If your product requires external processing, the answer could rule out its use.
If you use an AI assistant to organize notes, check every retained claim against the underlying page. Mark missing details as unknown and keep interpretations in the hypothesis field.
Worked example: three candidates, different decisions
The following companies and observations are fictional. They demonstrate how to use the worksheet; they are not customer results.
Account A offers assisted implementation. Its product page describes guided onboarding, and a current job listing assigns an implementation manager responsibility for receiving customer context from sales. Together, those observations support a possible use case for the handoff tool.
Mark A as ready for a fit conversation. The next action is to identify the person responsible for that transition and ask how the team transfers context today and whether anything gets lost. The status means you have enough context to ask a useful question. Pain, budget, and purchase intent remain unknown.
Account B is hiring customer success staff, but its product site and job description do not explain implementation responsibilities. Mark it as needs verification. The next action is to check its onboarding documentation for evidence of assisted implementation. If the research budget expires first, leave the question open.
Account C’s documentation describes customers activating and configuring the product themselves. That establishes a self-service option, but leaves open whether the company also offers assisted implementation. Mark C as needs verification unless you find evidence that onboarding is entirely self-service. With that confirmation, set it aside for this batch and record “workflow mismatch” as the reason.
This last distinction matters: finding one onboarding route does not tell you whether another exists.
Copy this prospect research template
Create one record per company before collecting several people from the same business. Keep your segment definition and research budget at the top of the sheet.
Company and website:
Business-fit hypothesis:
Public observation:
Source URL:
Page date, if available:
Date checked:
Explicit unknown:
Known exclusion or product constraint:
Relevant role and evidence for that role:
Appropriate business contact route, if available:
Status: ready for a fit conversation / needs verification / set aside
Reason for status:
Next action:
Research minutes:
Later learning and date:Add a separate observation and source URL for each supporting page. Use “unknown” for missing facts so a teammate can distinguish an unanswered question from an overlooked field.
Keep the relevant role provisional until you have evidence. The person performing the work, choosing software, and approving spending may be different people.
Before marking an account ready, check that you opened its sources, that the observations support the proposed workflow, and that no known product constraint rules it out. The fit explanation should leave pain, budget, and purchase intent unresolved unless you have evidence for them. Finish the record with a question that could change your decision and a specific next action.
Review what the list taught you before expanding it
At the end of the batch, count accounts investigated, accounts ready, unresolved accounts, and exclusions by reason. Record the time spent. These numbers describe your research process; they do not establish conversion benchmarks.
If most candidates lack the relevant workflow, revise the search criteria. If fit appears plausible but the same technical question blocks every account, resolve that constraint before collecting more names. After a conversation, record what it confirmed or contradicted alongside the original hypothesis.
A manual list built from public pages favors companies that describe their work in detail. Companies with sparse websites may still fit, and a selected batch cannot establish market-wide demand. Keep missing evidence under needs verification.
Complete three records before adding more
Choose one segment, set a timer, and complete the first three records. Review each source and status before adding a fourth account.
Each record should show why the company might fit, what you have verified, and the next question to resolve. If any of those is missing, make filling that gap your next task.
