How to Research Willingness to Pay for AI Features: A PM's Framework

Why Standard Pricing Research Fails for AI Features

Classic pricing research assumes customers have a reference point. "Would you pay $20 a month for this?" works when customers already pay for comparable products and can calibrate their answer. For genuinely novel AI features, they can't. The result is answers that sound like data but are actually noise.

The novelty problem

Customers systematically undervalue features they haven't used. Before they've experienced the time savings or quality improvement, they anchor to the effort of switching, not the value of the outcome. A feature that saves an analyst 4 hours a week gets priced like a $10/month tool, not like a $200/month assistant, until the analyst has actually used it.

The anchoring problem

If you name a price before asking whether they'd pay, they anchor to it. 'Would you pay $30/month for this?' will get different answers than 'Would you pay $10/month for this?' from the same customer. Both answers are artifacts of your framing, not genuine willingness to pay.

The uncertainty problem

AI features have variable quality that customers have learned to price in. If your feature works 80% of the time and fails the other 20%, customers apply a reliability discount. They won't tell you this directly; they'll just say the price feels high. The real issue is trust, not price.

The comparison problem

Customers compare your AI feature to the cheapest available substitute, not to the value it delivers. A research synthesis tool gets compared to ChatGPT at $20/month, not to the junior analyst it's replacing at $60K/year. Your job is to shift the comparison frame before asking about price.

The fix is to build a reference point before asking about price. Show a demo. Let them use the feature for 10 minutes. Have them describe what they just experienced in their own words. Then ask about price. The answers will be materially different.

The Van Westendorp Price Sensitivity Meter

The Van Westendorp PSM is the most reliable quantitative method for finding an acceptable price range before you have live pricing data. It bypasses anchoring by asking four relative questions rather than one absolute question.

Too cheap

"At what price would this be so cheap you'd question its quality?"

Cheap / acceptable

"At what price would this start to feel like a bargain?"

Expensive / acceptable

"At what price would this start to feel expensive, but you'd still consider it?"

Too expensive

"At what price would this be so expensive you wouldn't consider it regardless of quality?"

Run this with 20 to 30 customers who have experienced a demo or trial of the feature. Plot the four cumulative distribution curves. The intersection of the "too cheap" and "expensive but acceptable" curves gives you the optimal price point. The range between the "cheap" and "expensive" intersections is your acceptable price range.

Typical Output

For a mid-market B2B AI feature, a VW study might produce: "Acceptable range is $18 to $45/user/month. Optimal entry price is $24." This is not the final price; it is the starting hypothesis for your pricing experiment. Start at the top of the range, not the middle.

Limitation: VW works well for known categories where customers can calibrate. For genuinely novel AI features with no comparable product, the four questions produce wide, noisy ranges. In those cases, use JTBD interviews first (section 3) to build the value anchor before running VW.

Jobs-to-Be-Done Interviews for Pricing Discovery

The JTBD framework is usually applied to feature discovery, but it is the most effective tool for pricing discovery because it anchors willingness to pay to the economic value of the job the customer is hiring your product to do.

The key insight: customers don't pay for features. They pay to get a job done. The price they will pay maps to the value of the job, not the cost of building the feature or the price of a generic AI subscription.

Step 1: Find the Job

Script: "Tell me about the last time you had to [do the thing your AI feature handles]. Walk me through exactly what you did."

Goal: Surface the actual workflow, not the hypothetical one. Customers describe what they actually do, which is often 40% messier than what they describe when asked in the abstract.

Step 2: Find the Cost

Script: "How long did that take? How often do you do it? Who else is involved?"

Goal: Convert the job to a time and labor cost. If a VP of Sales spends 45 minutes preparing for every discovery call and has 15 calls a week, that is 11+ hours a week of expensive time.

Step 3: Find the Value Anchor

Script: "What would it mean for you personally if you could do that in 5 minutes instead of 45?"

Goal: Get them to articulate the outcome value in their own words. The answer becomes your pricing copy. It also sets the value frame before you ever mention a price.

