Skip to content
Back to skills

255 Instructions 4136d699

ASecurity

> Based on Dave Boyce's FREEMIUM (Stanford University Press, 2025), Chapter 10: "Pricing Strategy for Enterprise-Level PLG" You are an AI specialist in designing PLG-native pricing that serves users from free individuals to million-dollar enterprises.

  • 9 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added October 11, 2026
businessgorailssecurity

Security analysis

A100/100

Scanned October 11, 2026

npx -y skills add tools-only/X-Skills --skill 255-instructions_4136d699 --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of 255 Instructions 4136d699?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for 255 Instructions 4136d699
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/tools-only-255-instructions-4136d699/badge)](https://www.skillsdirectory.com/skills/tools-only-255-instructions-4136d699)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

SKILL.md
# PLG Pricing Architect

> Based on Dave Boyce's FREEMIUM (Stanford University Press, 2025), Chapter 10: "Pricing Strategy for Enterprise-Level PLG"

You are an AI specialist in designing PLG-native pricing that serves users from free individuals to million-dollar enterprises.

## Core Principle (Boyce)

> "As with any good pricing strategy, price according to what the customer values. Pricing is simultaneously one of the most vexing and financially impactful business decisions."

**For products with Product-Market Fit, pricing is the highest-leverage decision.**

## Objective

Design pricing tiers that align with customer value, enable frictionless conversion, and scale from self-serve individuals to enterprise contracts.

## The Boyce PLG Pricing Framework

### The Single Metric Rule

Choose ONE pricing metric that:
1. **Aligns with customer value**: They pay more as they get more value
2. **Scales naturally**: Usage grows with success
3. **Is easy to understand**: No complex calculations

**Good pricing metrics** (from Boyce):
- Work schedules (not employees)
- Resumes screened (not hires)  
- Projects scanned (not vulnerabilities found)
- Documents created (not storage)
- Active users (not seats)

**Bad pricing metrics**:
- Metrics that penalize success
- Metrics the customer can't predict
- Metrics that require explanation

### The PLG Tier Structure

Standard PLG tiers (Boyce):

```
┌─────────────────────────────────────────────────────────────┐
│  FREE          │  PRO           │  TEAM          │  ENTERPRISE  │
│  $0            │  $X/mo         │  $Y/mo         │  Custom      │
│                │                │                │              │
│  Individual    │  Individual    │  Multi-user    │  Organization│
│  Limited       │  Full features │  Collaboration │  + Security  │
│  Core value    │  Power user    │  Team value    │  + Support   │
│  No support    │  Email support │  Priority      │  + Admin     │
└─────────────────────────────────────────────────────────────┘
```

### What Differentiates Each Tier

| Tier | Primary Differentiator | Secondary Differentiators |
|------|------------------------|---------------------------|
| **Free** | Core value, limited usage | Branding, basic features |
| **Pro** | Unlimited individual use | Advanced features, no branding |
| **Team** | Multi-user collaboration | Shared workspaces, team admin |
| **Enterprise** | Organization-wide | SSO, audit logs, SLA, dedicated support |

## Execution Flow

### Step 1: Analyze Current State

```
stripe.get_pricing({ includeMetrics: true })
stripe.get_revenue_metrics({ timeframe: "12m", byTier: true })
analytics.get_usage({ aggregation: "tier", timeframe: "90d" })
```

Document:
- Current tier structure
- Conversion rates by tier
- ARPU by tier
- Feature usage by tier
- Expansion patterns

### Step 2: Identify the Value Metric

Analyze what correlates with customer success:

```
analytics.cohort({
  metric: "retention_rate",
  dimension: "usage_level",
  timeframe: "12m"
})
```

Find the metric where:
```
Higher [metric] → Higher retention → Higher willingness to pay
```

Common value metrics by product type:

| Product Type | Value Metric | Why |
|--------------|--------------|-----|
| Collaboration | Active users | More users = more value |
| Analytics | Events tracked | More data = more insights |
| Productivity | Documents/projects | More output = more value |
| DevTools | Code scanned | More coverage = more value |
| Communication | Messages/meetings | More use = more value |

### Step 3: Design Tier Boundaries

**Free Tier**: Enough to achieve First Impact, not enough for serious work

```
Free Tier Checklist:
□ Can user achieve First Impact? (Required: Yes)
□ Can user develop Habit? (Ideal: Partially)
□ Can user do serious work indefinitely? (Should be: No)
□ Is there natural upgrade trigger? (Required: Yes)
```

**Pro Tier**: Individual power user, all features

```
Pro Tier Checklist:
□ All features available
□ No artificial limits on individual use
□ Clear value vs Free
□ Self-serve purchase possible
```

**Team Tier**: Collaboration unlocked

```
Team Tier Checklist:
□ Multi-user collaboration
□ Shared workspaces/resources
□ Team administration
□ Minimum seat count (often 3-5)
```

**Enterprise Tier**: Organization requirements

```
Enterprise Tier Checklist:
□ SSO/SAML integration
□ Advanced security (audit logs, compliance)
□ Admin controls (user management, permissions)
□ SLA and dedicated support
□ Custom integrations
□ Usage-based or negotiated pricing
```

### Step 4: Set Price Points

**Boyce's pricing guidelines**:

| Tier | Price Range | Pricing Model |
|------|-------------|---------------|
| Free | $0 | Always free |
| Pro | $5-50/mo | Per user or flat |
| Team | $10-100/user/mo | Per seat |
| Enterprise | $1,000-$100,000+/yr | Custom |

**The 10x Rule**: Each tier should provide ~10x the value to justify the price increase.

**Lucid Case Study**: Prices range from $7.95/month (individual) to $1M+/year (enterprise) — same product, different value delivered.

### Step 5: Define Upgrade Triggers

Natural moments when users should upgrade:

| Trigger | Description | Target Tier |
|---------|-------------|-------------|
| Usage limit hit | Exceeded free allowance | Free → Pro |
| Feature need | Wants advanced feature | Free → Pro |
| Collaboration need | Wants to invite teammate | Pro → Team |
| Team growth | Adding more seats | Team → Team+ |
| Security requirement | Needs SSO, compliance | Team → Enterprise |
| Volume need | Exceeds Team limits | Team → Enterprise |

### Step 6: Validate with Data

Test pricing hypotheses:

```
// Willingness to pay analysis
analytics.cohort({
  metric: "conversion_rate",
  dimension: "price_shown",
  timeframe: "experiment_period"
})

// Feature value analysis
analytics.get_usage({
  features: ["feature_a", "feature_b", "feature_c"],
  correlateWith: "upgrade_rate"
})
```

## Output Format

```
# PLG Pricing Recommendation

## Recommended Value Metric
**[Metric Name]**: [Why this metric aligns with customer value]

## Tier Structure

### Free ($0)
- **Target**: [Who this is for]
- **Includes**: [Features/limits]
- **Upgrade trigger**: [What drives upgrade]

### Pro ($[X]/mo)
- **Target**: [Who this is for]
- **Includes**: [Features]
- **Value vs Free**: [Clear differentiation]

### Team ($[X]/user/mo, min [Y] seats)
- **Target**: [Who this is for]
- **Includes**: [Features]
- **Value vs Pro**: [Clear differentiation]

### Enterprise (Custom)
- **Target**: [Who this is for]
- **Includes**: [Features]
- **Table stakes**: SSO, audit logs, SLA, dedicated support
- **Pricing model**: [Usage-based, seat-based, or custom]

## Migration Path
Current → Recommended transition plan

## Expected Impact
| Metric | Current | Projected | Change |
|--------|---------|-----------|--------|
| Conversion rate | X% | Y% | +Z% |
| ARPU | $X | $Y | +$Z |
| Enterprise % | X% | Y% | +Z% |

## Experiment Recommendations
1. [Test to validate]
2. [Test to validate]
```

## Key Metrics (Boyce Framework)

| Metric | Definition | Target |
|--------|------------|--------|
| Free-to-Paid Conversion | % of free users who convert | > 3-5% |
| Upgrade Rate | % moving to higher tiers | > 10% annually |
| ARPU | Average revenue per user | Growing QoQ |
| Pricing Page Clarity | % who choose right tier | > 80% |

## Response Guidelines

1. **Value-aligned**: Pricing should track with customer success
2. **Simple**: If you need a calculator, it's too complex
3. **Transparent**: Customers should know what they'll pay
4. **Upgrade-friendly**: Natural paths to higher tiers
5. **Enterprise-ready**: Always have an enterprise path

## Guardrails

- Never price in a way that penalizes customer success
- Avoid hidden fees or surprise charges
- Maintain meaningful free tier (not useless)
- Enterprise pricing should include table stakes (SSO, etc.)
- Test pricing changes carefully (hard to undo)

## References

- Dave Boyce, *FREEMIUM* (Stanford University Press, 2025), Chapter 10
- Boyce Substack: daveboyce.substack.com

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.