Designs AI output sharing mechanics that turn users into a distribution channel. Covers the three types of AI virality, where to place share moments in the product, what outputs are inherently shareable, platform fit for different output types, embedding the product into shared artifacts, and how to avoid the virality-at-cost-of-trust trap. Use when designing an AI product sharing feature or diagnosing why output quality is high but organic growth is flat.
Instrucciones de origen · Vista previa de solo lectura
name
ai-output-virality
description
Designs AI output sharing mechanics that turn users into a distribution channel. Covers the three types of AI virality, where to place share moments in the product, what outputs are inherently shareable, platform fit for different output types, embedding the product into shared artifacts, and how to avoid the virality-at-cost-of-trust trap. Use when designing an AI product sharing feature or diagnosing why output quality is high but organic growth is flat.
triggers
["/ai-output-virality","user wants to add sharing mechanics to an AI product","AI product has high output quality but flat organic growth","user is designing a Discord community for an AI creative tool","user wants to design attribution patterns in AI outputs","user wants to measure K-factor for an AI product"]
Viral Mechanic Designer. AI products have a distribution advantage that traditional SaaS never had: the output of the product is itself interesting content. A generated image, a built app, a solved problem — these are shareable artifacts. The question is whether you design the product to make sharing happen, or leave it to chance.
Note: the virality-trust interaction (demo ≠ product fallacy, cherry-picking risk) is covered in pmm/DOMAIN.md. This skill covers the product design and distribution mechanics of output sharing.
Contract
This skill guarantees:
The three virality types are identified separately — design interventions are matched to the right type
Share moment placement follows the task-completion → acceptance → milestone sequence, not "immediately after output"
The virality-at-cost-of-trust trap is checked before recommending sharing mechanics
Attribution pattern selection is matched to product type and ICP (watermark vs. interactive embed vs. reproducibility link)
The Discord flywheel is included when the output type is visual
Before starting
Confirm (ask or infer):
Output type — images/visuals / apps / code / writing / data / conversations?
Current sharing behavior — do users share spontaneously? At what rate?
Share moment location — is there a designed share moment, or does it happen accidentally?
ICP — creative user / developer / business user? (determines platform fit and attribution preference)
Trust status — is the typical shared output representative of median quality, or best-case quality?
Inputs
Required before proceeding:
Description of the AI product and the output it produces
Current organic growth rate and channel
Whether a sharing feature exists and where it is placed
Whether a Discord or community exists
The three virality types
They require different design. Most AI products get one spontaneously. The other two require deliberate design.
Type
Mechanism
Where it works
Design requirement
Output sharing
Users share the artifact the AI produced
Creative output, generated content, built things
Low friction share moment after acceptance
Workflow sharing
Users share how they used the AI to accomplish something ("I used X to do Y in 10 minutes")
Productivity tools, coding assistants, research tools
Friction reduction on share; prompt the workflow story
Capability surprise
Users share the AI doing something they didn't expect was possible
Any AI product with a sufficiently surprising capability range
Community cultivation; the surprise moment needs a community context to spread
Step 1 — Share moment placement
SHARE MOMENT TIMING
The share moment must follow the wow moment — but not immediately, and not after
the user has moved on.
TASK COMPLETION → [WOW MOMENT] → [SHARE MOMENT] → BACK TO PRODUCT
Immediately after output generation: too early.
User hasn't processed whether the output is good yet.
A bad output shared instantly damages both user reputation and product reputation.
After the user has modified or accepted the output: better.
User has made a judgment that it's worth keeping.
After a meaningful milestone (first export, first share, first "done"): best for workflow tools.
User has validated the output by using it; share moment is natural.
FRICTION TEST:
If sharing requires more than two taps/clicks, most users won't do it.
Target: see output → one-tap share → done.
Test every share path against this standard.
Step 2 — Output shareability assessment
Not all AI outputs have equal virality potential. Assess against two axes:
Axis
Low
High
Visual distinctiveness
Plain text
Images, UI screenshots, diagrams, videos
Effort-to-result ratio
Routine output
Output that would have taken hours manually
The most viral AI outputs combine both: visually distinctive AND demonstrate impressive effort compression. A generated full-stack app screenshot from 3 lines of instruction scores high on both. A grammar-corrected paragraph scores low on both.
SHAREABLE OUTPUT CHECKLIST
[ ] The output is visually interesting or surprising
[ ] A viewer can immediately understand what was accomplished
[ ] The output includes a signal that AI was involved
(make it a feature, not a disclaimer — "built with [type of tool]")
[ ] The output has a natural share destination
(Twitter, Discord, GitHub, portfolio — not just "copy link")
If fewer than 3 of 4 boxes are checked:
The output type has low natural virality.
Options: (a) redesign the output format, or (b) focus on workflow sharing instead.
Step 3 — Platform fit by output type
Output type
Best share destination
Why
Generated images / design
Twitter/X, Discord
Visual-first feeds; image compression acceptable
Built apps / sites
Twitter/X thread, Product Hunt
"I built this with X" has a natural home; Product Hunt for launches
Code snippets / solutions
GitHub Gist, Twitter/X, Slack
Developers share code in these contexts
Writing / documents
Direct link (not social)
Writing shares poorly on social; a public link works better
Data analysis / charts
Twitter/X, LinkedIn
Data visualizations perform well on both
Conversations
Twitter/X screenshots
Conversation screenshots are a native Twitter format
The Discord flywheel (especially for visual/creative AI tools):
DISCORD FLYWHEEL
Discord communities where users share outputs create a reference gallery
that drives new user acquisition.
How it works:
User creates output → shares in Discord #showcase → other members see it →
some ask "how did you do that?" → creator describes the prompt/workflow →
new potential users discover the product through the showcase
Design before launch:
IF your output type is visual → design the Discord server structure before
you design the sharing feature.
Create a dedicated #showcase or #gallery channel.
Seed it: founding team and early beta users share first.
The seeding norm determines the community culture.
The Midjourney pattern: built its entire early user base through Discord
output sharing before any other acquisition channel.
Step 4 — Attribution patterns
The share moment is also an acquisition moment — but only if the artifact carries the product forward.
Pattern
How it works
Best for
Subtle attribution / "made with X"
Small attribution in the corner or footer; user can opt to keep or remove
Visual outputs; users often keep it if it looks good
Interactive embed
Shared link opens the artifact in the product; viewer becomes user
Apps, docs, interactive demos
Reproducibility link
"Try this prompt yourself" link
Productivity and coding tools where the prompt matters as much as the output
ATTRIBUTION ANTI-PATTERN:
Forced attribution (requiring users to keep a watermark for free tier access)
is a growth mechanic — but for developer-facing AI tools it often signals
cheapness rather than virality.
Test: offer watermark removal as a paid upgrade incentive instead.
- Free tier: watermark on
- Paid tier: watermark off (or custom branding)
This turns a forced cost into a perceived benefit of upgrade.
Do NOT force attribution for:
- Developer-facing tools (damages professional perception)
- High-stakes use cases (legal, medical, business documents)
Consider forcing attribution for:
- Consumer creative tools where the "made with X" is a badge of pride
- Social-first platforms where attribution drives discovery
Step 5 — The virality-at-cost-of-trust trap
THE TRAP:
Viral AI products that prioritize shareability over output quality create
a specific failure mode:
product becomes associated with impressive-looking but unreliable outputs →
users share → new users arrive → new users try on a real task → bad result → churn
THE TEST:
Does the output a user is most likely to share represent the product's
typical quality, or its best-case quality?
IF best-case quality is what gets shared → you have a trust problem disguised as
a virality win.
FIX: design the share moment to trigger on outputs that pass a quality threshold,
not on any output.
Option A: quality signal in UX — only surface the share button after an output
that meets a minimum threshold (e.g., user accepted/saved it; it passed a
confidence filter)
Option B: user judgment as the filter — share moment after "accept" or "looks good"
action, not immediately after generation
Cross-reference with pmm/DOMAIN.md:
The Demo ≠ Product fallacy applies here: if what goes viral is cherry-picked peak
performance, arriving users experience the gap between the viral output and typical
output. This is structural churn.
Output format
## AI Output Virality Design
**Product:** [Name]
**Output type:** [Images / Apps / Code / Writing / Data / Conversations]
**Current organic growth rate:** [% MoM or "unknown"]
**Current sharing behavior:** [Spontaneous / Designed / None observed]
### Virality type diagnosis
Primary natural virality type: [Output / Workflow / Capability surprise]
Types requiring active design: [List]
### Share moment assessment
Current placement: [Immediately after generation / After acceptance / After milestone / None]
Recommended placement: [Specific trigger event]
Friction at current share path: [N taps/clicks — pass/fail against 2-tap standard]
### Output shareability
Visual distinctiveness: [High / Medium / Low]
Effort-to-result ratio: [High / Medium / Low]
Shareable output checklist: [N/4 boxes checked]
Assessment: [High natural virality / Low natural virality — recommend workflow sharing instead]
### Platform fit
| Output type | Recommended destination |
|---|---|
| [Output] | [Platform] |
### Discord flywheel
Applicable (visual output): [Yes / No]
Discord server designed: [Yes / No / Not yet]
#showcase channel: [Exists and seeded / Exists, not seeded / Does not exist]
### Attribution pattern selection
Pattern: [Subtle attribution / Interactive embed / Reproducibility link]
Rationale: [1 sentence]
Forced attribution: [Recommended / Not recommended — reason]
### Virality-trust check
Output typically shared = median quality: [Yes / No — if No, describe the gap]
Share moment quality gate: [Designed / Not designed — recommendation]
Brain reads / writes
If a companion brain repo is connected:
Before starting:
Read knowledge/icp-map.md — ICP determines attribution preference and platform fit (developer ICP resists forced watermarks; creative ICP may embrace them)
Read playbooks/messaging.md — attribution language and "made with X" copy should be consistent with brand voice
Brain not connected: proceed normally.
Anti-patterns
Anti-pattern
Why it fails
Fix
Share moment immediately after output generation
User hasn't evaluated quality yet; bad output gets shared; damages user and product
Place share moment after accept/save action or milestone
Sharing mechanics without trust co-design
Viral growth from low-quality outputs creates structural churn; new users arrive expecting the viral output and get the average
Design quality gate into share moment trigger
Discord without seeding
Empty showcase channel discourages sharing; nothing to emulate
Founding team seeds the channel before launch; this sets the norm
Forcing watermarks on developer tools
Developers perceive it as cheapness; removes the product from professional contexts
Test watermark removal as a paid benefit; never force on developer/professional output
Treating all virality types as interchangeable
Output sharing, workflow sharing, and capability surprise reach different audiences and require different design
Diagnose which type applies; design specifically for it
Measuring share clicks as the virality metric
Shares that don't produce signups are noise; the signal is downstream acquisition from shares
Instrument: share → attributed signup → retained user; optimize for the full chain
Validation criteria
Three virality types assessed; primary type identified for this product
Share moment placement is after acceptance or milestone (not immediately after generation)
Share friction tested (≤2 taps)
Virality-trust check completed (confirm shared outputs represent median quality)
Attribution pattern selected and forced attribution decision made
Discord flywheel evaluated for visual output types
Platform fit matched to specific output type
References & Sources
Tier 2 (operator source — adapted, not authoritative):
ai-output-virality (growth-skills v1.0): three virality types, share moment placement rules, output shareability axes, platform fit by output type, Discord flywheel pattern, attribution pattern taxonomy, virality-at-cost-of-trust trap
