Lesson 79.1 earned borrowed trust one partner at a time. Marketplaces offer a different deal: strangers arrive already looking for a solution, comparing options inside a directory you do not control. You inherit intent — and you inherit the ecosystem's rules for format, quality, support, and reviews.

The vocabulary, in plain language

• Marketplace: a browsable collection where buyers compare solutions — an app store, template gallery, plugin directory, or services board.
• App marketplace: a store tied to a host product — listings extend that product and live under its approval, search, and billing rules.
• Integration ecosystem (ecosystem): the host product plus its developers, listings, docs, reviewers, and users. You join an ecosystem; you merely appear in a directory.
• Listing: your public page inside the marketplace — title, description, screenshots, pricing, setup path, and support link.
• Category: where the marketplace files you. Wrong category means invisible to the right intent and visible to the wrong complaints.
• Review: a user's public verdict inside the ecosystem. Reviews compound: early honesty plus fast support beats early volume plus silence.
• Platform dependency: the fact that the host can change fees, ranking, rules, or access. Distribution you rent, not own.

The mental model: a marketplace is a busy aisle in someone else's shop. Foot traffic is real, but shelf placement, lighting, and returns policy belong to the shopkeeper.

Why intent helps — and what the shopkeeper demands

People in a marketplace have already decided the job: "I need a meeting-notes summarizer for my docs app" or "I need a launch checklist for my store." That pre-qualified intent beats cold scrolling. But every ecosystem charges admission in the same currencies:

Format. Titles, lengths, image sizes, video rules, permission scopes, data-handling disclosures. A listing that ignores the format guide reads as careless before anyone tries the product.

Quality. Working setup on the first attempt, accurate description, current screenshots, no placeholder copy. Ecosystems demote listings that generate support tickets or refunds.

Support. A named owner, a response-time promise, and a maintained changelog. Marketplaces remember which makers answer. Lesson 88's support habits begin here, at listing scale.

Reviews. Requested at the right moment — after first value, not at install — and answered publicly with specifics. A three-star review with a thoughtful maker reply teaches more buyers than ten silent five-stars.

Ignore these and intent works against you: the same aisle that could have delivered twenty qualified trials delivers twenty public lessons in why your setup confused people.

Three shapes, refreshed at drafting time

Ecosystems change names, fees, and review flows. Recheck the official directory, developer docs, and listing guide at drafting time and record the date. The durable shapes below survive the refresh:

1. Integration in a workflow-tool ecosystem. A Research Desk "send brief to docs" connector inside a note-taking or chat product. Discovery happens beside the user's existing work. The winning asset is a two-minute setup plus a sample brief already formatted for the host. Support load concentrates on permissions and sync — document both on the listing.

2. Listing in an app directory. A local-booking add-on or a ByeBuy study template pack inside a productivity store. Discovery is search plus category browse. The winning asset is a precise title ("Same-week tailoring bookings for local shops") plus three screenshots showing before, during, and done. Category choice is strategy: file under the job, not the technology.

3. Template in a creator or productivity marketplace. A creator-led publication sells a filing-check template gallery. Discovery is preview plus review sentiment. The winning asset is a filled example beside the blank (Lesson 78.2's discipline) plus a 60-second walkthrough. Updates are the compounding move — version 1.3 with reader-requested fields outranks a prettier version 1.0 abandoned in place.

Each shape borrows the same lesson: the marketplace sends you people mid-job. Meet them mid-job or lose them.

The listing stack: six parts that must all work

Treat the listing as a small product, not a paragraph:

1. Precise job and title. Name the user, moment, and outcome. "Source-linked briefs for solo analysts" beats "AI research supercharger." 2. Proof and screenshots. Real output, current interface, one annotated before/after. Never stock mockups of features that do not exist. 3. Setup path. Numbered steps from install to first value in under ten minutes, with permission scopes explained in plain language. 4. Support owner and path. Who answers, where, and how fast — plus a link to docs and a changelog date. 5. Review request at the right moment. After the user completes first value (Lesson 79.4), inside the product, with an easy private-feedback alternative for the unhappy. 6. Owned-route back. A permission-based path to your email list, docs, or community (Lessons 78.1, 69.2) — disclosed, optional, never a hostage exchange for core function.

Miss one and the stack wobbles: great screenshots with no support owner produce one-star surprises; great support with a vague title produces silence instead of trials.

Exercise: draft one listing before you publish

Create MARKETPLACE-LISTING.md for a single ecosystem. Choose the ecosystem later chapters of this part already taught you to respect — search, social proof, and direct follow-up all point here.

# MARKETPLACE-LISTING.md — [Ecosystem, date checked]

## User job + category
- Job (user + moment + outcome): ___
- Category + 3 competitor listings: ___

## Title + promise (60 characters first)
- Title: ___
- One-line promise: ___

## Proof (current, dated)
- Screenshot 1 (setup): ___ / Screenshot 2 (result): ___
- Filled example link: ___

## Setup path (numbered, <10 min to value)
1. ___ 2. ___ 3. ___

## Support + maintenance
- Owner: ___ / response time: ___ / docs link: ___
- Last verified date + recheck date: ___

## Review plan
- Ask moment (after first value): ___ / private-feedback path: ___

## Owned route (optional, disclosed)
- Email/docs/community invite: ___ — why it helps the user: ___

## Dependency note
- What the host controls (fees/rank/rules): ___ / mitigation: ___

Worked mini-example — ByeBuy Classroom template pack in a docs-template gallery: job "first-year builders need a source-check checklist inside their notes"; category Templates › Research; title "Source-Check Pack: 10-minute filing brief"; screenshots show blank checklist, filled brief, and export; setup is three steps with scopes named; support owner replies within two business days; review ask fires after the first saved brief; owned route is an optional Tuesday research note.

Finish line: a MARKETPLACE-LISTING.md with job, category, title, proof, setup, support, review moment, owned route, and a dated dependency note.

Verify quickly: hand the setup steps to someone who has never seen the product. If they cannot reach first value in ten minutes without asking you a question, the listing is not ready — fix the steps before touching the screenshots.

Common failure mode: the download-count mirage — celebrating installs while ignoring activation, reviews, and support queue. Marketplace users are users, not counts. Measure first value and return (Appendix 79.A), not rank screenshots.

Check your understanding

1. What does platform dependency mean for a listing you cannot fully control? 2. Why must the review request wait until after first value? 3. How does the owned route protect you without violating ecosystem trust?

Next

Marketplaces borrow intent from strangers. Lesson 79.3 borrows momentum from people who already won with your product — referral loops that begin with something worth sharing, not a bribe for spam.