Last lesson you named the outcome: a specific person finishes a recurring job and returns. Now you have to name the *shape* of the thing that delivers it. Shape is not technology. Two apps can use the same model and be completely different products. Shape is the value promise — what the user is actually paying for with time, trust, or money.

The seven shapes

Read the promise column again. That is what the user remembers. Nobody wakes up wanting "a SaaS." They want the queue triaged, the comps organized, the Saturday test-drives planned.

Apply it to our idea pool:

• The used-car shortlist as a utility: rank my forty listings today. As a SaaS: a dealer team works every lead all month. Same engine, different promise, different price.
• The salary-bands brief as a data product: query any role, get sourced bands. As a media product: a weekly newsletter people read for fun. One is pulled on demand; the other is pushed on schedule.
• The support triage as an internal tool: our queue, our rules, our CRM. As a SaaS: any company's queue. The second requires multi-tenancy, onboarding, and SLAs the first never needs.
• The filing brief as an internal tool: our firm's matters. As a data product: any lawyer queries any docket. Different data rights entirely.

One dominant first promise

A product can contain more than one shape over its life, but version one needs one dominant first promise — the sentence a new user would use to describe you.

Research Desk is a data product first, not a SaaS. Its first promise is "trusted, source-linked briefs on public companies plus a private watchlist." It is not yet team workflows, roles, per-seat billing, and admin consoles. Calling it SaaS on day one drags in multi-user permissions, collaboration, and uptime promises the brief itself does not need. Those can come later, once individuals demonstrably return for the data.

Neighborhood Events is a community utility first, not a platform. Its first promise is "find something real to do this weekend; organizers manage only their own listings." A platform promises that organizers, attendees, venues, sponsors, and developers all interact successfully — with supply, demand, moderation, and cold start solved simultaneously. That is five products wearing a trench coat. Ship the utility: accurate listings, correct times, owner-only edits. Earn the right to be a platform.

Write your dominant promise as: "We are a [shape] that [job] for [person]." If you need the word "and" twice, you have two products. Pick one.

Why "platform" is usually premature

"Platform" sounds ambitious in a pitch. In practice it is a list of responsibilities most first versions cannot carry:

• Two-sided cold start. A used-car marketplace with no dealers is an empty lot; with no buyers it is a lot nobody visits. Utilities work with one user. Platforms starve without both sides.
• Identity and trust. Who is allowed to list, bid, review, refund? Events learned this early: only the organizer edits their own listing.
• Moderation and abuse. Public listings attract spam, scams, and duplicates. Someone must remove them daily.
• Incentives and supply. Why does the first dealer post, the first organizer list, the first writer publish? "Exposure" is not an incentive.
• Rules and economics. Fees, payouts, disputes, taxes — the unglamorous machinery that makes strangers transact.

None of this means platforms are bad. It means they are *second*. Start with the utility or data product that works for one side alone, then invite the second side once the first side already returns. Outbid.lol, which you will study in Class 56, works because the loop is legible before any network exists.

Exercise: classify three products + write APPLICATION-SHAPE.md

Pick three products you actually use — say, a maps app, a team chat app, and a newsletter — and for each write: primary user, primary recurring job, and the shape that best explains it. Argue with yourself where it is ambiguous. A team chat looks like SaaS but has strong community properties; a newsletter with a searchable archive is media plus data. The point is to practice naming the *dominant* promise.

Then create APPLICATION-SHAPE.md for your own idea:

# Application Shape

- Idea: House-price comparables brief.
- Primary shape: Data product — trusted, sourced comps on demand.
- Primary user/job: Buyer comparing one street before making an offer.
- Possible later shape: SaaS for buyer's-agent teams (shared searches, notes, alerts).
- Why not now: team roles, shared billing, and alert SLAs triple the build without proving anyone trusts one brief yet.

Finish line: an APPLICATION-SHAPE.md naming the primary shape, one possible later shape, and a concrete reason not to build the later shape yet.

Verify fast: cover the "later shape" line and ask a friend what you are. If they answer with your primary shape in one sentence, you chose well. Common failure: "we're a platform + SaaS + community." That is three roadmaps and zero finish lines.

Check your understanding

1. What distinguishes a data product from a media product? Use the salary-bands example. 2. Why is Research Desk a data product first rather than SaaS? 3. Why is Neighborhood Events a community utility first rather than a platform? 4. Name two responsibilities that come with the platform label.

Next

Shape tells you what promise you make. Next, Lesson 54.3 asks *to whom*: yourself, your team, or the public — because the same brief behaves like three different products depending on the audience.