mcpField
P
pricing-strategy

pricing-strategy

github.com/mohitagw15856Marketing & growth1.5k58 installsUpdated 1w ago
Repository

About pricing-strategy

A skill for structuring product pricing recommendations around customer segments, delivered value, pricing models, and competitive context. It is intended for teams deciding or revising pricing and packaging.

Key features

  1. 01Customer and value assessment
  2. 02Pricing model selection
  3. 03Freemium decision framework
  4. 04Three-tier packaging guidance
  5. 05Competitive positioning and rollout planning

Use cases

  1. 01Choosing a model for a SaaS product
  2. 02Comparing freemium with paid access
  3. 03Designing customer tiers and upgrade triggers
  4. 04Planning a pricing change

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/mohitagw15856/pm-claude-skills --skill pricing-strategy

After installing, type/pricing-strategyin Claude Code to confirm it loaded.

Bundled filesreferences/model-selection.md

Details

From the project README

Pricing Strategy Skill

Build pricing that reflects value delivered — not cost to build. Structure every pricing decision with customer segmentation, value metric identification, competitive context, and a packaging recommendation.

Pricing Foundations

Three questions to answer before any pricing decision:

  1. Who is our buyer? (Role, company size, willingness to pay)
  2. What value do we deliver? (Quantifiable outcome — time saved, revenue generated, risk reduced)
  3. What is our pricing model? (Per seat, usage-based, flat, hybrid)

Pricing Models

ModelBest ForRisk
Per SeatCollaboration tools, team softwareDisincentivises adoption as team grows
Usage-BasedAPIs, infrastructure, consumption toolsRevenue unpredictability for both sides
Flat RateSimple tools, early-stageLeaves money on table from power users
TieredProducts with clear user segmentsFeature gatekeeping frustrates users
FreemiumViral/PLG products with low marginal costConversion to paid is hard to engineer
Value-BasedEnterprise, outcomes-driven productsRequires strong ROI story

Freemium Decision Framework

Use freemium when:

  • ✅ Marginal cost per free user is near zero
  • ✅ Product is inherently viral (network effects or sharing)
  • ✅ Free tier creates genuine value (not just a demo)
  • ✅ Clear upgrade trigger exists (feature, volume, or team size)
  • ✅ Conversion benchmark is realistic (2–5% free-to-paid is typical)

Avoid freemium when:

  • ❌ Support cost per free user is high
  • ❌ No natural upgrade trigger in the product
  • ❌ Core value requires features you'd need to gate

Packaging / Tiering Framework

Recommended 3-tier structure for SaaS:

TierTargetPrice SignalKey FeaturesLock-in Mechanism
Free / StarterIndividual, early discovery$0Core value, usage-limitedInvite colleagues, export limit
Pro / GrowthSMB, growing teams$[X]/seat/moFull features, higher limitsTeam collaboration, integrations
Business / EnterpriseMid-market, enterprise$[X]/seat/mo or customAdmin, SSO, SLAs, dedicated supportSecurity, compliance, volume

Tier design rules:

  • Each tier should be genuinely sufficient for its target segment
  • The upgrade trigger should be felt naturally — not manufactured
  • Price jumps of 3–5x between tiers are normal and defensible

Competitive Pricing Context

CompetitorModelPriceKey Differentiator
[Name][Model][Price][What they lead with]

Positioning options:

  • Premium: Price 20–40% above market. Justify with enterprise features, support, or brand.
  • Parity: Match the market leader. Win on product or distribution.
  • Value: Price below market. Win on volume. Dangerous without strong unit economics.

Output Format

Pricing Strategy Recommendation — [Product] — [Date]

Current State: [What pricing exists today, if any] Problem to Solve: [Why pricing is being reviewed]

Recommended Pricing Model: [Model name + rationale]

Value Metric: [The single unit that scales with customer value — e.g., "active users", "API calls", "documents processed"]

Proposed Tiers:

[Table using 3-tier structure above]

Free-to-Paid Upgrade Trigger: [Specific moment or threshold that creates natural upgrade pressure]

Competitive Position: [Premium / Parity / Value + reasoning]

Pricing Change Rollout (if applicable):

  • Grandfathering: [Yes / No — recommendation and rationale]
  • Communication plan: [How to tell customers + timing]
  • Rollback plan: [Under what conditions you'd revert]

Risks:

  • [Risk] → Mitigation: [Action]

Metrics to Monitor Post-Change:

  • Conversion rate (free to paid)
  • Churn rate by tier
  • Average revenue per user (ARPU)
  • Expansion revenue

Required Inputs

Work from what is given. If any of these is missing, still produce the complete output: fill each gap with a reasonable assumption marked (assumed, confirm) and list those assumptions at the end. Ask a question first only when the core subject itself is missing (there is nothing to write about).

  • Product or service being priced
  • Current pricing (if any — and why it's being reviewed)
  • Target customer segments (size, role, willingness to pay)
  • Key competitors and their pricing (if known)
  • Business model (SaaS / Marketplace / Usage-based / Other)
  • Primary goal (grow adoption / increase ARPU / reduce churn / new market entry)

Deeper Materials

Quality Checks

  • Value metric is defined (the unit that scales with customer value)
  • Free-to-paid upgrade trigger is specific (not "when they need more")
  • Competitive positioning is chosen and justified (premium / parity / value)
  • Pricing change rollout plan includes grandfathering decision
  • Counter-metrics are defined to catch perverse incentives
  • Risks have specific mitigations (not just listed)

Anti-Patterns

  • Do not base pricing solely on cost-plus — pricing must reflect value delivered to the customer
  • Do not design tiers where the middle tier is clearly worse value — it undermines trust and pushes customers to extremes
  • Do not change pricing without a migration plan for existing customers — surprise price changes cause churn
  • Do not set enterprise pricing as "contact us" without a floor — it deters self-serve evaluation and qualification
  • Do not skip competitive positioning — pricing in isolation from the market is incomplete strategy

Guidelines

  • Never price based on cost — price based on value delivered to the customer
  • Always A/B test price changes where possible; use geographic holdouts if A/B isn't feasible
  • Recommend annual pricing with 15–20% discount — improves cash flow and reduces churn
  • If enterprise pricing is "contact us", recommend adding a price floor to qualify inbound

Example Trigger Phrases

  • "Set pricing."
  • "Design pricing tiers."
  • "Evaluate freemium vs paid."
  • "Prepare a pricing change."

Comments

Markdown supported