Same technology, three completely different products. A house-price brief you run for yourself, a comparables console your brokerage team shares, and a public subscription anyone can join share almost no product decisions — even if they share code. This lesson teaches you to pick your first audience on purpose.

Three audiences, different products

• Personal machine (self). Built for one builder. You are the user, the support desk, and the quality control. Examples: your own trip filter spreadsheet-plus-model, your private used-car ranker.
• Internal tool (team). Built for people inside one organization. Examples: a support-triage queue for six agents, a filing-brief console for four paralegals, an events ops dashboard for two city coordinators.
• External product (customer). Built for strangers who pay, sign up, or simply arrive. Examples: a public salary-bands lookup, a public Research Desk subscription, a public events site.

The same idea morphs across all three. Take Research Desk:

A personal trip filter can hallucinate a hotel and you laugh and re-prompt. A public trip product that invents hotels issues refunds and apologies. The model did not change. The audience changed everything.

Internal tools are real

Beginners hear "internal tool" as a consolation prize. It is not. A useful internal tool eliminates repetitive work, makes decisions visible, reduces errors, and pays for itself in weeks:

• The support triage console that routes 300 Monday tickets before standup.
• The filing brief console that turns a docket dump into owners and deadlines with no missed dates.
• The events ops dashboard where two coordinators approve, correct, and feature listings before the public ever sees them.

Internal is often the smartest first audience: users sit next to you, data access is already granted, feedback arrives in hours, and there is no marketing. An internal tool becomes an external product only if the external problem is genuinely similar. Your firm's filing workflow, with its document styles and review chain, may not match any other firm's. Do not assume portability. Prove it by watching a second organization do the job the same painful way before you generalize.

Neighborhood Events shows the ordering clearly. The first build should be the private ops dashboard: coordinators see every submission, fix times, remove duplicates, feature the weekend picks. Only after listings are accurate week after week does the public community site deserve to exist. Public first means publishing other people's errors at scale.

The scope question

Before you choose, answer two questions honestly:

1. Who has the pain strongly enough to change behavior? Pain is measured in current workaround. The buyer screenshotting listings into a photo album has pain. The person who says "cool idea" and returns to old habits does not. The support lead drowning every Monday will try anything; the executive who likes dashboards in theory will not log in. 2. What access and data is safe to give them? A personal used-car ranker can hold your max budget safely. A public salary-bands product holding submitted pay stubs needs consent, anonymization, and deletion. A filing console touching client matters needs firm permissions before any external reuse.

If the pain is weak or the access is unsafe, shrink the audience. Personal first, then internal, then external — earning each step with evidence.

Exercise: the three-column table + first audience

Make a table for one idea — use the house-price comparables brief or the support triage — with three columns: personal, internal, external. Fill five rows: users, data, permissions, support burden, success metric.

Example sketch for support triage:

Then write your decision underneath: "First audience: internal — the six-person team — because the pain (Monday overload) and safe access (already in our CRM) both check out. Not personal, because routing only matters across agents. Not external, because multi-tenant PII isolation is a second product."

Finish line: a three-column audience table plus one explicit first audience and a written reason the other two are not version one.

Verify fast: show the table to the actual humans in your chosen column and ask, "would you use this weekly?" A polite maybe is a no. Common failure: choosing external for prestige while the only reachable, pained users sit in your own team.

Check your understanding

1. How do auth and support differ between an internal filing console and a public filing product? 2. Why is an internal tool a legitimate first product rather than a lesser one? 3. When is it safe to turn an internal tool into an external product? 4. Why should Neighborhood Events start as an ops dashboard rather than a public platform?

Next

You know the outcome, the shape, and the audience. Next, Lesson 54.4 narrows all of that to the wedge — the one small job you ship first before the imaginary platform swallows you.