How to find your first five SaaS customer conversations
A buyer asks: how do you find the first five conversations before building? Start with people who already feel the problem, then ask about the last time it happened. A landing page can help collect follow-ups after those conversations; it cannot replace them.
Get the Summit landing page template · Open its live demo
Start with a recent problem, not a product pitch
The first five conversations are useful only if they reveal something a person has already tried to solve. “Would you use an app that does X?” invites a polite prediction. “When did this last happen, and what did you do?” asks for a memory.
Write a one-sentence description of the situation before you contact anyone. Keep it about a person and a moment: “A small bookkeeping firm needs to reconcile client files before month-end” is more testable than “accountants need better software.” If the sentence includes a proposed feature, remove it and describe the job instead.
Then list the people who encounter that moment. Start with reachable roles, not a broad industry label. A small group of bookkeepers who close client books every month is easier to find and compare than “finance teams.” The aim is not statistical representation. It is to learn whether the same costly or awkward moment appears in more than one real workflow.
Find people where the work already happens
Ask for a short conversation in places where the target role already discusses its work: a professional community, a local association, a public build thread, or an introduction from someone who knows the role. Make the request specific and small. Say what kind of experience you are trying to understand, how long the conversation will take, and that you are not asking them to buy.
A useful note is direct: “I’m learning how independent bookkeepers handle month-end reconciliation. Could I ask about the last close you completed? I’m looking for workflow details, not feedback on a product.” Avoid claiming you are doing research on behalf of an established company if you are not.
Do not send the same pitch to a large list. A few thoughtful requests give you room to learn whether your audience definition makes sense. If people in the role do not respond, that can mean the request is unclear, the channel is wrong, or the problem is not important enough to interrupt them. It is not proof of demand.
Ask about the last time, then follow the evidence
Begin with the last occurrence: “Tell me about the most recent time you had to do this.” Let the person describe the steps in their own order. Follow with concrete questions: What triggered the task? Which tools or files did they use? Where did they wait, repeat work, or ask someone else for help? What happened when it went wrong?
Ask what they tried before. If they built a spreadsheet, bought a tool, hired help, or accepted the problem, learn why that option fit. Ask what it costs in time or money only when the person can give an actual estimate. Do not turn a guess into a market statistic.
Avoid pitching your planned features during this part. A product description changes the conversation: people start reacting to your idea instead of describing their workflow. If they ask what you are building, give a short honest answer and return to the problem: “I’m exploring whether this workflow is painful enough to deserve a better tool. I haven’t established that yet.”
Keep a simple evidence record
After each conversation, write down the role, the situation, the existing workaround, and the consequence. Keep the person's own wording in quotation marks only if you captured it accurately and have permission to retain it. Separate observations from interpretations. “They export three reports before the close” is an observation; “they would pay for automation” is a hypothesis unless they actually described a buying action.
A small comparison table helps expose differences without pretending the sample is representative:
| What to compare | Evidence to record |
|---|---|
| Trigger | What event starts the task? |
| Current approach | Which tools, people, or manual steps are used? |
| Friction | Where does delay, error, or repetition happen? |
| Existing commitment | What have they already paid for, built, or changed? |
| Next step | Will they introduce another person, share a workflow, or review a prototype? |
Look for repetition and meaningful variation. If every person describes a different task, narrow the role or situation. If several describe the same friction but use a workable substitute, investigate why the substitute is insufficient before deciding to build. If they like the concept but cannot recall a recent problem or prior workaround, record that as weak evidence.
Make the next step proportional to what you learned
Five conversations do not prove a market. They can show whether the problem statement is understandable, whether a repeated workflow exists, and which assumption you should test next. A stronger signal is a participant taking a concrete next step: sharing an example with sensitive details removed, introducing a colleague who owns the process, or agreeing to try a focused prototype when it exists. Do not treat a compliment or a hypothetical purchase as a sale.
If the workflow appears consistent, write down one testable promise and one audience. A concise page can explain who the tool is for, what task it helps with, and what the visitor can do next. If you have reached the page-test stage, see how to prove an AI landing page before traffic. Use a landing page as a way to make that test visible and gather responses; do not call page visits or sign-ups proof that users will pay.
For a first public test, keep the page narrow. State the intended user, the job, and the next step in plain language. Show only product details you can currently support. Ask for a reply, interview, or early-access request that lets you learn more. If no one responds, revisit the audience, the problem statement, and the channel before adding more features.
When to stop interviewing and build a test
Move from conversations to a prototype when the same specific moment recurs, people can describe a current workaround, and at least one next step is available that tests a real behavior. That next step might be a clickable flow, a manual service, or a deliberately small feature. Choose the smallest test that can disprove your riskiest assumption.
Keep an explicit “not yet” list. If you do not know who owns the budget, whether the task happens often enough, or what an acceptable alternative costs, those are open questions. Do not bury them beneath a long roadmap. A first version should test one workflow end to end, with a way to notice where a person gets stuck.
A useful validation loop is modest: recruit a few relevant people, ask about recent behavior, write down evidence, choose one assumption, and test it. Repeat when new evidence changes the audience or the workflow. The purpose is not to delay building until uncertainty disappears. It is to make the first build answer a question that real behavior has raised.
Choose the build path after the problem is clear
Once the problem and user are specific enough to test, choose the smallest implementation that supports the next learning step. If you need a marketing page to explain the test and collect follow-ups, the Summit template is a $9 starting point; its live demo shows the page structure. The template supplies a page and editable code. It does not supply customer interviews, a validated market, traffic, or customers.
For a larger SaaS application, a full dashboard starter is a different choice; it becomes relevant when the workflow you intend to test actually needs an app. Do not buy a larger build surface just because the idea sounds compelling. Let the evidence determine whether the next investment is a conversation, a page, a prototype, or a broader application.
Sources
- U.S. Small Business Administration, “Plan your business,” market research section, accessed 24 October 2026: https://www.sba.gov/counseling/plan-your-business/
- r/SaaS, “Why do SaaS beginners fail?”, posted 21 October 2026; one founder’s account, not prevalence data: https://www.reddit.com/r/SaaS/comments/1xbdbdw/why_do_saas_beginners_fail/
Ship your first screen tonight — free starter in your inbox
The quickstart, the SDK repo and the live kit demos, on this screen and in your inbox.
No spam. Unsubscribe any time.
