/pricing
Design a pricing strategy — models, competitive analysis, willingness-to-pay estimation, and pricing experiments
$ npx -y skills add phuryn/pm-skills --agent claude-codeHow it fires
How this command gets triggered: by you, by Claude, or both.
- Fires itselfClaude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/pricing
Context preview
What this command does when you run it.
Design a pricing strategy — models, competitive analysis, willingness-to-pay estimation, and pricing experiments
Command definition
pricing.mddescription: Design a pricing strategy — models, competitive analysis, willingness-to-pay estimation, and pricing experiments
argument-hint: "<product or pricing question>"
/pricing -- Pricing Strategy Design
Build a pricing strategy from first principles: analyze pricing models, estimate willingness to pay, benchmark against competitors, and design pricing experiments.
Invocation
/pricing SaaS project management tool moving from free to paid
/pricing Should we switch from per-seat to usage-based pricing?
/pricing [upload competitor pricing pages or current pricing data]
Workflow
Step 1: Understand the Pricing Context
Ask:
- What is the product? What value does it deliver?
- Current pricing (if any): model, price points, packaging
- What's the trigger? (new product, pricing change, competitive pressure, growth stall)
- Target customer profile and their budget context
- Any constraints? (contractual obligations, market expectations, competitive positioning)
Step 2: Analyze Pricing Models
Apply the **pricing-strategy** and **monetization-strategy** skills:
Evaluate applicable models:
- **Flat-rate**: Simple, predictable — best for commoditized products
- **Per-seat/user**: Scales with adoption — best for collaboration tools
- **Usage-based**: Aligns cost with value — best for infrastructure and API products
- **Tiered**: Captures different willingness to pay — best for segmented markets
- **Freemium**: Drives adoption — best for products with network effects
- **Hybrid**: Combines models — best for complex products with multiple value levers
For each relevant model: pros, cons, fit for your product, revenue projection approach.
Step 3: Competitive Pricing Analysis
Using web research:
- Benchmark pricing against 3-5 competitors
- Identify pricing model patterns in the category
- Note pricing trends (e.g., shift from per-seat to usage-based in B2B SaaS)
- Find pricing page screenshots and data points
Step 4: Willingness to Pay Estimation
If the user has survey data or customer feedback:
- Apply Van Westendorp analysis (if data available)
- Segment willingness to pay by user type
If no data:
- Estimate based on value delivered, competitive anchoring, and market norms
- Design a willingness-to-pay survey the user can run
Step 5: Generate Pricing Recommendation
## Pricing Strategy: [Product]
**Date**: [today]
**Current pricing**: [if applicable]
### Recommended Model: [Model Name]
**Why this model**: [rationale tied to product value delivery]
### Pricing Structure
| Tier | Price | Includes | Target Segment | Key Limit |
|------|-------|---------|---------------|-----------|
### Free / Trial Strategy
[What's free, what's gated, conversion triggers]
### Competitive Benchmark
| Competitor | Model | Price Range | Positioning |
|-----------|-------|-----------|------------|
### Revenue Projections
| Scenario | Assumptions | Year 1 ARR | Year 2 ARR |
|----------|-----------|-----------|-----------|
| Conservative | [X] | [Y] | [Z] |
| Expected | [X] | [Y] | [Z] |
| Optimistic | [X] | [Y] | [Z] |
### Migration Plan
[If changing pricing: how to transition existing customers]
- Grandfathering approach
- Communication plan
- Timeline
### Pricing Experiments
| Experiment | What We're Testing | Method | Duration |
|-----------|-------------------|--------|----------|
### Risks and Mitigations
| Risk | Likelihood | Impact | Mitigation |
|------|-----------|--------|-----------|
### Key Metrics to Track
- Conversion rate by tier
- Average revenue per user (ARPU)
- Upgrade/downgrade rates
- Churn by price sensitivity
- Price elasticity signals
Save as markdown.
Step 6: Offer Next Steps
- "Want me to **create a monetization strategy** with alternative revenue models?"
- "Should I **run a market scan** to validate pricing assumptions?"
- "Want me to **draft customer communication** for the pricing change?"
- "Should I **design the A/B test** for pricing experiments?"
Notes
- Pricing is the most powerful lever for revenue growth — a 1% improvement in pricing typically has 3-4x the impact of 1% improvement in customer acquisition
- Value-based pricing always beats cost-plus — start from customer value, not your costs
- The best pricing is simple to understand and predictable for the customer
- Freemium only works if free users generate value (network effects, word of mouth, marketplace liquidity)
- Always design a migration path for existing customers — pricing changes that alienate your base destroy trust
Read more
description: Design a pricing strategy — models, competitive analysis, willingness-to-pay estimation, and pricing experiments argument-hint: "<product or pricing question>"
/pricing -- Pricing Strategy Design
Build a pricing strategy from first principles: analyze pricing models, estimate willingness to pay, benchmark against competitors, and design pricing experiments.
Invocation
/pricing SaaS project management tool moving from free to paid /pricing Should we switch from per-seat to usage-based pricing? /pricing [upload competitor pricing pages or current pricing data]
Workflow
Step 1: Understand the Pricing Context
Ask:
- What is the product? What value does it deliver?
- Current pricing (if any): model, price points, packaging
- What's the trigger? (new product, pricing change, competitive pressure, growth stall)
- Target customer profile and their budget context
- Any constraints? (contractual obligations, market expectations, competitive positioning)
Step 2: Analyze Pricing Models
Apply the **pricing-strategy** and **monetization-strategy** skills:
Evaluate applicable models:
- **Flat-rate**: Simple, predictable — best for commoditized products
- **Per-seat/user**: Scales with adoption — best for collaboration tools
- **Usage-based**: Aligns cost with value — best for infrastructure and API products
- **Tiered**: Captures different willingness to pay — best for segmented markets
- **Freemium**: Drives adoption — best for products with network effects
- **Hybrid**: Combines models — best for complex products with multiple value levers
For each relevant model: pros, cons, fit for your product, revenue projection approach.
Step 3: Competitive Pricing Analysis
Using web research:
- Benchmark pricing against 3-5 competitors
- Identify pricing model patterns in the category
- Note pricing trends (e.g., shift from per-seat to usage-based in B2B SaaS)
- Find pricing page screenshots and data points
Step 4: Willingness to Pay Estimation
If the user has survey data or customer feedback:
- Apply Van Westendorp analysis (if data available)
- Segment willingness to pay by user type
If no data:
- Estimate based on value delivered, competitive anchoring, and market norms
- Design a willingness-to-pay survey the user can run
Step 5: Generate Pricing Recommendation
## Pricing Strategy: [Product] **Date**: [today] **Current pricing**: [if applicable] ### Recommended Model: [Model Name] **Why this model**: [rationale tied to product value delivery] ### Pricing Structure | Tier | Price | Includes | Target Segment | Key Limit | |------|-------|---------|---------------|-----------| ### Free / Trial Strategy [What's free, what's gated, conversion triggers] ### Competitive Benchmark | Competitor | Model | Price Range | Positioning | |-----------|-------|-----------|------------| ### Revenue Projections | Scenario | Assumptions | Year 1 ARR | Year 2 ARR | |----------|-----------|-----------|-----------| | Conservative | [X] | [Y] | [Z] | | Expected | [X] | [Y] | [Z] | | Optimistic | [X] | [Y] | [Z] | ### Migration Plan [If changing pricing: how to transition existing customers] - Grandfathering approach - Communication plan - Timeline ### Pricing Experiments | Experiment | What We're Testing | Method | Duration | |-----------|-------------------|--------|----------| ### Risks and Mitigations | Risk | Likelihood | Impact | Mitigation | |------|-----------|--------|-----------| ### Key Metrics to Track - Conversion rate by tier - Average revenue per user (ARPU) - Upgrade/downgrade rates - Churn by price sensitivity - Price elasticity signals
Save as markdown.
Step 6: Offer Next Steps
- "Want me to **create a monetization strategy** with alternative revenue models?"
- "Should I **run a market scan** to validate pricing assumptions?"
- "Want me to **draft customer communication** for the pricing change?"
- "Should I **design the A/B test** for pricing experiments?"
Notes
- Pricing is the most powerful lever for revenue growth — a 1% improvement in pricing typically has 3-4x the impact of 1% improvement in customer acquisition
- Value-based pricing always beats cost-plus — start from customer value, not your costs
- The best pricing is simple to understand and predictable for the customer
- Freemium only works if free users generate value (network effects, word of mouth, marketplace liquidity)
- Always design a migration path for existing customers — pricing changes that alienate your base destroy trust
68 PM skills and 42 chained workflows across 9 plugins. Claude Code, Cowork, and more. From discovery to strategy, execution, launch, growth, and shipping AI-built code. Designed for Claude Code and Cowork. Skills compatible with other AI assistants.
Repo: phuryn/pm-skills
Other commands on pm-skills.
- /derive-tests
Turn documented intent into a test-coverage map — inventory the tests that exist today, derive use-case cases from the system docs, separate existing coverage from proposed tests and unverified gaps, mark each unit / guarded-live / manual, and recommend a green-before-merge CI
Open command - /document-app
Reverse-engineer an AI-built codebase into the system documents reviewers and auditors need — a core set (architecture, flows, permissions, variables) plus conditional docs (emails, cron, SEO, automation) when they apply
Open command - /performance-audit-static
Static performance audit of AI-built code — find N+1 queries and request waterfalls, over-fetching, missing indexes, and caching opportunities, ranked by effort and impact
Open command - /security-audit-static
Static security audit of AI-built code — map trust boundaries, cross-reference documented intent, self-refute every finding, and report only evidence-backed risks
Open command - /ship-check
Turn a vibe-coded repo into a reviewer-ready shipping packet — document the app, wire agent context, run security and performance audits, map test coverage, and compile the results
Open command - /analyze-cohorts
Perform cohort analysis on user data — retention curves, feature adoption, and engagement trends
Open command

