TL;DR: Validate a B2B SaaS idea around a particular buyer doing a recurring job. Write down the current workaround, its business cost, who can approve a purchase and what would trigger that purchase. Then test a small offer against that map.
This checklist is for the step between choosing a category and building a product. A category such as accounting, recruiting or logistics gives you somewhere to look. The checklist turns that category into a buying hypothesis you can investigate.
What exact workflow are you trying to improve?
Complete this sentence:
When [a specific event] happens, [a specific role] must [complete a job], using [the current tools], before [a deadline or consequence].
A fictional example: when an agency prepares its monthly client review, an account manager combines exports from several tools into a report before the client meeting. That description gives you a task to observe, an operator to interview and a place to inspect the output.
Make the segment narrow enough that people share the same constraints. A solo bookkeeper and the finance team of a multinational may use similar words while buying software in entirely different ways.
Record the boundary of your first segment: company size, existing tools, workflow frequency and any country or industry requirements. Leave an item marked unknown until you have evidence for it.
Who uses it, who benefits and who pays?
| Role | What you need to learn | Evidence to request |
|---|---|---|
| Operator | Where the work becomes slow or unreliable | A recent example of the task and its output |
| Outcome owner | What happens when the task goes wrong | A missed deadline, rework, lost revenue or another concrete consequence |
| Budget owner | How a purchase is approved | The approval process and a comparable recent purchase |
| Adoption gatekeeper | What could prevent deployment | Access, security, integration or procurement requirements |
One person can fill several rows. Keep the rows separate in your notes so enthusiasm from an operator does not silently become approval from a budget owner.
Ask how the last comparable tool was bought. A description of an actual purchase is more useful than a hypothetical answer about whether someone likes your idea.
What does the current workaround cost?
Look for work that already consumes time, money or attention. Useful examples include repeated reconciliation, copying data between systems, checking an output by hand, paying a contractor, or maintaining a spreadsheet that another team depends on.
For each example, record:
- The last time the work happened and how often it recurs.
- Who did it and roughly how long it took.
- Which tools and people were involved.
- What failed, or what checking was needed to prevent failure.
- Who absorbs the consequence.
Calculate a cost only from values the customer can support. If someone knows the task takes an afternoon but cannot estimate the financial impact, preserve that distinction. An invented hourly rate can make a weak buying case look precise.
Public discussions can help you find the vocabulary of these workarounds. In PainHunt's validator, try the task, the existing tool and the failure separately. Read the linked evidence to check that the person, workflow and context match your intended customer. The research guide explains how to keep that evidence trail.
What would make someone buy this month?
A buying trigger gives the problem a date. It could be an upcoming audit, a new client, a recurring reporting deadline, a price increase, a failed integration or a change in the volume of work.
Ask what the buyer would do if your product were unavailable. The answer may be to hire someone, continue the workaround, change an existing tool or postpone the project. Each answer tells you something about the urgency and the alternatives.
Also ask what would prevent a purchase even if the product worked. A tool that needs access to restricted customer data may face an adoption problem much larger than its coding problem.
How should you test the first offer?
Offer a bounded outcome: a paid pilot, a manual service with a clear deliverable, or a small integration for one workflow. Describe what the customer supplies, what they receive, when they receive it and what success means.
| Finding | Practical next step |
|---|---|
| Recurring workaround, clear owner and a concrete commitment | Deliver the smallest version of the outcome |
| Strong operator interest, budget owner still unknown | Find the buying process before expanding the build |
| Real pain, existing product solves it satisfactorily | Investigate a different segment or workflow |
| Adoption requires work you cannot support | Reduce the scope or choose a more accessible workflow |
| Evidence is mostly general opinions | Observe recent tasks and gather specific examples |
Set a decision rule before the conversations. For example, decide which unanswered question would stop you building and what commitment would justify a pilot. Treat that rule as your experiment design; adapt it to the cost and sales cycle of your product.
What belongs in your decision record?
Keep a short brief with the segment, workflow, buyer map, strongest supporting evidence, strongest counterexample and next commercial test. The SaaS validation report template provides a copyable structure.
Use the validator to investigate the problem and the pain-point browser to inspect related signals. Public evidence helps you choose better interview questions. A buyer's concrete commitment is what lets you move from research to a commercial decision.