STRATEGY

Pricing and packaging review

Use when tiers have grown by accident and you need a structured view before changing prices.

pricing-and-packaging-review.md

Download .md

You are a pricing strategist. You review structure and logic, not the specific price points, unless the data supports a change.

Current tiers, features and prices: {{CURRENT_PRICING}}
Distribution of customers across tiers: {{TIER_DISTRIBUTION}}
Most common upgrade and downgrade reasons: {{MOVEMENT_REASONS}}
Competitor pricing, if provided: {{COMPETITOR_PRICING}}
What we want pricing to do: {{PRICING_OBJECTIVE}}

Produce:
1. The value metric each tier is currently charging on, inferred from the structure. Say whether it scales with the value the customer receives.
2. A table with columns: Tier | Who it is for | Value metric | The one feature that forces the upgrade | Percentage of customers | Problem with this tier.
3. Packaging problems: features in the wrong tier, tiers nobody buys, and any tier that lets a large customer stay small.
4. Three structural options, each with what improves, what breaks, and who gets upset.
5. The migration question for existing customers under each option.
6. What to test first and how to test it without changing the public price page.

Constraints: do not recommend a specific new price unless the data given supports it; recommend the structure instead. Do not cite willingness to pay research you cannot verify. No em dashes.

Fill in before running

Replace each placeholder with your own detail. The more specific you are, the less the model invents.

{{CURRENT_PRICING}}
{{TIER_DISTRIBUTION}}
{{MOVEMENT_REASONS}}
{{COMPETITOR_PRICING}}
{{PRICING_OBJECTIVE}}

Getting a better result

The upgrade and downgrade reasons matter more than the tier distribution; include verbatim quotes.
Watch for the tier that large customers can sit in forever, which is usually the biggest leak.
Ask separately what breaks operationally under each option before choosing one.

Questions about this prompt

When should I use this rather than putting prices up?

When the tiers grew feature by feature and nobody can say what each one is for. Raising prices on a broken structure raises them on the wrong customers. This reads the value metric each tier charges on and asks whether it scales with the value received, before anyone touches a number.

What pricing data should I bring?

Current tiers with features and prices, how customers are distributed across them, and the common upgrade and downgrade reasons with verbatim quotes. The movement reasons matter more than the distribution, because they say what actually forces an upgrade. Add competitor pricing and a clear objective for what pricing should do.

What comes back, and which finding is usually the leak?

The inferred value metric per tier, a table naming the one feature that forces each upgrade, packaging problems, three structural options with what improves and who gets upset, the migration question for each, and something you can test without changing the public price page. Watch for the tier a large customer can sit in forever.

What is the mistake that gets a pricing review wrong?

Pushing it to name new prices. It recommends structure instead unless your data supports a change, and a price produced without willingness to pay evidence is a guess with a decimal point on it. Ask separately what breaks operationally under each option, because that answer often eliminates the favourite.