How do you get the first ten users without an audience?
Start with a narrow problem and people who already experience it. You do not need a large following to learn from a small group, but you do need a reason for those people to care. Choose a first task they can reasonably try, explain the commitment, and make participation voluntary.
Ten is a useful planning size because you can still speak with people individually; it is not a target every product must use. A complicated team workflow might need fewer, deeper trials. A simple utility may allow more lightweight sessions. Decide what evidence would change your product decision before choosing the cohort size.
Where should you look for people with the problem?
Write down places where the intended audience already discusses its work: an existing professional group, a relevant public question, people who have asked you about the problem, or a community that permits product feedback requests. Read the context before contributing. A visible complaint is evidence of a problem to investigate, not permission to send an unsolicited sales message.
A builder community such as r/ShowMeYourSaaS is useful for meeting makers and testing an explanation. If your product serves a different profession, add a route to that profession. For a fictional app helping freelance illustrators collect revision notes, a maker can assess the interface while an illustrator can test whether clients actually use the proposed workflow.
| Participant | Useful question | What remains unproven |
|---|---|---|
| Fellow builder | Is the product explanation understandable? | Whether the intended buyer needs it |
| Person doing the task | Does this fit the real workflow? | Whether a team will adopt or pay |
| Person responsible for buying | What would justify the commitment? | Whether repeated use will follow |
What should an early-user invitation say?
Name your relationship to the app, the specific task you want to learn about, and what participation requires. Explain whether the app is in beta, what is free or paid, and whether you would like feedback. Keep the invitation useful enough for someone to decline quickly when it does not fit.
For the fictional illustrator tool, a possible invitation is: I’m the maker of an app for collecting client revision notes. I’m looking for illustrators willing to try a sample revision round and tell me where the handoff becomes confusing. Would that fit your workflow? Adapt the wording to the setting, and ask before sending links or arranging a session when that is the community’s expectation.
Avoid promising savings you have not measured or implying you found a customer’s private problem through tracking. Invite people through appropriate, permitted channels. Mass messages turn a learning exercise into unwanted promotion and usually leave you with poor evidence about real interest.
What should a person do during the first trial?
Ask them to complete one meaningful workflow from a known starting point. Explain prerequisites and offer safe sample data when possible. Watch for the first place they become uncertain. A session where the maker silently fixes every problem may show that the concept is interesting while hiding how difficult independent use will be.
In the illustrator example, the task could be creating a sample revision request, receiving one comment, and marking it resolved. Record whether each step worked, what assistance was required, and whether the final state was clear. Separate a product failure from a missing explanation. The onboarding content guide provides a structure for completion checks and recovery instructions.
Which feedback should change the product?
Record observations in the person’s own terms, then distinguish the underlying need from their suggested feature. If someone asks for a spreadsheet export, learn what they do with the file and who receives it. The useful requirement might be a handoff to accounting rather than a preference for one export button.
Keep a small log with the intended task, observed obstacle, consequence, proposed change, and next check. Do not publish names or quotes without permission. Prioritize repeated obstacles that prevent the core task, while keeping unusual but important failures visible. The downloadable first-distribution worksheet includes a place to record these decisions without storing participant identities.
When should you look for a larger audience?
Expand when the current explanation and workflow are strong enough that another relevant person can make progress. That does not require a flawless app, but recurring failures should have a clear response. Ask whether someone would return for another real task and what would stop them. A pleasant first session and repeated usefulness answer different questions.
A maintained ShowMeYourSaaS profile can become one public destination for people who hear about the app later. Prepare it alongside your own onboarding page, then use the marketing plan for vibe coders to choose the next distribution experiment. A listing gives you a place to explain the app; the learning comes from what suitable people do next.