Willingness to pay and price testing

Every founder makes a pricing decision. Most make it wrong because they never test it.

A founder of a PLG SaaS product picks a price by looking at five competitors, splitting the difference, and launching. They hit $10k/month in revenue. It feels like a win. But they never asked: would customers pay $50/month instead of $29? Would they pay $99? Would a $999/month enterprise tier pull in larger accounts? The founder left 10–40% of revenue on the table and will never know.

Or the opposite: a founder of a sales-led product prices their tool at $500/month based on a multiple of implementation cost. They launch. Nothing happens. No motion, no conversation, no traction. Prospects ghost. It takes six months to realize the price is not anchored to customer WTP; it is anchored to internal cost structure. By then, the market has decided they are expensive, and repricing looks like weakness.

Willingness to pay is not intuitive. It is not what customers say they will pay, and it is not what you feel like charging. It is the maximum price at which a buyer will execute a transaction at a given moment, in a given segment, under a given buying process. It moves. It is testable. And most founders never test it.

What WTP is (and isn’t)

WTP is not the same as value. A customer might perceive $100k/year in value from your product but only be willing to pay $12k/year. The gap is not dishonesty; it is constraint (budget ceiling), priority (other uses for the money), or disagreement about your share of the value created. Your job is to find the price where enough buyers say yes while the unit economics work.

WTP is not a single number. It varies by segment (enterprise vs mid-market), use case (core workflow vs nice-to-have), and buyer type (CFO vs practitioner). The founder who treats price as a universal number is optimizing for the average buyer and leaving money on the table in high-value segments. A single price point is a choice, not an accident.

WTP is not what customers say. If you ask a prospect, “What would you pay?”, they will say “as little as possible.” If you ask, “Would you pay $10,000/year?”, they will often say no, then pay $12,000/year when they are in purchase mode. Stated preference (what customers say) and revealed preference (what they actually do) diverge. Testing for WTP requires observing behavior, not collecting opinions.

The diagnostic: how to test WTP

Price testing takes three forms, each with different strengths.

Revealed preference: A/B tests and tiered pricing

This is the gold standard. Show different price points to different segments, measure conversion, and calculate revenue-optimal price. The test is real; the buyer is in purchase mode; the signal is clean.

Tiered pricing. Offer three price points (Good/Better/Best) and observe which tier customers choose. If 70% of customers pick the middle tier, you are probably underpricing the top tier (they would pay more, but the option is not compelling enough). If 5% pick the top tier, it is overpriced or poorly differentiated. If 50%+ pick the bottom tier, you are probably overpriced overall; the bottom tier is a ceiling, not an entry point.

Price test via trial or freemium cohort. If you have a free or trial tier, segment conversion by trial usage intensity. Do high-usage users (proven value) convert at higher prices? If usage is the same but price acceptance diverges, you have a messaging or segment problem, not a WTP problem.

Paid search landing page test. If you acquire customers via ads, test two landing pages with different price anchors. Keep messaging constant, vary only the price. (You may also vary the tier structure—e.g., $49 vs $99 vs $299 vs $49 vs $149—to understand how anchoring affects choice architecture.) Measure CAC, conversion rate, and revenue per acquired customer. Revenue per customer is the metric; conversion rate alone is a trap.

Ask during sales, not before. Sales-led GTM: in a sales conversation, test pricing by proposing different tiers to similar prospects and observing how they respond. A prospect who says yes to $10k/month but asks for “a discount to $8k” has a WTP of ~$8k–$10k. A prospect who says “$10k is way too high, we were thinking $2k” has a WTP of ~$2k–$3k. These signals are live data; codify them.

Stated preference: willingness-to-pay surveys

Surveys are weaker than revealed preference but faster. Ask customers (existing or prospective) directly: “At what price would you consider this product too expensive?”, “At what price would it seem too cheap (low quality)?”, “At what price is it a good deal?”, “At what price would you definitely buy?” Use the van Westendorp Price Sensitivity Meter or a simpler version: plot responses and identify the range where “good deal” and “definitely buy” overlap.

Caveat: survey respondents do not have skin in the game. A prospect answering a survey will be more price-sensitive than a prospect in a purchase conversation. Use survey data to inform your testing, not to set price directly.

Contingent valuation: pricing model builders and configurators

Deploy a tool that lets customers build their own configuration (e.g., “users: 10, seats: 5, integrations: 3”) and see price in real-time. This surfaces WTP by use case: a customer building a 100-user configuration is revealing that they value the product enough to evaluate at high tier; a customer abandoning at 50 users is showing a price ceiling. Usage and price are linked, so you understand where WTP breaks.

Founder mistakes in price testing

Mistake 1: Not testing at all

The most common error. You set a price, watch revenue, and assume that is the only number that works. You never run an experiment. You never observe: “Would 10% more revenue come from a 20% price increase if we lost 10% of customers?”

How to fix it. Run one test. Offer a 15% price increase to new customers in a single segment for 4 weeks. Measure conversion and revenue. If revenue goes up, you were underpriced. If it goes down, you were right or close. One test takes 4 weeks and clarifies pricing more than six months of internal debate.

