ConcertoNotes Make Product Viral
Attribution
This skill is inspired by Marc Lou's "32 Principles of a Viral Product" post on X: https://x.com/marclou/status/2065385672991752210
Marc framed the source ideas as patterns from five years of building startups in public, not as universal rules. Keep that spirit: use the principles as strong defaults, then adapt them to the product, audience, price point, and channel.
Do not copy Marc's original post wholesale into outputs. Attribute the framework when the user asks where the ideas came from or when the output presents this as a named audit method.
Core Lens
A viral product is not just a product with social sharing. It has a simple promise, visible product proof, low cognitive load, a clear buying path, and a memorable reason to talk about it.
Optimize in this order:
- Can people understand it in seconds?
- Can they see or try the product before reading a long explanation?
- Is the desired outcome concrete, emotional, and memorable?
- Is there one obvious next action?
- Is trust visible before the user is asked to pay?
- Is the page easy to share, including its final impression and social preview?
Fast Audit
Use this sequence when reviewing a product, landing page, launch page, pricing page, free tool, app-store surface, or OG/social preview.
1. One Thing
The product should be describable in under 10 words. The page should sell one main outcome, not a bundle of unrelated capabilities.
Check for:
- A specific audience or use case.
- One memorable promise.
- A clear category, alternative, or comparison anchor.
- No hero copy that tries to serve every possible buyer at once.
If the page lacks a sharp one-line description, write that before making lower-level suggestions.
2. Hero That Can Sell Alone
Assume many visitors will not scroll. The first viewport should answer:
- What is this?
- Who is it for?
- What result do I get?
- Why should I believe it?
- What happens if I click?
Prefer concrete outcomes over adjectives. Replace vague claims like "faster" or "better" with numbers, time saved, money made, risk reduced, or pain removed when evidence exists. If evidence does not exist, recommend how to gather it.
3. Show Product Before Explaining
A demo, interactive example, annotated screenshot, calculator, scanner, or short founder walkthrough usually beats paragraphs of copy.
For AI and software products, look for a way to let users experience the payoff on the page before they create an account. If a hard paywall is appropriate, still show enough product proof to create desire and trust.
4. One Screen, One Idea
Each major section should communicate one idea:
- problem
- product proof
- outcome
- social proof
- pricing
- comparison
- objections
- final shareable close
If a section mixes several arguments, split it or cut it until the scan path is obvious.
5. CTA Clarity
Use one primary CTA. The CTA should say what happens next, not a generic action.
Weak patterns:
- Get Started
- Learn More
- Submit
Stronger patterns:
- Analyze My Website
- Generate My Launch Page
- See Pricing
- Buy the Template
- Run the Audit
Only include a secondary CTA when it serves the same buying journey, such as watching a demo or viewing pricing.
6. Pricing And Paywall
For simple indie products, default to clear paid validation over free-user accumulation unless the business model truly depends on a free tier.
Consider:
- Is pricing visible from navigation or early page flow?
- Are there three or fewer choices?
- Is one plan the obvious best fit?
- Could a one-time payment sell better than a subscription?
- Does the product need a tight trial with payment required, especially for app-store-style products?
Do not apply this blindly. SaaS with recurring infrastructure, collaboration, ongoing service delivery, or high expansion value may need subscriptions. Freemium can work when free usage is a distribution channel, proof engine, or network-effect driver.
7. Copy Only This Founder Could Write
Generic copy is easy to ignore and easy to copy. Look for founder experience, specific customer language, sharp opinions, or proof from real use.
Use customer words when available. If customer research is missing, ask for reviews, support tickets, DMs, interviews, beta feedback, or demo-call notes before inventing proof.
8. Trust Before Traffic
Do not send serious launch traffic to a page with no proof.
Minimum proof can include:
- specific beta-user quotes
- founder demo video
- named testimonials
- before-and-after examples
- public build-in-progress evidence
- case-study numbers
- credible comparison against alternatives
If testimonials do not exist, recommend a beta-feedback sprint before a bigger launch.
9. Social Preview As Thumbnail
Treat the OG image like a YouTube thumbnail: it should earn the click without requiring the full page.
Check for:
- one clear message
- strong contrast
- readable text if text is used
- recognizable product, result, or emotion
- no dense screenshot walls
- no tiny UI text that only makes sense after zooming
Marc clarified in the thread that overly text-heavy thumbnails can fail because people will not stop to decode them. If the OG image has a lot of text, ask: "How would this look with roughly 180 characters or less?"
10. Memorable Final Impression
The footer or final section should not feel like a dead end. End with something people can remember or share:
- a strong one-line promise
- a pointed comparison
- a founder note
- a compact demo or result
- a final CTA tied to the product's core action
Output Format
When using this skill, respond with:
- Viral diagnosis: the main reason this is or is not likely to spread.
- Highest-leverage fixes: 3 to 7 changes, ordered by impact.
- Hero rewrite: headline, subhead, CTA, and proof or demo suggestion.
- Shareability pass: OG image, footer or final impression, and one-line description.
- Pricing or paywall note: only if relevant.
- Validation plan: what to check before launch.
Keep recommendations concrete. Prefer replacement copy, section order, product proof, pricing structure, and specific UI/content changes over abstract advice.
Caveats
- Attribute the source when presenting the framework: inspired by Marc Lou's viral product principles.
- Treat the principles as strong defaults, not commandments.
- Avoid fake testimonials, fake scarcity, manipulative claims, or unsupported numbers.
- Strong claims need evidence. If evidence is missing, recommend how to gather it.
- Do not let "viral" override usefulness. A product that spreads but disappoints users creates the wrong kind of attention.