Build your ideal customer profile (ICP) around a recurring task, the point where it fails, and the change that makes fixing it urgent. Use company size and job titles to find candidates, then check whether they share that situation.
Two companies with the same headcount and budget can have very different reasons to buy. Imagine one has a reliable customer handoff process while the other has a coordinator repairing missing information every Friday. The company filters match; the need does not.
The worksheet below helps AI and SaaS founders turn that distinction into a provisional ICP for research, account qualification, and messaging tests.
Define the customer situation before choosing filters
For this exercise, a workflow-based ideal customer profile describes organizations that share a recurring task, a consequential failure in that task, and conditions under which your product could help.
Start with the customer’s current alternative. April Dunford’s positioning method begins with what customers would do without your product, then connects differentiated capabilities to value and the customers who care most about it. That alternative may be a manual process or a spreadsheet. Read Dunford’s positioning guide.
Ask what makes the current approach inadequate and what your product can demonstrably improve. Then give each company attribute a reason to be in the profile. A particular integration might be necessary to deliver the product. Multiple locations might create the handoff problem. An employee range might help you find prospects while telling you little about their need.
Label each attribute as a requirement or a prospecting aid. This keeps a convenient search filter from excluding otherwise suitable buyers.
Reconstruct one recent failure
Choose one workflow your product can plausibly improve. Define its beginning and end, such as turning an approved sales agreement into an implementation plan with an assigned owner.
Ask someone who performs the work to walk through a recent instance:
- What started the work, and what counted as finished?
- Which people, documents, and tools did it pass through?
- Where did someone wait, repeat a step, or correct information?
- What happened because of that failure?
- What has the team tried, and why does it still use the current approach?
- Has anything changed that makes solving this more urgent?
Ask for a redacted example or demonstration where appropriate. Use it to identify the failed step and its consequence rather than settling for a broad complaint about efficiency.
Keep the person’s wording separate from your interpretation. Joanna Wiebe’s review-mining method examines the solutions prospects already use and preserves their language with minimal abstraction. Use that language to develop questions and messages to test. See the original review-mining method.
If you do not have customers yet, public discussions can supply initial hypotheses. FindVex’s pain-point evidence sheet guide explains how to organize those observations. A public complaint does not establish the writer’s budget, authority, or willingness to switch. Leave those questions open until you investigate them.
Separate recurring pain from a buying trigger
A failure describes what goes wrong. A buying trigger describes what changes the priority of fixing it.
A team might tolerate manually checking every customer handoff until a new service commitment makes the delays unacceptable. A departing coordinator could remove the person who kept the process working. Treat these as possible triggers to investigate; growth alone does not establish urgency.
Ask what happened between tolerating the problem and considering a change. An account can fit the problem while having little reason to act now.
Record who owns each decision. The person doing the repair work may champion a test, another person may control the budget, and someone else may approve data access. Knowing who feels the pain is only part of knowing whether the team can adopt your product.
For an AI product, also ask who would check the output, what errors would be unacceptable, and whether that review would erase the expected benefit.
Copy this workflow-based ICP worksheet
Create one worksheet per candidate segment. Start with a specific account or incident, then add evidence from other accounts before treating its situation as a segment pattern.
Use the last column to record a source, date, and evidence status for each answer. Observed means you inspected a relevant artifact or watched the work. Reported means someone described it. Assumed means it is your inference. Write unknown when you have no answer. A demonstration of one failure does not establish how often it occurs; record frequency separately if it is only reported.
| Field | Prompt | Your answer | Source, date, and status |
|---|---|---|---|
| Workflow | What event starts the work, and what output finishes it? | ___ | ___ |
| Current alternative | Which tools, people, and workarounds handle it today? | ___ | ___ |
| Recurring failure | Which step breaks, and how often? | ___ | ___ |
| Consequence | What delay, rework, expense, or exposure follows? | ___ | ___ |
| Buying trigger | What changed to make action timely? | ___ | ___ |
| People involved | Who uses, owns, pays for, and approves the change? | ___ | ___ |
| Product advantage | What capability can you demonstrate against the current alternative? | ___ | ___ |
| Adoption conditions | What data, integrations, permissions, and review capacity are required? | ___ | ___ |
| Account filters | Which company traits matter, and which are only prospecting aids? | ___ | ___ |
| Exclusions | Under what conditions would the product be a poor choice? | ___ | ___ |
| Evidence gap | Which unanswered question could most change your decision? | ___ | ___ |
| Next test | What will you do, measure, and use as a decision rule? Who owns it? | ___ | ___ |
Keep conflicting accounts visible. If a coordinator reports frequent omissions but a manager says handoffs work well, record both claims and choose a recent handoff to examine together. Do not combine them into an unsupported average.
For early qualification, record whether an account is worth investigating now, potentially suitable later, or unsuitable for the current product. Add the reason and any unresolved question. Missing evidence, weak urgency, and a known incompatibility call for different next steps.
Worked example: an AI handoff assistant
Suppose a founder is developing an AI assistant that drafts implementation handoffs from sales notes and signed agreements. Everything in this example is hypothetical, including the figures and proposed product capabilities.
The initial ICP is US B2B SaaS companies with 20 to 100 employees. To explain why a company would buy, the founder focuses on teams where sales and implementation have separate owners, customer commitments are scattered across documents, and a coordinator manually assembles each handoff.
Here is how that candidate situation could fill part of the worksheet:
| Field | Hypothetical entry | What still needs checking |
|---|---|---|
| Workflow | Signed agreement becomes an implementation plan with an owner. | Walk through a recent handoff. |
| Current alternative | Coordinator gathers commitments from sales notes and agreements. | Inspect the documents and actual steps. |
| Recurring failure | Missing dependencies are discovered after kickoff. | Establish frequency from recent handoffs. |
| Consequence | Kickoffs need rescheduling and more coordination. | Identify who bears the cost and how it is recorded. |
| Buying trigger | A new kickoff deadline exceeds what the current process can reliably support. | Confirm the deadline and its effect on the buying decision. |
| Product advantage | Draft links extracted commitments to sources and flags missing information. | Demonstrate the capability on representative documents. |
| Adoption conditions | Implementation lead reviews output; operations owner approves spending; security reviewer assesses data access. | Confirm these roles, permissions, and review capacity. |
Imagine the coordinator estimates 12 handoffs per month at 45 minutes each. That is nine hours of monthly work to verify as a baseline. Any savings calculation must account for preparation, review, correction, and setup with the assistant.
Exclusions sharpen the profile. Standardized agreements and reliable automatic handoffs may leave little need for the product. Unsupported data controls may prevent adoption. If checking every draft takes as long as preparing a manual handoff, the proposed time advantage has failed its test.
The provisional ICP becomes:
B2B SaaS teams with separate sales and implementation owners that manually assemble customer handoffs from scattered commitments, experience recurring omissions, and face a deadline or operational change that makes those omissions urgent to fix.
Headcount remains a prospecting aid until evidence shows it explains fit. The workflow, consequence, and trigger provide specific reasons to investigate an account.
Test the weakest assumption before narrowing further
Choose the unanswered question that could invalidate the segment. Does the failure recur? Does anyone own its consequence? Can the product improve the complete process after setup and review?
Write the hypothesis, test, measure, and decision threshold before starting. These are the four elements of Strategyzer’s Test Card. See Strategyzer’s explanation.
For the hypothetical assistant, begin by examining recent handoffs from several independent companies. Record how you found each participant. Include teams whose process works well so you can investigate what distinguishes them from teams with recurring omissions.
If that research supports the problem, use a separate product test. A proposed test plan could read:
| Element | Plan for the hypothetical assistant |
|---|---|
| Hypothesis | The assistant reduces total handoff work while preserving required commitments and dependencies. |
| Test | Compare manual and assisted preparation on comparable, representative handoffs. Have the implementation lead check each against its source documents. |
| Measure | Record preparation, review, correction, and downstream repair time. Record setup effort separately, plus missed commitments and incorrect details. |
| Decision rule | Before testing, agree on the minimum time reduction that would justify switching and which errors would block adoption. Proceed to another test only if both the time and quality requirements are met; otherwise revise the product or reconsider the segment. |
| Owner | Assign a person to collect the results and explain the next decision. |
This is a proposed test, with no results implied. Set the thresholds with the workflow owner because the acceptable tradeoff depends on the work and the consequences of errors.
A few interviews can sharpen a hypothesis; they cannot establish market size. Agreement to try a prototype also leaves willingness to pay and continued use untested.
Complete one profile and choose its next test
Before using the profile for account selection or messaging, check whether you can describe a recent failure, name the owner of its consequence, and support the proposed buying trigger. Keep an unknown trigger visible. Confirm that the product advantage can be demonstrated and that adoption requirements and exclusions are recorded.
Some workflow signals will be difficult to discover from public company data. Use visible attributes to find candidates, then verify the underlying situation in conversation. An absent public signal does not establish that the problem is absent.
In your next work session, complete the worksheet for one prospect you already understand. Circle the assumption that would most change whether you pursue that account. Turn it into a question about a recent event or an observable test, assign an owner, and write down how the answer will change your decision.