Step 4: Price the Job

Script: "If you could eliminate that 45-minute prep entirely, what would be a fair price to pay per month for that?"

Goal: Now the customer is pricing the job, not the feature. You will consistently get 3 to 10x higher answers than if you had led with the feature description.

Learn to Price and Position AI Products

The AI PM Masterclass covers pricing strategy, go-to-market, and how to build a monetization model that holds up in production. Taught live by a Salesforce Sr. Director PM.

Setting Your Value Metric: What to Charge Per

The value metric is what you charge per: per seat, per query, per output, per outcome. Getting the value metric wrong is more damaging than getting the price wrong, because it misaligns who pays with who benefits. A wrong value metric drives away your best customers and subsidizes your least valuable ones.

Per seat

Every user gets roughly equal value from the product. Best for collaboration tools where the seat count reflects team adoption, not usage intensity. Risk: your heaviest users pay the same as light users.

Per output

Value scales with volume: documents generated, queries answered, analyses run. Aligns well with AI features where cost is also usage-based. Risk: customers throttle usage to control spend, limiting adoption.

Per outcome

You can measure and attribute a business result: revenue influenced, hours saved, errors prevented. Highest alignment with customer value. Hardest to measure and verify. Best for high-ticket B2B contracts where the outcome is auditable.

Flat subscription

The value is access itself, not usage. Best for foundational features where any usage is valuable and you want to encourage adoption without usage anxiety. Risk: customers with very different usage levels have very different perceived value.

How to test your value metric hypothesis: ask five customers which pricing structure feels most fair, and ask them to explain why. The explanations reveal which metric they naturally map to the value they received. If three of five independently describe a per-output structure, that is stronger signal than any VW study.

Competitive Anchoring in the AI Pricing Market

Customers always compare your price to something. The question is whether you control what they compare it to, or whether the comparison happens without you.

In 2026, the default comparison anchors for AI features are: Microsoft Copilot at $30/user/month, Claude Pro at $20/user/month, and Cursor at $20/user/month. If your AI feature is positioned generically, customers will anchor to these and price-resist anything above $30.

Bad anchor (leads with the feature)

"Our AI writes your PRDs." Comparison: ChatGPT at $20/month. Customer thinks: this is a writing assistant. I already have one.

Good anchor (leads with the job value)

"Your senior PM spends 6 hours a week writing PRDs. Our AI gives those 6 hours back." Comparison: a $150K PM role. Customer thinks: this replaces a significant cost.

Build the anchor in discovery

Before your pricing page, before your sales call, before you mention a number: quantify the value of the job in the customer's terms. Then the price is a fraction of what they're already paying.

Test your anchor messaging

A/B test landing page copy. Variant A leads with the feature. Variant B leads with the job value and names a specific cost (time, labor, error rate). Track revenue per visitor, not conversion rate.

Running Your First Pricing Experiment

Qualitative research gives you a hypothesis. The pricing experiment tests it with real purchase behavior. These are different things. Customers who say they would pay $40 in an interview often convert at $20 and churn at $40. Run the experiment before you commit to a pricing structure.

Choose one variable to test

Price point only (not value metric, not tier structure, not trial length) for the first experiment. Testing multiple variables at once makes causation impossible to attribute.

Set your minimum viable sample size

For a B2B AI feature at $20 to $50/month, you need at least 300 trial signups per variant to reach statistical significance on revenue per visitor within 6 weeks. If your volume is lower, you're running a directional test, not a conclusive one.

Track revenue per visitor, not conversion rate

Conversion rate optimizes for the lowest price. Revenue per visitor finds the price that maximizes revenue, which is usually higher than the price that maximizes conversions.

Start high, move down if needed

You can always discount. You cannot raise prices without a meaningful product change and risk of churn. Start at the top of your VW acceptable range and run the experiment there first.

Act on the result within 2 weeks

Pricing experiments that produce clear results but sit in a review queue for two months are useless. Commit in advance to the decision rule: if variant A has higher revenue per visitor at 90% confidence, we ship variant A's price.