Run a pricing experiment without breaking trust

A 10-step playbook. Open in Dock and you'll get four surfaces seeded:

- **Cohorts** (table) — control vs treatment cohorts with conversion + churn + LTV metrics
- **Brief** (doc) — the hypothesis, the math, the grandfathering policy, the decision log
- **Comms** (table) — every customer-facing message: banners, emails, FAQs, by audience
- **Pointers** (table) — pricing research methodologies + sample comms templates

Read `Brief` top-to-bottom on first open. Decide the grandfathering policy in step 2 — it's the single most important decision in the whole experiment.

Outcome

A pricing experiment with a control + treatment cohort, statistically valid sample, grandfathered existing customers, and a defensible decision documented for the team. Either: a price increase that ships without churn, or a clear signal that the change isn't worth it.

Estimated time: 4-8 weeks (most of it is waiting on conversion + churn data)
Difficulty: advanced
For: Founders + monetization leads at $100K-$10M ARR.

What you'll need

Pre-register or install before you start.

• Stripe (2.9% + $0.30 per transaction) — Source of truth for pricing + subscriptions. Multi-price products live here.
• ProfitWell / Paddle (Free for ProfitWell metrics) — Subscription analytics: MRR, churn, LTV. Free price-intelligence reports.
• PostHog (Free tier (1M events/mo)) — Run the price page A/B test + cohort analysis on conversion + retention.
• Van Westendorp Price Sensitivity Meter (Free (run via Typeform / Tally / SurveyMonkey)) — Survey methodology: 4 questions to bound the acceptable price range.
• Reforge pricing course ($2K per program) — Reference: their pricing program is the strongest material on this.
• Patrick Campbell's pricing newsletter (Free) — Free weekly pricing insights with real SaaS data.

---

The template · 9 steps

Step 1: Diagnose: are you actually underpriced (or overpriced)?

Estimated time: 1-2 days

Most founders feel underpriced for the wrong reasons (one customer asked for a discount, a competitor raised prices, a board member mentioned it). The right diagnosis comes from data. Three signals of underpricing: <2% of customers ever push back on price, expansion revenue is dominated by usage growth not plan upgrades, prospects sign without negotiation. Three signals of overpricing: >20% of qualified leads bounce on the pricing page, conversion gap between trial-to-paid + trial-to-churn is wide, win/loss notes mention price often.

Tasks

• Pull pricing-page bounce rate (% of pricing visitors who leave without converting)
• Pull % of customers who pushed back on price during sales conversations (review CRM notes)
• Pull win/loss reasons from the last 30 lost deals — was price cited?
• Pull NPS / satisfaction by plan tier — is the highest tier not the happiest?
• Run a Van Westendorp survey on 50-200 customers (4 questions, 5 min)
• Decide: are you underpriced, overpriced, or correctly priced but with the wrong tier structure

Pointers

• [Guide] Van Westendorp methodology
• [Guide] Pricing diagnosis checklist (ProfitWell)

[!CAUTION] Gotchas

• If <2% of customers ever push back on price, you're definitely underpriced — but the fix might be tier structure, not list price.
• Van Westendorp surveys with <50 responses are noisy. Don't decide off N=20.
• Anchoring effects in surveys — putting your current price as the reference point biases responses. Use ranges.

Step 2: Decide the grandfathering policy BEFORE you decide the new price

Estimated time: 2-3 hr

