Find SaaS Interview Participants by Building in Public

The short answer

Recruit SaaS interview participants by sharing a specific problem, describing whose experience matters, and offering a private route to volunteer. Confirm fit and participation arrangements before scheduling. Record the recruitment route and prior product exposure, and separate public interest from completed interviews and supported learning.

Recruit SaaS interview participants through building in public by sharing a specific problem you are investigating, describing whose experience matters, and offering a clear private route to volunteer. Confirm the fit before scheduling. Record how each person found you and what they had already seen, then keep public engagement separate from completed interviews and what those conversations actually support.

A public product journey can give someone a reason to trust your invitation. It can also attract people who enjoy following founders but do not perform the work you need to understand. The useful transition is from a recognizable problem to a voluntary conversation about real experience.

This guide proposes a recruitment workflow and source-and-exposure record. Its café example is fictional. No recruitment campaign or customer interviews were conducted for this article.

Choose a discovery conversation, not a hidden product pitch

Name what you want to learn before asking anyone to participate. A discovery interview might explore how a café manager handles an incorrect supplier delivery today. A product test would ask someone to use a proposed tool. A sales conversation would explore a purchase. Be clear about which activity you are inviting.

In her customer interview guide, Teresa Torres distinguishes conversations about customers’ goals, needs, and context from sales, support, and solution testing. That is a useful boundary for a founder’s public invitation. It tells readers what they are agreeing to and helps you interpret the conversation afterward.

Keep the initial commitment bounded. Someone can discuss one recent experience without agreeing to recurring collaboration or becoming an early customer. If you need ongoing co-development instead, the guide to finding SaaS design partners describes that separate relationship.

Describe experience that makes someone relevant

Define the experience you need in ordinary language. A job title can help, but the actual responsibility may matter more. For a delivery-discrepancy question, look for someone who personally checks deliveries and follows up when something is missing or incorrect. A person who only approves software budgets may have a different perspective.

GOV.UK’s participant-recruitment guidance recommends actual or likely users and criteria tied to relevant experience or circumstances. Applied to a SaaS discovery question, this means choosing people who can describe the work you are investigating rather than recruiting whoever is easiest to reach.

Set criteria because they affect the question. If you are studying a recent event, define a useful recency window. If a particular operating setting matters, explain it. Avoid requiring people to use your preferred workaround unless that workaround is itself the subject of the research.

Treat a peer introduction as a route to a possible participant. A founder who knows a café operator can help the invitation travel, but the founder’s enthusiasm does not establish the operator’s experience or willingness to join. Let the intended participant decide whether to respond.

Use the public update to explain the open question

Show enough of your thinking for a relevant reader to recognize the problem. Explain what you currently understand, what remains uncertain, and why you want to hear about the existing workflow. A small diagram using fictional records can help when the process is difficult to describe.

Keep your proposed solution in proportion. If the purpose is to understand how people resolve delivery problems, a long feature demonstration can turn the invitation into a request for opinions about the app. You can disclose that you are building software while keeping the conversation focused on the person’s current work.

Place the invitation where that work is relevant and participation is welcome. A founder audience may offer useful referrals without containing many intended users. When sharing elsewhere, follow the community’s current rules and contribute the necessary context. Do not turn every unrelated thread into a recruitment opportunity.

Make the route to volunteer easy to identify. Explain whether to send a private message or use a short form, what happens next, and that expressing interest does not guarantee a session. Do not ask readers to post personal contact details or internal business information in public comments.

A fictional invitation for café managers

Imagine a founder exploring software for independent cafés that need to follow up on incorrect supplier deliveries. The current uncertainty is how managers notice, record, and resolve a discrepancy. The following is proposed invitation copy for that invented situation, not a real founder announcement or a participant quotation.

I am exploring how independent café managers deal with missing or incorrect items in supplier deliveries. I am especially interested in hearing from people who personally checked a delivery and handled a discrepancy in the past month.

I am building software in this area, but this conversation is about a recent experience and the process you use today. You will not need to install an app, share invoices, or make a purchase. I am planning a 25-minute private conversation, and I will explain the research and any recording arrangements before you decide to take part.

If this matches your work, message me with your role and whether you have handled this situation recently. I will confirm fit, timing, and the session details privately. Please keep supplier and customer details out of public replies.

The duration is an illustrative proposed commitment, not a benchmark. Before using similar copy, choose a duration and arrangements you can honor. State any compensation and its terms before participation. If the activity changes into a product test, update the invitation rather than extending the original agreement silently.

This example makes the unresolved work recognizable without asking people to praise a solution. It also leaves detailed scheduling and participation information for the private exchange. The public post opens a door; it does not complete recruitment.

Confirm fit and participation privately

Ask a small number of relevant screening questions. Confirm what the person does and whether they have the experience the invitation describes. Keep the questions neutral enough that someone can explain a mismatch. An ineligible volunteer can be treated courteously without being pushed into the session to fill a slot.

