An audience is only one route to a launch. Start with a reachable group of plausible buyers, a legitimate way to enter their context, and a test that can prove your chosen route wrong.
Map distribution you can reach now
“Build an audience” hides several different jobs. A founder may need introductions, permission to contribute in a community, a list of organisations with a visible need, or search pages that answer a recurring question. Write down the routes you can use now, not the channels that look impressive in someone else’s launch story.
| Route | Access you actually have | Permission and context | What it can teach | Main risk |
|---|---|---|---|---|
| Existing relationships | Former colleagues, suppliers, clients or peers who know the buyer. | Ask for a relevant introduction, not a list dump. | Whether the problem description earns a conversation. | Spending trust on a vague or premature pitch. |
| Direct outreach | Public business context that gives you a defensible reason to contact a role. | Use respectful targeting, identify yourself, explain the reason and make refusal easy. Check applicable rules and platform policies. | Whether the role and trigger are specific enough. | Irrelevant contact, reputational damage or legal/compliance exposure. |
| Communities | A forum, group or event where the workflow is discussed. | Follow community rules. Contribute to the discussion before asking for attention. | How buyers describe the workflow and which advice they already use. | Turning a shared space into an unsolicited sales list. |
| Partners | Consultants, agencies or service providers already involved in the job. | Bring a clear benefit for their clients and a boundary that does not threaten their service. | Which cases are common, costly to serve or poor product fits. | Assuming a partner will distribute a product that creates support work. |
| Directories or marketplaces | A category where buyers already compare options. | Meet listing requirements and state the product boundary plainly. | Which category, use case and objections buyers expect. | Being visible beside established alternatives without enough proof. |
| Search | Questions tightly connected to the product’s workflow. | Publish a complete answer that remains useful without a sale. | Which questions recur and whether the product can support the answer. | Waiting for uncertain traffic when conversations are needed sooner. |
Leave a route blank if you cannot name the source of access. “LinkedIn” is not access. “Operations managers at firms that publish a monthly missing-document checklist, reached through a relevant professional association” is closer, provided the association and contact rules allow it.
Choose for fit, permission and learning
Score each reachable route with words, not false precision:
- Buyer density: are plausible buyers present, or only people interested in the topic?
- Reason to appear: can you explain why you are contacting or contributing in that context?
- Permission: do the recipient, community rules, channel policy and applicable requirements support the action?
- Learning quality: can the route produce a reply, conversation, observed workflow or another interpretable signal?
- Founder capacity: can you research, respond and follow through without resorting to careless automation?
- Reputation at risk: what relationship or community trust could you damage if the message is wrong?
A labelled example with no invented launch result
Illustrative scenario, not a founder or customer result. Assume a founder has built a tool that turns a contractor’s emailed job updates into a draft weekly status report. The founder knows two project coordinators, belongs to one construction-operations community that permits vendor participation in a designated thread, and can identify local firms from public company pages. The product has not yet proved demand or business impact.
| Route | Known access | Reason to use it | Decision |
|---|---|---|---|
| Introductions | Two coordinators can judge whether the workflow description is accurate. | Ask for a workflow critique or a relevant introduction, without implying they endorse the product. | Use first to test language. |
| Community | A permitted vendor thread exists. | Share an annotated sample report and ask how teams assemble theirs now. | Use if the contribution is useful on its own. |
| Direct outreach | Company pages show the relevant role, but not how the work is handled inside the firm. | Contact only when a public business trigger creates a genuine reason for the message. | Hold until the workflow language is sharper. |
| Search | The founder has no evidence yet about recurring queries. | Useful later if real conversations reveal repeat questions. | Do not make it the initial test. |
This map does not predict customers. It turns “launch somewhere” into choices that can be checked against access and behaviour.
Write a falsifiable launch test
A launch test should be able to fail for a stated reason. “Post consistently and see what happens” cannot distinguish a poor channel, a weak message or a product nobody wants.
Launch test record
For the illustrative contractor-report product, one test could ask permitted community members to critique a sample input and output. The hypothesis is: “People who assemble weekly project updates will identify a current manual step and ask a specific question about the draft report.” The test fails if the people reached do not own that workflow, the community context rejects vendor participation, or reactions stay at polite interest without workflow detail. No response target is assumed.
Read failure before switching channels
| What happened | Likely interpretation | Next decision |
|---|---|---|
| The right roles saw the offer but could not recognise the workflow. | The problem framing or segment may be wrong. | Rework the buyer moment before increasing reach. |
| People recognised the problem but the request felt premature. | The offer asks for too much trust. | Use a sample, narrower question or manual review. |
| The contribution was removed or contacts objected. | The route or permission assumption failed. | Stop. Review rules, targeting and suppression before any further contact. |
| Conversations produced specific non-fit reasons. | The test is learning, even without a sale. | Record the exclusion and decide whether a narrower buyer remains reachable. |
| One route creates useful conversations but exceeds founder capacity. | The channel may fit, but the operating method does not. | Reduce scope before adding automation. |
Start with the access you can defend
Complete one row of the distribution map. Name the buyer, access source, permission boundary, offer, claim under test and stop condition. If any field is vague, improve the route before making a launch announcement.