I often get asked how to validate whether customers will actually pay significantly more for a SaaS add-on — not just say they would in a survey, but put real money on the line. The approach I use is a pragmatic 90-day pricing test that balances statistical rigor with the speed and clarity a product team needs. Below I walk through the playbook I’ve used to prove — or disprove — a hypothesis like “customers will pay 30% more for this add-on” in a way that minimizes risk and maximizes learning.
Define the hypothesis and primary metric
Start with a crisp hypothesis. For example: “Target customers will upgrade to the Premium Add‑On at a price 30% higher than the current list price within 90 days.” Translate that into a measurable primary metric. I prefer monetary conversion rate — the percentage of target accounts that convert to the add‑on multiplied by the average revenue per converted account — because it directly ties to revenue rather than just clicks or intent.
Supporting metrics should include:
- Conversion rate (trial start to paid upgrade)
- Average Revenue Per User (ARPU) for converted accounts
- Churn or downgrade rate within 90 days
- Activation/completion rates of onboarding flows for the add‑on
- NPS or qualitative feedback from purchasers and refusers
Pick the right cohorts and sample size
Not every customer is relevant. Focus on the segment most likely to buy your add‑on — maybe Enterprise accounts with over X ARR, or mid‑market accounts using a particular core feature. I split traffic into cohorts by account size, industry, and product usage intensity to avoid diluting the signal.
You'll need meaningful sample sizes. If you expect a baseline conversion of 10% and want to detect a relative increase that corresponds to 30% more revenue, plug numbers into a simple sample size calculator for proportion tests. If you don’t have the luxury of huge samples, accept wider confidence intervals and supplement with rich qualitative feedback.
Design the price variants and controls
Keep the experiment simple: a control group sees the current price, and test groups see the new price points. I recommend three arms:
- Control: current add‑on price (baseline)
- Test A: +15% pricing
- Test B: +30% pricing (the target)
For some products, a fourth arm with a value‑packaged offer (same price but bundled benefits) helps disentangle whether price or perceived value is the limiter. Make sure each account is exposed to a single arm to avoid contamination.
Experiment channels and arrival flows
Decide where the price will be seen: in‑app upgrade modal, pricing page, pricing email, sales outreach, or a mix. My recommendation: run the test across the primary purchase channels that drive most conversions. For self‑serve SaaS, that’s usually in‑app and pricing page. For sales‑led deals, have sales follow the script and offer the tested price to matched accounts.
Keep the UX consistent across arms except for price and any explicit value messaging tied to price. That isolates the effect of price itself.
Guardrails and ethical considerations
Be transparent internally about the experiment. For B2B customers, abruptly changing prices can harm relationships. Use these guardrails:
- Cap exposure for high-risk accounts: exempt top 5% ARR customers or require AE approval.
- Offer a satisfaction or escape hatch: a short identical refund window or ability to revert to prior spend for key accounts.
- Notify sales and support teams with clear FAQs and escalation paths.
Pricing communication and value framing
Price changes rarely work without comms. Test the price plus one of two messaging treatments: a purely numeric increase, or an increase framed with additional value articulation. For example, when increasing price for a reporting add‑on, show improved SLAs, extra access, or time savings quantified in hours and dollars.
Example messages to test:
- “New price: $130/month — includes advanced reporting and 2 dedicated export slots.”
- “Now $130/month — customers save 3 hours/week with automated reports.”
Billing, offers and promotions
Decide whether to test list price or introductory discounted pricing. If you want to know whether customers will accept a permanent 30% higher list price, show list price and limit promotional coupons. If you want to see whether a higher price with an introductory discount performs, include a time-limited discount arm.
Make billing changes reversible in your system and tag transactions so you can slice revenue by experiment arm. If using Stripe, add metadata to subscriptions; if sales‑led, add a custom field on deal records.
90‑day timeline and milestones
Map the test across a 90‑day calendar. I use a structure like this:
| Days | Goal |
|---|---|
| 1–7 | Launch, QA, internal alignment, enable analytics tags |
| 8–30 | Initial traction — monitor for any catastrophic drop in conversion |
| 31–60 | Collect statistically meaningful sample; run customer interviews |
| 61–90 | Finalize results, assess churn/downgrade impact, measure revenue uplift |
During the first 30 days, my focus is on QA and early-warning signals: any sudden spike in cancellations or support tickets triggers immediate review. The next 60 days are about collecting enough conversions and qualitative data to make an informed decision.
How I analyze results
At the end of 90 days I compare arms across the primary metric and supporting metrics. Key questions I ask:
- Did the +30% arm increase ARPU enough to offset any drop in conversion compared with control?
- Is the revenue lift persistent or front‑loaded (e.g., discounts, promotions)?
- Did churn or downgrades increase in the test arms?
- What did purchasers say about value versus non‑purchasers?
I prefer a table view that summarizes revenue per cohort and conversion elasticity:
| Arm | Conversion | Avg Rev / Conv | Total Rev |
|---|---|---|---|
| Control | 10% | $100 | $10,000 |
| +15% | 9.5% | $115 | $10,925 |
| +30% | 8.5% | $130 | $11,050 |
In this hypothetical, even with conversion falling slightly, total revenue rose — a win. But if conversion collapses (e.g., from 10% to 5%), the math flips and the price hike fails.
Qualitative follow‑ups
Quantitative results tell what, interviews tell why. Schedule 10–20 short interviews across buyers and non-buyers in each arm. Ask:
- What stopped you from upgrading?
- What value would make the add‑on unquestionably worth the price?
- Would you buy at the higher price if X feature or SLA existed?
Often the path to acceptance is not an across‑the‑board price cut but adding a small feature or clearer ROI messaging that shifts perceived value.
Decide and act
Once you have the numbers and the feedback, choose a path: adopt the new list price, create targeted pricing for segments, add a value ladder (e.g., Basic/Pro/Premium add‑on), or iterate with a new test. If the +30% arm clearly wins on revenue without unacceptable churn, it’s time to operationalize: update pricing pages, sales decks, and billing rules and retrain the sales team.
Throughout the process, keep stakeholders informed with weekly dashboards and concise summaries. Pricing tests are as much about organizational alignment as they are about data — if finance, product, and sales trust the experiment, roll‑out becomes a lot smoother.
If you'd like, I can provide a simple spreadsheet template for the sample size calculations and revenue comparison table I use. It makes setting up the test much faster and helps you avoid rookie mistakes like failing to tag experiment participants or confusing trial starts with paid conversions.
