Pricing Experiments Playbook

When a pricing experiment is worth running

Run a pricing experiment only when the team has a specific hypothesis and a way to observe real business impact. The goal is not to “try pricing” in the abstract. The goal is to test whether a visible change can improve revenue, retention, cash flow, or packaging clarity without creating disproportionate support or churn risk.

This guide is most useful when the business already knows the current model is directionally close, but not yet validated enough to ship broad changes blindly. If the real issue is that the tier structure itself feels broken, start with Pricing Tier Design first.

What belongs in this playbook

This page covers three experiment families:

Price increase tests for renewals, new cohorts, or a limited segment.
Annual prepay tests that trade discount for cash flow or commitment.
Packaging tests that move features, limits, or plan boundaries to a different tier.

It does not try to cover every commercial change. If the team is changing the core value metric, redesigning the tier ladder, or reconsidering the entire pricing motion, those are broader design problems, not experiment tactics.

A simple decision sequence

Define the hypothesis in business terms, not just pricing terms.
Choose one customer segment and one primary metric.
Decide which risk you are willing to accept: churn, support load, conversion loss, or delayed revenue.
Set the rollout window long enough to observe the customer behavior that actually matters.
Launch a small cohort first, then expand only if the result is stable.

If the hypothesis cannot survive this sequence, it is probably too vague to test safely.

How to structure the test

Price increase tests

Use price increases when the product already delivers clear value and the team wants to test whether the current price is still too low for the segment. Watch revenue uplift, renewal behavior, and support reaction together. A higher price that looks good on day one but damages retention or creates exception handling is not a healthy result.

Use the Pricing Increase Impact Calculator before launch to check whether the projected revenue gain survives reasonable churn assumptions.

Annual prepay tests

Use annual prepay tests when the business wants to improve cash flow, reduce monthly churn sensitivity, or encourage a longer commitment. The important question is not just whether customers accept the discount. It is whether the discount creates cleaner retention economics and a more stable revenue base.

Use the Annual Discount Calculator to make sure the discount is not so large that it simply trades future margin for temporary conversion.

Packaging tests

Use packaging tests when the experiment is really about plan structure, feature access, or upgrade logic. These tests should move a real customer decision, not just reshuffle labels.

If the experiment is really about how plans progress, compare the test against the broader Pricing Tier Design rules instead of treating it like a pure pricing tweak.

Guardrails that matter

Set guardrails before launch. The most useful ones are usually:

churn or downgrade rate
support ticket volume and severity
conversion rate for the exposed segment
gross profit or revenue per account
time to recover acquisition cost, if the segment is acquisition-sensitive

Do not rely on one headline metric. A good experiment should improve the target outcome without making the rest of the commercial system harder to run.

How to read the results

Treat a test result as a decision input, not a verdict. A clean result means the experiment behaved as expected within the chosen segment and time window. A noisy result usually means one of three things:

the segment was too broad
the test window was too short
the pricing change was too entangled with other changes

Use the Churn Impact Calculator if the observed result is mostly about retention risk. Use the MRR Calculator if you need a cleaner view of revenue effect before deciding on rollout.

Common mistakes

Testing a price change without a stated hypothesis.
Changing price, feature access, and contract terms at the same time.
Using too short a test window to observe renewals or support effects.
Ignoring the support burden created by a “successful” test.
Treating a packaging issue as if it were only a discount problem.

How this page fits the cluster

This guide is the operational page in the cluster. Use it when you want to run the test. Use the surrounding pages when you need to understand the economic inputs behind the test:

CAC for acquisition cost discipline
LTV for long-run gross-profit value
COGS for delivery-cost constraints
Support Costs for service burden
Packaging for plan structure and upgrade logic