GOV.UK’s recruitment guidance also advises collecting only the information needed to manage participation. For a founder, that supports keeping the first exchange small. Do not collect documents, detailed operating records, or sensitive personal information merely to decide whether a conversation is relevant.

Before the interview, explain who is conducting it, its purpose, the activity, any recording or observers, and how information will be used. GOV.UK’s informed-consent guidance sets out those elements and the importance of voluntary participation. Agree on the arrangements and retain a record of that agreement.

Permission to take part is separate from permission to appear in a public founder update. Do not assume it covers naming the participant, showing a recording, or quoting a private account. Make any proposed public use specific and optional, and keep the research useful when publicity is declined.

Keep a source-and-exposure record

Building in public creates a special context for recruitment: a participant may already know your product story. Keep that context attached to the session. You do not need to exclude everyone who follows you, but you should not describe their reaction as an uninformed first impression when they have already seen the explanation.

This is an editorial record for interpreting the evidence, not a scoring system for people. Store it privately and retain only useful information. If you change the recruiting post or show a new demonstration between sessions, note that change rather than assuming every participant encountered the same material.

GOV.UK’s recruitment guidance identifies the activity, timing, location, and recruitment approach as sources of possible sampling bias. A self-selected public audience is therefore one route into research, not a claim that you have heard from the whole market. Consider what relevant experiences your route may be missing.

Ask about the work they actually did

Once the session begins, return to the research question. Invite the person to describe a specific recent event, then ask about the sequence, decisions, and difficulties in that account. Keep your proposed features out of the way while you learn how the existing work happens.

Torres’s interview guidance emphasizes stories about specific past behavior. For the fictional café question, the useful account concerns an actual delivery discrepancy: how it was discovered, what happened next, and where resolution became difficult. A general opinion that a new tracking tool sounds helpful answers a different question.

Separate the person’s account from your interpretation. A participant describing a missing follow-up step gives you something to investigate. It does not automatically prescribe a feature, establish willingness to pay, or demonstrate how common the situation is. Keep those later questions open until you have evidence for them.

Count the stages without inflating the result

Keep a simple recruitment record that distinguishes the stages below. Use actual counts only when you have retained the underlying records and defined what each count means. Do not collapse them into a single claim that a public post validated demand.

An empty stage is useful information. If the post attracts peers but no relevant volunteers, reconsider the audience and invitation. If suitable people volunteer but sessions do not happen, examine timing and the commitment. If conversations happen without clarifying the question, revisit the research focus.

A quiet public post does not prove that the underlying problem is unimportant. A lively one does not establish customer demand. Judge the recruiting route by the relevant conversations it helps you complete, and judge those conversations by what they can actually tell you.

Publish the learning without exposing the participant

Return to the original public question with a safe account of your own decision. Explain what you investigated, how participants were found, what you learned within that scope, and what still needs checking. Link the earlier invitation so readers can understand how the work developed.

You can describe a changed assumption or a new investigation without publishing a person’s identity, private records, or distinctive business circumstances. If you have permission to use specific material, keep the published account within that permission and preserve important qualifications.

Buildside’s About page describes public SaaS progress and useful collaboration. A research invitation and later decision update can fit that purpose. Buildside publishes this Journal; the article does not claim that the platform supplies a screened research panel or guarantees interview recruitment.

For the next invitation, choose one workflow question and one relevant experience. Let the public update explain why you are asking, then let a clear private process establish who can participate. The later public story should reflect the conversations completed, including the uncertainty they leave behind.

Common questions

Can I recruit interviews before my SaaS is ready to use?

Yes, when the activity is a conversation about relevant goals, needs, or current work. Describe the product stage and the activity honestly. Do not imply that working software or beta access is available when it is not.

Should I interview people who already follow my public updates?

They may have relevant experience. Record that relationship and any known prior product exposure, and consider which other relevant experiences your recruiting route may miss. Following you does not establish customer fit or make a sample representative.

Can I use a positive interview comment as a testimonial?

Do not assume research participation includes public endorsement. Ask separately about the exact words, identity, context, and intended public use. Keep research findings and marketing claims distinct, and do not turn an exploratory comment into a result the participant did not report.

Sources

• GOV.UK Service Manual: Finding participants for user research

• GOV.UK Service Manual: Getting informed consent for user research

• Teresa Torres, Product Talk: Customer Interviews

• Buildside: About the community

Frequently asked questions

A note from Uriel Bitton

This is a source-based recruitment method with a fictional café invitation, not a report of completed research. No recruitment campaign or interviews were conducted. Sources checked October 26, 2026. Buildside publishes this Journal; no screened-panel or guaranteed-recruitment capability is claimed.

Keep building with us

Get practical founder lessons and product updates in your inbox.

Subscribe or Join Buildside.

Keep reading