agentleFS
mia-pppmia-ppp/PMM-Skills/skills/upgrade-conversion/SKILL.md

upgrade-conversion

Skill2 starsChanged 28 days agoMITView on GitHub

When the user wants to create or optimize in-app paywalls, upgrade screens, upsell modals, or feature gates. Also use when the user mentions "paywall," "upgrade screen," "upgrade modal," "upsell," "feature gate," "convert free to paid," "freemium conversion," "trial expiration screen," "limit reached screen," "plan upgrade prompt," "in-app pricing," "free users won't upgrade," "trial to paid conversion," or "how do I get users to pay." Use this for any in-product moment where you're asking users to upgrade. Distinct from public pricing pages (see acquisition-conversion). This focuses on in-product upgrade moments where the user has already experienced value. For pricing decisions, see pricing-strategy.

The file

Show its rules and text

We split this skill into the rules it gives an agent

20 rules. About 0 are common, 17 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈17

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use the company SSOT when present: follow ../_shared/ssot-consumption.md and the project manifest to load only relevant approved context.

    line 11
  2. Distinctive:

    Do not invent discounts or repackage plans.

    line 19
  3. Very specific:

    Load the evidence labels: read ../_shared/evidence-gaps.md (relative to this skill's folder) and follow it.

    line 25
  4. Very specific:

    If .agents/product-marketing-context.md exists (or .claude/product-marketing-context.md in older setups), read it before asking questions.

    line 28
  5. Distinctive:

    Before providing recommendations, understand:

    line 30
  6. Distinctive:

    User Journey: - When does this appear? What have they experienced?

    line 36
  7. Distinctive:

    Don't make them hunt for pricing

    line 54
  8. Distinctive:

    Don't trap or pressure

    line 57
  9. Distinctive:

    When user clicks a paid-only feature:

    line 66
  10. Distinctive:

    When user hits a limit:

    line 73
  11. Distinctive:

    Don't block abruptly

    line 76
  12. Distinctive:

    When trial is ending:

    line 79
  13. Distinctive:

    After X days of free use:

    line 85
  14. Distinctive:

    After value moment, before frustration

    line 158
  15. Distinctive:

    After activation/aha moment

    line 159
  16. Distinctive:

    When hitting genuine limits

    line 160
  17. Distinctive:

    When they're in a flow

    line 164
  18. Distinctive:

    Keep in-context if possible

    line 178
  19. Distinctive:

    No em dashes in output.

    line 237
  20. Distinctive:

    Keep any short summary or open-questions list separate from the Evidence gaps lists.

    line 241

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Upgrade Conversion

Use the company SSOT when present: follow ../_shared/ssot-consumption.md and the project manifest to load only relevant approved context. Preserve covered strategic meaning while keeping this skill’s existing scope and frameworks.

You are an expert in in-app paywalls and upgrade flows. Your goal is to convert free users to paid, or upgrade users to higher tiers, at moments when they've experienced enough value to justify the commitment.

PMM upgrade responsibility

Own upgrade eligibility, timing, value communication and trial/free-to-paid conversion briefs. Consume accepted go-to-market-strategy and approved pricing-strategy; pricing retains price, packaging, entitlements and commercial policy. Do not invent discounts or repackage plans. Product/Design own in-product implementation; billing/access operations remain external. Measure retained value and conversion quality alongside immediate upgrades.

Initial Assessment

Load the evidence labels: read ../_shared/evidence-gaps.md (relative to this skill's folder) and follow it. Label every claim, benchmark, and number Sourced, Assumed, or Gap. Never drop an item because proof is missing: label it and name how to get the proof.

Check for product marketing context first: If .agents/product-marketing-context.md exists (or .claude/product-marketing-context.md in older setups), read it before asking questions. Use that context and only ask for information not already covered or specific to this task.

Before providing recommendations, understand:

  1. Upgrade Context - Freemium → Paid? Trial → Paid? Tier upgrade? Feature upsell? Usage limit?
  2. Product Model - What's free? What's behind paywall? What triggers prompts? Current conversion rate?
  3. User Journey - When does this appear? What have they experienced? What are they trying to do?

Core Principles

1. Value Before Ask

  • User should have experienced real value first
  • Upgrade should feel like natural next step
  • Timing: After "aha moment," not before

2. Show, Don't Just Tell

  • Demonstrate the value of paid features
  • Preview what they're missing
  • Make the upgrade feel tangible

3. Friction-Free Path

  • Easy to upgrade when ready
  • Don't make them hunt for pricing

4. Respect the No

  • Don't trap or pressure
  • Make it easy to continue free
  • Maintain trust for future conversion

Paywall Trigger Points

Feature Gates

When user clicks a paid-only feature:

  • Clear explanation of why it's paid
  • Show what the feature does
  • Quick path to unlock
  • Option to continue without

Usage Limits

When user hits a limit:

  • Clear indication of limit reached
  • Show what upgrading provides
  • Don't block abruptly

Trial Expiration

When trial is ending:

  • Early warnings (7, 3, 1 day)
  • Clear "what happens" on expiration
  • Summarize value received

Time-Based Prompts

After X days of free use:

  • Gentle upgrade reminder
  • Highlight unused paid features
  • Easy to dismiss

Paywall Screen Components

  1. Headline - Focus on what they get: "Unlock [Feature] to [Benefit]"
  2. Value Demonstration - Preview, before/after, "With Pro you could..."
  3. Feature Comparison - Highlight key differences, current plan marked
  4. Pricing - Clear, simple, annual vs. monthly options
  5. Social Proof - Customer quotes, "X teams use this"
  6. CTA - Specific and value-oriented: "Start Getting [Benefit]"
  7. Escape Hatch - Clear "Not now" or "Continue with Free"

Specific Paywall Types

Feature Lock Paywall

[Lock Icon]
This feature is available on Pro

[Feature preview/screenshot]

[Feature name] helps you [benefit]:
• [Capability]
• [Capability]

[Upgrade to Pro - $X/mo]
[Maybe Later]

Usage Limit Paywall

You've reached your free limit

[Progress bar at 100%]

Free: 3 projects | Pro: Unlimited

[Upgrade to Pro]  [Delete a project]

Trial Expiration Paywall

Your trial ends in 3 days

What you'll lose:
• [Feature used]
• [Data created]

What you've accomplished:
• Created X projects

[Continue with Pro]
[Remind me later]  [Downgrade]

Timing and Frequency

When to Show

  • After value moment, before frustration
  • After activation/aha moment
  • When hitting genuine limits

When NOT to Show

  • During onboarding (too early)
  • When they're in a flow
  • Repeatedly after dismissal

Frequency Rules

  • Limit per session
  • Cool-down after dismiss (days, not hours)
  • Track annoyance signals

Upgrade Flow Optimization

From Paywall to Payment

  • Minimize steps
  • Keep in-context if possible
  • Pre-fill known information

Post-Upgrade

  • Immediate access to features
  • Confirmation and receipt
  • Guide to new features

A/B Testing

What to Test

  • Trigger timing
  • Headline/copy variations
  • Price presentation
  • Trial length
  • Feature emphasis
  • Design/layout

Metrics to Track

  • Paywall impression rate
  • Click-through to upgrade
  • Completion rate
  • Revenue per user
  • Churn rate post-upgrade

For comprehensive experiment ideas: See references/experiments.md


Anti-Patterns to Avoid

Dark Patterns

  • Hiding the close button
  • Confusing plan selection
  • Guilt-trip copy

Conversion Killers

  • Asking before value delivered
  • Too frequent prompts
  • Blocking critical flows
  • Complicated upgrade process

Task-Specific Questions

  1. What's your current free → paid conversion rate?
  2. What triggers upgrade prompts today?
  3. What features are behind the paywall?
  4. What's your "aha moment" for users?
  5. What pricing model? (per seat, usage, flat)
  6. Mobile app, web app, or both?

Output Rules

  • No em dashes in output.
  • Open with the "Inputs and assumptions" note from ../_shared/evidence-gaps.md.
  • Label every claim, benchmark, and number Sourced, Assumed, or Gap.
  • End with the Evidence gaps section: the top five in the body, the rest in an appendix.
  • Keep any short summary or open-questions list separate from the Evidence gaps lists.

Related Skills

  • customer-marketing: For cancel flows, save offers, and reducing churn post-upgrade
  • acquisition-conversion: For public pricing page optimization
  • product-activation: For driving to aha moment before upgrade
  • marketing-experimentation: For testing paywall variations

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.