You can name your value exchange. Now you need to place it in the right family — because each family carries a different operational promise, and confusing them is how builders promise one thing and staff for another.

The five families

Every revenue model in this part belongs to one of five families. Learn the table cold; Lessons 81–83 each deepen one column.

| Family | Customer pays for | Useful examples |

|---|---|---|

| Software / product | ongoing access or a completed job | SaaS subscription, app, utility, data product |

| Service | expert implementation or judgment | consulting, development, research service, training |

| Knowledge product | structured learning or a reusable method | course, cohort workshop, template pack, paid report |

| Audience / media | trusted access to a relevant audience | membership, sponsorship, advertising, affiliate |

| Marketplace / transaction | a successful exchange between parties | fee per booking, commission, take rate |

A few notes that prevent the usual mix-ups:

• A course is not a product subscription. It sells a finite outcome (a skill, a finished artifact) with an end date. A membership sells belonging and continuing participation with a renewal reason.
• A service sells your judgment and delivery capacity. A product must work while you sleep. Price and staff them differently (Class 82 vs. Class 81).
• A marketplace only earns when the exchange completes. Browsing is free; the booking, order, or match pays.

One dominant model first

A mature project can hold several models. The Research Desk could eventually offer individual subscriptions, quarterly paid reports, *and* scoped advisory. ByeBuy Classroom could offer workshops, templates, sponsorships, and a member community.

It should not launch as all three. Here is why: each model demands different operations. Subscriptions demand onboarding, retention work, and billing support. Advisory demands scoping, delivery time, and revision handling. Sponsorships demand audience proof, a partner policy, and editorial boundaries. Running three promises with one person's capacity produces three mediocre experiences.

So choose one dominant model — the one that collects the first dollar and teaches the most — and park the rest in a "later" list with the condition that unlocks each. Lesson 80.3 scores the candidates; this lesson maps them.

The local business makes it concrete

Take a neighborhood tailoring and alterations shop. Same skills, five different promises:

• Product sale: a finished garment or hem kit, taken home. Promise: it fits and lasts. Work: inventory and quality control.
• Appointment fee / service: "event alteration, fitted and pressed." Promise: ready by Friday. Work: scheduling and delivery capacity.
• Package: "wedding party of four, two fittings each, backup hems." Promise: everyone ready, one coordinator. Work: scoping and coordination.
• Subscription / maintenance: "monthly mending and pressing for a small hotel." Promise: ongoing reliability. Work: retention and pickup rhythm.
• Referral commission: sending shoe-repair overflow to the cobbler next door for a cut. Promise: a successful handoff. Work: trust and tracking.

A customer understands each instantly — because each names a different job, boundary, and moment of payment. Your offer must do the same (80.4).

The niche publication shows the audience side of the same discipline. A membership sells belonging and deeper reporting; a sponsorship sells a relevant partner trusted access to that readership; a paid report sells one reusable research asset. Each has different proof, different staffing, and different trust risk — which is why Class 83 treats the community portfolio as its own full decision, not a footnote.

DO: map the field, then pick your primary

Exercise — two parts, 30 minutes.

Part A: classify three existing businesses. Pick one software tool you pay for, one local service, and one publication or creator you follow. For each, write one line: primary family, what the customer pays for, and one secondary stream. Example: "My notes app — product/subscription — pays for ongoing synced workspace; secondary: one-time template pack."

Part B: write REVENUE-MODEL-MAP.md. Use this template:

# REVENUE-MODEL-MAP
Primary model: [family + specific form, e.g. service — scoped research briefs]
Buyer + outcome: [who pays, what changes]
Operational promise: [what must work every time]
Possible later model: [family + form]
Why not yet: [missing proof, capacity, or audience — be specific]
Unlock condition: [e.g. 10 repeat service buyers → test a $29/mo workspace plan]

Finish line: a REVENUE-MODEL-MAP.md with a primary model, one possible later model, and a concrete reason the later one waits.

Verify: hand the map to someone outside the project. They should be able to say which family you are in and what must work operationally. If they guess a different family, your promise is blurred — tighten the outcome language.

Common failure mode: listing three primaries ("subs + reports + advisory"). That is a wishlist, not a map. Circle one. The others move to "later" with unlock conditions.

Check your understanding

1. Why is a course (knowledge product) operationally different from a membership (audience)? 2. A research workflow offers subscriptions, reports, and advisory. What breaks if it launches all three at once? 3. For the tailor's wedding package, who is the buyer, what is the outcome, and when does money change hands?

Next

Lesson 80.3 turns the map into a decision: which first model teaches you the most the fastest — who pays, for what, at what moment, and whether they return.