Mistake 2: Testing on the wrong segment

You test price on your most price-sensitive segment (bottom of market, or longest sales cycle, or most budget-constrained) and conclude all segments are price-sensitive. Then you leave money on the table in your enterprise or high-use segments, which have completely different WTP.

The trap: a startup founder testing price with one customer segment often has a PLG product and runs the test on free-to-paid conversion. Free-to-paid prospects are always price-sensitive; they have low switching cost and low commitment. If you test only there, you miss that enterprise or annual-commitment segments have 3–5x higher WTP. Test by segment.

Mistake 3: Changing price too often

You run a test, interpret the data weakly (“it seemed like conversion went down a tiny bit”), and change price again. Six months later you have changed price five times. Customers see you as unpredictable. Sales is confused. You have no clean data because each test cohort is too small. The market has lost confidence in your pricing.

How to fix it. Commit to a price for a minimum window (8–12 weeks). Run one test. Make one decision. Ship it. Hold it for 6 months before re-testing. One stable price with clean data is better than five changes with noisy data.

Mistake 4: Confusing price with value

You think “we added a feature, so we should raise price by 10%.” But the feature does not align with customer WTP; it is not in the use case they are evaluating on. You raise price and see conversion drop 20%. You conclude customers do not value the feature, but really they do not value that feature for their use case. Your segmentation or messaging was wrong, not your value delivery.

How to fix it. Before changing price, segment first. Identify which customer segment cares about the new feature and would willingly pay for it. Test price increase with that segment, not the full base. A 10% price increase that only applies to enterprise tier or annual plans is very different from a blanket 10% raise.

Real examples of price discovery

Slack (early). Slack launched with a freemium model at a time when no one was selling premium chat. They did not know if people would pay $12.50/person/month. By observing free-to-paid conversion rates, they discovered that teams with 5+ active users (high value proxy) had 35% conversion, while small teams had 8% conversion. This revealed that Slack had WTP tied to team size and engagement, not just “this is a nice product.” It led them to focus enterprise sales on high-usage teams and to anchor premium pricing at team scale, not per-person cost. Revenue-optimal decision that came from revealed preference, not guessing.

Stripe (early). Stripe could have charged per transaction (like competitors) or a flat monthly fee. They tested pricing structure by offering both and observing. They discovered that high-volume merchants cared about per-transaction cost, while low-volume merchants preferred predictability of flat fee. This revealed a segmentation insight: high volume = high WTP for better per-transaction pricing. Stripe optimized for high-volume and priced accordingly. The decision came from observing revealed preference (what merchants actually chose), not from what Stripe guessed about the market.

HubSpot (early). HubSpot initially priced on a per-user basis. They noticed that small businesses using the product wanted to add more users but hit a price ceiling. They tested a per-contact pricing model and discovered that small businesses had much higher WTP when pricing was tied to success metric (contacts in the database) instead of the resource cost (users). This single change opened a new market and made the product affordable to segments that could not pay per-user. The decision came from observing conversion failure (small businesses bouncing at the price), not from guessing.

Rules for price testing

1. Test one variable at a time. If you test price and messaging together, you cannot isolate which drove the result. Test price only; keep everything else constant.

2. Define your segment first. Do not test “company size 1–100 employees” and “company size 100–1000 employees” in a blended pool. Test each segment separately. If you blend, the high-WTP segment subsidizes learning in the low-WTP segment, and you will miss the opportunity.

3. Measure revenue per acquisition, not conversion alone. A price increase that lowers conversion by 15% but raises revenue per customer by 25% is a win. Conversion is not the metric; revenue is. A discount that raises conversion by 50% but lowers revenue per customer by 40% is a loss, even if it feels like progress.

4. Hold price stable during the test. If you change price on week 2, your test ends on week 2. Commit to 8–12 weeks of constant price so you collect enough samples to reach statistical significance.

5. Communicate pricing changes proactively. If you raise price, tell existing customers prothe increase and when it takes effect (usually 30–60 days for subscription products, longer for enterprise contracts). A surprise price increase feels like theft; a communicated increase feels fair. The customer response will teach you about true WTP vs. complaint noise.

6. Use tiering to guide WTP discovery. If you offer Good/Better/Best at $29/$99/$299, and 60% of customers choose Better, test moving the tiers to $49/$149/$449 and observe. If the distribution stays the same, the tiers are well-calibrated and you have room to move. If distribution shifts heavily toward Good, you overpriced middle tier. If it shifts to Best, you under-priced Best.

Where the insight goes next

Once you have tested WTP, you have a foundation for every downstream decision. You know your pricing power in each segment. You know whether price is the limiting variable (too high) or revenue pool is (too low or too small a segment). You know whether sales velocity matters more than volume. And you know which price point allows you to invest in customer success, which allows you to stay self-serve, and which is so low you need to cut costs or exit the segment.

Most importantly, you stop guessing. You have data. You can move with confidence.

The next node reveals the question this raises: once you know WTP and have tested pricing, how do you architect the monetization model itself?