Lesson 80.0 named the fork: product-led or community-led first, with hybrids real but demanding. This closing lesson makes the hybrid an operating model. A paid product with a member community around it — or a community whose needs shape the product — can compound beautifully. Run half-heartedly, it starves both: the product loses focus, the room loses care, and each side blames the other.

Name which side leads

Every hybrid has a lead side and a supporting side. Name it explicitly, because the lead decides priorities, metrics, and staffing when they conflict.

• Product-led hybrid: the paid product is the business; the community drives adoption, feedback, and retention. Metrics that matter: activation, retention and churn, MRR, support load. The community exists to make the product succeed — office hours that teach the workflow, a showcase gallery, peer templates. Sonariq's research workspace with a member circle around it is product-led: community feedback ships product improvements, and product value justifies dues.
• Community-led hybrid: the community is the business; the product deepens participation. Metrics that matter: participation, contribution, renewal reason, ritual health. The product exists to make the room stronger — a shared source library, a brief-review tool, a member archive. ByeBuy Classroom's circle with a lightweight toolkit is community-led: product decisions serve the practice, and dues fund both.

Write the sentence from Lesson 80.0 again, now as an operating commitment: "___ leads; ___ supports; when they conflict, ___ wins." Revisit it annually, because successful products tempt community-led rooms to flip without admitting it.

For examples of how product-plus-membership economics get framed for supporters, browse Patreon Creator Hub and note which pages let the product carry acquisition while membership carries retention.

Shared or separate P&L — and who subsidizes year one

Teach the economics choice plainly. A shared P&L pools product and community revenue against combined cost: simpler, honest about cross-subsidy, but can hide a failing side. Separate P&Ls give each side revenue, cost, and margin: clearer accountability, more bookkeeping, harder arguments about shared costs (moderation that also does support, content that also markets).

Whichever you choose, answer three questions in writing:

1. Who subsidizes whom in year one? Name the direction, the amount, and the sunset date. 2. What happens to each side if the other stalls? Pre-commit the answer. 3. What is the stall plan? The trigger ("two quarters of flat participation despite staffed rituals") plus the response (shrink, merge, or pause — decided in advance, not in panic).

A workable year-one pattern: the lead side funds the supporting side with a capped subsidy, reviewed quarterly, expiring or renewing on evidence. Uncapped, unreviewed subsidy is how a beloved room quietly eats a viable product — or vice versa.

Firewall rules: what never crosses

Firewalls protect each side from the other's legitimate hunger. Publish them where both teams and members can see.

Never paywall: core rituals, help-seeking, and newcomer welcome. The Tuesday help thread, the ask-for-help channel, the first-week orientation stay free and sponsor-free even inside a paid product's community. Paywalling help turns support into extortion and kills the participation that feeds retention.

Never give away: the paid outcome, private data, and sponsor-free attention. The workflow's completed job, member contact lists, and the promise of an un-rented room stay protected even when growth wants them spent. Giving away the outcome to "grow community" trains members that paying is optional.

Edge decider: name who resolves gray cases — the archive with product IP in it, the workshop recording that teaches the paid workflow. One named owner, a 48-hour rule, and a written rationale each time.

Kill criteria: shrink one side on purpose

Teach the hardest hybrid skill: deliberately shrinking one side rather than running two half-systems. Two kill criteria, one per side, written before attachment sets in:

• Shrink community if: participation stalls while moderation cost rises — flat or falling peer answers, fewer returning contributors, more staff hours per thread — across two review periods. Response: cut rituals to the one that still works, pause the rest, keep help and welcome alive. A small alive room beats a large dying one.
• Shrink product if: churn stays unfixed and the community cannot repair it — cancellations cite missing value, not missing help; feedback is built but renewal does not move. Response: freeze the roadmap, serve the current workflow well, let the community lead until product evidence returns.

Either trigger may end in an honest single-side decision: a product with office hours instead of a community, or a community with tools instead of a product business. That is a success of the operating model, not a failure — it is the sentence from 80.0 finally answered with evidence.

Exercise: write HYBRID-OPERATING-MODEL.md

Create HYBRID-OPERATING-MODEL.md:

# HYBRID-OPERATING-MODEL.md — [Project], [date]

## Lead side + support side
- Leads: product-led / community-led: ___ / when they conflict, ___ wins because ___

## Economics (shared vs separate P&L)
- Model: ___ / year-one subsidy (direction + cap + sunset): ___
- If product stalls, community gets: ___ / if community stalls, product gets: ___
- Stall-plan trigger + response: ___

## Firewall list
- Never paywall (rituals/help/welcome): ___
- Never give away (outcome/privacy/sponsor-free attention): ___
- Edge decider (owner + 48-hr rule): ___

## Shared rituals (max three, each with owner + cadence)
1. ___ 2. ___ 3. ___

## Kill criteria (one per side, with metric + review date)
- Shrink community if: ___ / review on: ___
- Shrink product if: ___ / review on: ___

## Honest single-side fallback
- If hybrid fails, we run: ___ because ___

Worked mini-example — Research Desk, product-led: product leads, community supports adoption and feedback; shared P&L with product subsidizing six moderation hours/month through Q3; help channel and welcome never paywalled, completed-report outcome and member list never given away, founder decides edges in 48 hours; shared rituals are Tuesday teardown, monthly roadmap review, quarterly template jam; kill criteria are two flat participation quarters (shrink rituals) and two quarters of churn above target despite shipped feedback (freeze roadmap); fallback is product with office hours.

Finish line: a HYBRID-OPERATING-MODEL.md with lead side, economics plus stall plan, both firewall lists, an edge decider, three or fewer rituals, one kill criterion per side, and a named fallback.

Verify quickly: ask each side's owner "what do you lose first in a bad quarter?" If both point at the other side's budget, the subsidy and firewall are not believed — rewrite until each can state their own cut.

Common failure mode: the double half-system — two roadmaps, two metrics, one exhausted founder, and a room that senses it is now a support queue with dues. The hybrid model exists to force the choice before exhaustion forces it worse.

Check your understanding

1. How do product-led and community-led hybrids differ in metrics and in what the supporting side is for? 2. Why must the year-one subsidy have a direction, a cap, and a sunset date? 3. State one firewall rule per side and explain what breaks without it.

Next

Class 83 closes here — and with it the community pathway. Part XV's completion artifact asks for one track built deeply and the other sketched: carry your value exchange, member journey, partner policy, and portfolio into Part XVI, where only streams that passed the scale gate earn automation.