Pricing Review

You are helping the user evaluate or redesign their pricing model. Pricing is strategy made visible — it signals positioning, affects who buys, and determines who stays.

Framework: Lenny Rachitsky (AI feature monetization data), Palle Broe (How should you monetize your AI features), Patrick Campbell (value-based pricing), April Dunford (positioning-informed pricing).

Key insight from Palle Broe's analysis of 44 tech incumbents: 59% bundle AI features in existing packages; 23% offer as an add-on; 18% build standalone AI products. For products with clear customer value and high variable costs, direct monetization is best.

Step 1 — Load Context

Read

memory/user-profile.md

for product stage, business model, and current bets. Read

context/company/competitors.md

for competitive pricing context.

Step 2 — Pricing Model Selection

Evaluate which model fits:

Flat subscription: Simple, predictable revenue; good when value doesn't vary much by usage. Best for: Tools used at a consistent rate; B2C or SMB.

Usage-based / metered: Price scales with value delivered; aligns costs with revenue. Best for: AI-powered features with significant per-use costs (API calls, compute); enterprise customers with variable volume.

Tier-based (Good/Better/Best): Multiple tiers; works well when value delivered varies significantly by customer segment. Best for: When you have distinct ICP segments with different willingness to pay and different feature needs.

Freemium: Free tier drives adoption; paid tier captures value for power users. Best for: When the free tier has a real viral or word-of-mouth effect; when converting 2–5% of free users to paid is sufficient.

Per-seat: Simple, scales with team size. Best for: Collaboration tools; B2B where value scales with the number of users.

Step 3 — Value Metric Identification

The value metric is what you charge for — the thing that scales as customers get more value.

Good value metrics:

• Are easy for customers to understand
• Scale as customer value scales (power users pay more)
• Are easy for you to track and enforce

Poor value metrics:

• Don't connect to value (e.g., charging per API call when users care about the quality of outputs)
• Create friction that reduces adoption (e.g., per-seat pricing for a tool that needs wide adoption to work)
• Are gamed by customers (e.g., sharing one account)

Step 4 — Willingness to Pay Analysis

Estimate willingness to pay for the ICP:

Van Westendorp price sensitivity meter: Ask (or infer from context):

• At what price is the product too cheap? (Makes them doubt quality)
• At what price is it a great deal?
• At what price is it starting to feel expensive but worth it?
• At what price is it too expensive?

The acceptable price range is between "too cheap" and "too expensive" responses.

Competitive anchoring: What do alternatives cost? How does our product's value compare? If we're 10x more valuable, we shouldn't be 10x more expensive — but we shouldn't be the same price as an inferior alternative.

Step 5 — Freemium Assessment

If evaluating freemium:

The freemium test: Is the free tier genuinely useful enough to drive adoption, but limited enough to justify upgrading?

Common freemium mistakes:

• Too generous: users get everything they need for free and never upgrade
• Too restrictive: users can't see enough value to know they should upgrade
• Wrong limit: the limit is on the wrong dimension (limiting features vs. limiting usage vs. limiting output quality)

For PM Copilot specifically (as a reference model):

• Free: 20 core skills, 2 commands, no memory persistence → shows quality, creates need to upgrade for memory
• Solo: Full skill library, all 4 commands, full memory layer → the natural upgrade when the user wants memory to persist
• Pro: All MCP connectors, proactive check-ins, gossip mode → for power users who want the full experience

Step 6 — Output

Produce:

• Pricing model recommendation with rationale
• Value metric identification
• Tier design (if applicable) with what's in each tier and why
• Price point recommendations with willingness to pay rationale
• Competitive pricing context
• One pricing assumption to validate: "We're assuming [X] — here's how to test it"