Grandfathering means: existing customers keep their current price (forever, or for 12 months, or for the life of the contract). The grandfathering decision shapes the entire experiment + comms strategy. Default for SaaS: grandfather existing customers indefinitely on their current plan. Exceptions are rare and require strong justification (existing customer pricing was unsustainable / one-off discount that wasn't documented as permanent).

Tasks

• Pick policy: indefinite grandfather / 12-month grandfather / no grandfather (rare)
• If grandfathering: document exactly which customers are grandfathered (signup before date X, plan tier Y, etc.)
• If 12-month grandfather: document the migration path + comms cadence
• If no grandfather: prepare for 5-15% churn from existing customers and a backlash cycle. Make sure the math justifies it.
• Document the policy in the Brief with reasoning

[!CAUTION] Gotchas

• Raising prices on existing customers without grandfathering torches trust faster than any other change you can make. Default to indefinite grandfather.
• 12-month grandfather + clear comms is the middle path: existing customers get a year, new customers pay the new price.
• If you've already burned existing customers with surprise price changes once, the second one is 2-3x worse. Be conservative.

Step 3: Pick the experiment shape: A/B price test, gradual rollout, or full rollout

Estimated time: 2-3 hr

Three experiment shapes. (1) A/B price test on the pricing page — randomize new visitors to old vs new price, measure conversion + early retention. Cleanest data, requires traffic. (2) Gradual rollout by signup date — new customers from date X see new price, prior customers grandfathered. No clean A/B but no test infrastructure needed. (3) Full rollout — everyone sees new price. Highest risk, fastest signal. Pick based on your traffic + risk tolerance.

Tasks

• Audit traffic: how many new signups/month? (A/B needs 500+ to converge in reasonable time)
• Audit risk tolerance: what % churn would be unacceptable?
• If traffic >500/mo + price change is large (+30%+): A/B test
• If traffic <500/mo + grandfathering is locked: gradual rollout
• Full rollout only if confident from prior data + change is small (<10%)
• Document the chosen shape in the Brief

[!CAUTION] Gotchas

• A/B price tests look clean but are forbidden in some jurisdictions (UK price-discrimination rules apply in some sectors). Consult counsel if customer base is global.
• Showing different prices to different visitors who can talk to each other (B2B teams, public communities) leaks fast. Limit the test window or risk Twitter incident.
• Full rollout 'just to see' is how teams break trust. The experiment exists to make the rollout safer, not to skip it.

Step 4: Compute the math: incremental revenue vs churn risk

Estimated time: 3-4 hr

Don't run the experiment until you've modeled the math. Inputs: current conversion rate, current LTV, hypothesized new conversion rate (lower at higher price), hypothesized new LTV (higher because higher MRR per customer). Output: at what conversion-rate drop does the new price equal the old price's revenue per visitor? If you can tolerate a 30% conversion drop and break even on revenue, the experiment is low-risk. If a 5% drop takes you under, it's high-risk.

Tasks

• Model 3 scenarios: optimistic, expected, pessimistic conversion change
• Compute breakeven: at what conversion drop does new revenue per visitor = old revenue per visitor?
• Model long-tail effects: if churn rises 1-2% on the new price, what's the revenue impact at 12 months?
• Compute the floor: minimum sample size to detect a 10% conversion difference at 95% confidence
• Document all of it in the Brief — math is the audit trail when results come in

Pointers

• [Tool] Sample size calculator (PostHog)
• [Guide] Pricing math worksheet (First Round)

[!CAUTION] Gotchas

• Modeling only conversion ignores churn. Higher prices often slightly raise churn (e.g. 1-2% additional monthly churn). Include it.
• Breakeven margins under 5% conversion drop mean the experiment is high-risk — small changes look big in noisy data.
• If the math says you need 5000 visitors per arm at your traffic of 100/month, the experiment will take a year. Either get more traffic or simplify the test.

Agent prompt for this step

Model the pricing experiment math.

Read the Brief for current pricing + conversion + LTV.

Output:
1. A scenario table with 3 columns: Optimistic / Expected / Pessimistic conversion change
2. For each: revenue per visitor, monthly revenue impact, breakeven conversion drop
3. Long-tail effect at 12 months including churn assumptions
4. Minimum sample size for 95% confidence on a 10% conversion delta
5. A risk flag if breakeven is under 10% conversion drop (very tight margin)

Constraints:
- Use the actual current conversion rate + LTV from the brief, don't invent numbers
- Show the math, don't just give the answer
- Flag any scenario where breakeven is under 5% drop — that's a red flag the price change is too small to be worth the experiment risk

Step 5: Set up the technical experiment cleanly

Estimated time: 1-2 days

Implementation is where pricing tests die. The wrong price gets shown to the wrong visitor for 2 days, you get angry tweets, the whole experiment's data is contaminated. Build it carefully: visitor splits at FIRST visit (not session), persisted to localStorage + server-side, verifiable with a debug toggle. Test the entire signup flow at both prices end-to-end before launching.

Tasks

• Build the price split in your A/B test framework (PostHog, Optimizely, GrowthBook, in-house)
• Persist the price assignment server-side keyed by anonymous_user_id (NOT cookie alone — cookies wipe)
• Lock the price for the visitor's lifetime — never flip mid-funnel
• Test signup → checkout → first invoice at BOTH prices in staging
• Add a debug toggle for staff to force-pick a variant when investigating bug reports
• Verify Stripe receives the right price for the right customer

Pointers

• [Tool] PostHog A/B testing
• [Tool] GrowthBook price testing

[!CAUTION] Gotchas

• Cookie-only splits get wiped by ITP / privacy modes. Tie to a server-side anonymous_user_id, then promote to user_id at signup.
• Mid-funnel price flips (visitor was randomized to $20, refreshes the page, sees $30) are the #1 way pricing tests blow up on Twitter.
• Test the EDGE cases: trial-to-paid conversion, plan upgrades, mid-cycle changes — they often use a separate code path that doesn't read the variant.

Step 6: Draft the customer comms before launch — every audience separately

Estimated time: 1-2 days

Comms is the trust layer. Existing customers, prospects on the pricing page, sales prospects mid-deal, partners — each needs a tailored message. Write them all before launch, get a colleague to red-team, then ship. Surprise pricing changes are the single most-cited reason for customer churn in B2B SaaS post-mortems. Every comms gap is a churn risk.

Tasks

• Write the email to grandfathered existing customers ('we're updating prices for new customers, your plan is unchanged forever')
• Write the email to non-grandfathered existing customers (if any) with effective date + reason + grandfathering window
• Write the in-app banner for the pricing page with old / new context
• Write the FAQ document covering: why now, what's grandfathered, how billing works, refund policy
• Write the sales-rep talk track for in-flight deals
• Write the public blog post / social post if the change is large

[!CAUTION] Gotchas

• Burying the new price 4 paragraphs into the email is the most-flagged sin in pricing-change post-mortems. Lead with the number.
• Telling grandfathered customers 'we're raising prices' without immediately saying 'YOUR plan is unchanged' causes panic and churn calls.
• Sales reps who learn about the price change from a customer email are angry and rightfully so. Tell internal first, external second.

Agent prompt for this step

Draft the customer comms for this pricing change.

Read the Brief for the new pricing + grandfathering policy.

Output one message per audience:
1. Email to grandfathered existing customers (subject: 'A note on our updated pricing')
2. Email to non-grandfathered customers if any (with effective date, reason, transition support)
3. In-app pricing-page banner copy (50 words max)
4. FAQ doc (10-15 Q&A pairs, in plain language)
5. Sales-rep talk track for in-flight deals (3-4 sentences)
6. Public blog post if the change is large (500-700 words)

Constraints:
- Lead with what's not changing for existing customers (reassure first)
- Be specific about the new price (no 'starting from' weasel words)
- Acknowledge the change directly — don't bury it under marketing voice
- No 'value-driven evolution', no 'as we grow', no 'investment in our partnership'

Step 7: Soft-launch to internal + a small canary first

Estimated time: 3-5 days

Before public launch, soft-launch to your team + 5-10 friendly customers + 1-2% of new visitors. Watch the data for 48-72 hours: are there bugs, is the comms landing, are sales reps fielding pricing questions correctly? Issues found in canary cost you 1 angry customer instead of 200.

Tasks

• Deploy the experiment to internal staff first — let everyone hit the new pricing flow
• Open the canary to 1-2% of new visitors for 48 hr
• Monitor: support ticket volume, signup conversion, refund requests, social mentions
• If 0 issues: scale to 10%, then 50%, then 100% over 5-7 days
• If issues: pause the canary, fix, re-deploy

[!CAUTION] Gotchas

• Internal staff are biased toward 'looks fine' — get them to actually use credit cards in test mode + try the upgrade flow.
• Low-volume canaries (under 1% / under 100 visitors) generate too little data to spot bugs. Aim for 1-5% for 48-72 hr.

Step 8: Run the experiment until you have statistical significance

Estimated time: 4-8 weeks

The experiment runs until you hit the pre-computed sample size + minimum 4 weeks elapsed (to capture early-retention signal). Resist the urge to read the data daily and call the result early — pricing tests are noisy and stopping early biases you toward the noise. Set a stopping rule before launch + hold to it.

Tasks

• Pre-commit to a stopping rule: hit sample size AND minimum 4 weeks elapsed AND first cohort has 4 weeks of retention data
• Pull the dashboard weekly, not daily — daily reads are noise
• Track: trial-to-paid conversion, week-1 retention, week-4 retention, refund rate, support volume
• Watch the leading indicators: drop in pricing-page time-on-page (overpricing signal), spike in refund rate (oversold signal)
• If treatment looks 30%+ worse on conversion + 4+ weeks have elapsed: cut the experiment short to limit damage

[!CAUTION] Gotchas

• Stopping the experiment after 1 week because 'it looks like the new price is winning' is the #1 mistake. Pricing data has high noise; week 1 is rarely the truth.
• Counting only conversion ignores retention. A new price that converts 95% but churns 30% in month 2 is a worse outcome than the old price.
• Sample size calculations assume normal distribution. Pricing data is often long-tail (a few high-value plans skew everything). Use bootstrap confidence intervals if your data is heavy-tailed.

Step 9: Decide: ship the new price, kill it, or iterate

Estimated time: 1-2 days

After the experiment runs the full window, make the call. Three outcomes. (1) Ship the new price — incremental revenue per visitor is up + retention isn't down. Roll out to 100% + grandfather existing. (2) Kill it — conversion drop or churn rise outweighs incremental MRR. Revert. (3) Iterate — partial signal, test a different price point or a different tier structure. Document the decision in the Brief with the data, regardless of which way it goes.

Tasks

• Pull the final cohort metrics — conversion, retention, LTV-per-visitor
• Compute the 95% confidence interval on the lift / drop
• Make the call: ship / kill / iterate
• If ship: roll the change to 100% over 5-7 days, send the comms
• If kill: revert the experiment, note the learnings + the prices that didn't work
• If iterate: design the next experiment with the learnings (different price point, different tier mix, different audience)
• Document the decision in the Brief: what we tested, what we learned, what we shipped

[!CAUTION] Gotchas

• Shipping a price change because 'we ran the experiment so we should' even when results are flat is sunk-cost thinking. If the math is flat, kill cleanly.
• Iterating immediately on a different price without understanding why the first didn't work means you're guessing twice. Diagnose first.
• Publishing the experiment's learnings internally helps the team trust future pricing work. Pricing post-mortems compound the way engineering ones do.

---

Hand the template to your agent

Paste the prompt below into your agent's permanent system prompt so the agent reads, writes, and maintains this workspace as you work through the steps.

You are an agent on the "Run a pricing experiment" playbook workspace.

Your role: maintain the four surfaces (Cohorts, Brief, Comms, Pointers) as the experiment runs.

Cadence:
- Every Monday: pull the cohort metrics (signup conversion, payment conversion, week-1 retention, week-4 retention) and post to the Brief.
- Flag when treatment cohort conversion drops >15% vs control — early signal of overpricing.
- Flag when treatment cohort churn rises >10% vs control by week 4 — durable signal.
- When the user updates grandfathering policy: re-derive customer comms and update the Comms table.

First MCP tool calls:
1. list_surfaces(workspace_slug="run-a-pricing-experiment")
2. get_doc(workspace_slug="run-a-pricing-experiment", surface_slug="brief")
3. list_rows(workspace_slug="run-a-pricing-experiment", surface_slug="cohorts")

Hard rule: do not draft customer-facing comms about pricing without explicit user review. Pricing comms are high-stakes; never auto-send.

---

FAQ

How big does a pricing experiment need to be?

Sample size depends on the effect size you want to detect. For a 10% conversion delta at 95% confidence with a 5% baseline conversion, you typically need 5000-10000 visitors per arm. For B2B with 100-500 visitors/month, that's 6-12 months — usually too long. Two fallbacks: (1) test bigger price changes (20-30%) which need smaller samples to detect, (2) skip the A/B and use gradual rollout by signup date with cohort comparison instead.

Should I tell customers I'm running a pricing experiment?

No, not while it's running. Do tell them when you ship the change publicly. Pricing experiments are short-term, opaque, and standard practice — disclosing them mid-flight invites confusion + competitor screenshotting. What's NOT okay: showing different prices to customers who can compare notes (B2B teams sharing internal docs, public Twitter, etc.). Limit the test scope to anonymous visitors.

How do I raise prices on existing customers without losing them?

Default: don't. Grandfather indefinitely. Existing customers churned to a price increase are 2-3x more painful than the incremental revenue. If you must raise on existing: 60-90 days notice, clear reason, generous transition (12 months at old price), and a manual outreach to top accounts. Even with all of that, plan for 5-15% additional churn in the affected segment.

Can my AI agents help run a pricing experiment?

Yes. Agents are good at: modeling pricing math against historical conversion + churn data, drafting customer comms across audiences, watching cohort metrics + flagging churn drift, surfacing which segments are price-elastic. Not good at: making the strategic call (ship / kill / iterate) or judging the soft signals (sales rep frustration, social-media tone). Use them to keep the analysis honest.

What's the most common mistake teams make with pricing changes?

Three in order: (1) raising prices on existing customers without grandfathering, then spending 6 months apologizing, (2) calling the experiment too early because week-1 results 'look great' and missing the month-2 retention drop, (3) skipping the comms work and surprising customers with a price change in their next invoice. All three are preventable; this playbook's middle steps exist to prevent them.