What is pricing methodology?
Written by Arnon Shimoni
✓ Expert
Last updated on:
Pricing methodology is the set of research methods and decision rules a company uses to arrive at a price. It covers how you measure willingness to pay, how you turn that measurement into a price level, and how you structure the price so it can be sold and billed. Common methods include the Van Westendorp Price Sensitivity Meter, the Gabor-Granger method, conjoint analysis, price elasticity estimation from transaction data, and structured willingness-to-pay interviews.
Field | Detail |
|---|---|
Also known as | Pricing research, price discovery, price setting methodology |
What it answers | What should the number be, and how confident are we in it |
Main survey methods | Van Westendorp PSM, Gabor-Granger, conjoint analysis (CBC/ACBC), MaxDiff, monadic price testing |
Main behavioural methods | Transactional elasticity analysis, price A/B tests, win/loss analysis, discount distribution analysis |
Distinct from | Pricing strategy (the intent, e.g. value-based, cost-plus, market-based) |
Distinct from | Pricing model (the mechanic, e.g. seats, usage, credits, hybrid) |
Typical owners | Product marketing, pricing/RevOps, finance, sometimes a founder with a spreadsheet |
Typical cadence | Full study at launch or major repositioning, lighter checks quarterly |
Where it fails | Methods built for one-off physical goods, applied to recurring consumption pricing |
Pricing strategy, pricing methodology, and pricing model are three different things
People use the three interchangeably, and that's most of why pricing conversations go in circles. They sit in a stack.
Pricing strategy is the intent. Are you pricing off your costs, off the competition, or off the value the customer gets? That's cost-plus, market-based, and value-based respectively. Strategy tells you where to look for the number.
Pricing methodology is how you find the number. Surveys, choice experiments, transaction analysis, live price tests. Methodology tells you what the number is and how much you should trust it.
Pricing model is the mechanic you ship. Per seat, per API call, per agent run, per resolved ticket, prepaid credits, a hybrid of several. The model decides what the customer's invoice looks like and what your billing system has to compute.
You can hold a value-based strategy, run a conjoint study, and ship a credit model. Those are three independent choices. Most of the bad pricing I've seen came from a team that picked the model first (usually by copying whoever they admire), then reverse-engineered a justification. e.g., "we'll do credits because Clay does credits," with no view on what a credit is worth to the buyer.
The pricing research methods, compared
Each method answers a different question. Picking one because it's the one you've heard of is how you end up with a precise answer to a question you weren't asking.
Method | Question it answers | Format | Rough sample needed | Gives you a demand curve? | Best for |
|---|---|---|---|---|---|
What price range is credible? | 4 open-ended price questions | 150-300 | No | New categories with no reference price | |
What price maximises revenue? | Purchase intent at 5+ price points | 200-400 | Yes | Known product, single price point | |
What are the features worth, relative to price? | Forced choice between bundles | 300-800 | Yes, per configuration | Packaging, tiering, bundling | |
MaxDiff | Which features matter most? | Best/worst from a set | 200-400 | No | Feature prioritisation before packaging |
Elasticity from transactions | How did demand actually move? | Historical billing and usage data | Your customer base | Yes | Repricing an existing product |
Price A/B test | What happens if we change it? | Live experiment | Enough traffic for significance | Partial | Self-serve and PLG motions |
Win/loss and discount analysis | Where does the price actually break? | CRM and quote data | 50+ closed deals | No | Enterprise and sales-led motions |
Sample sizes above are practitioner convention rather than a statistical law. The real driver is how many distinct segments you need to read separately: if you want to price differently for SMB and enterprise, you need each of those cells to hold up on its own, which roughly doubles the requirement.
Two of these methods are stated preference (you ask people what they'd do) and the rest are revealed preference (you look at what they did). Stated preference is cheaper, faster, and available before you have customers. It also overstates willingness to pay, consistently. Revealed preference is honest and slow, and requires that you already shipped something.
How to pick a method
The decision comes down to what you already have.
No product in market, new category. Start with Van Westendorp. It's the only method that works when the respondent has no reference price, because it asks them to construct one out loud. Follow with qualitative interviews to understand the alternative they'd use instead of you. Do not treat the Optimal Price Point as a price. It's a sanity range.
No product in market, established category. Gabor-Granger, because reference prices exist and you're really asking where you sit relative to them. Add price benchmarking against the incumbents, since your respondents are silently benchmarking anyway.
Product in market, deciding on packaging and tiers. Conjoint. It's the only method that prices features against each other rather than pricing the whole product as one blob. If you're building a good-better-best structure or deciding which capability gates the enterprise tier, this is the one.
Product in market, changing the price. Transactional elasticity first, survey second. You have the data. Look at how conversion, expansion, and churn moved across your historical price points and discount bands before you ask anyone anything.
Self-serve product with volume. A/B test. Nothing beats a live experiment when you have the traffic to run one. Watch for the trap: price tests that measure conversion but not retention will tell you to cut the price every single time.
Usage or consumption pricing. None of the classic methods fit cleanly. See the next section.
Where these methods break for usage-based and AI pricing
Every method in the table above was designed to find a price. One number, one unit, one purchase decision. That assumption held for a box of cereal in 1976 and for a seat-based SaaS product in 2014. It doesn't hold when the customer's bill depends on how much they use, which they don't know in advance.
Four specific failures:
The respondent can't price a unit they can't feel. Ask someone what they'd pay per 1,000 tokens and you'll get a number, and the number will be meaningless. They have no intuition for how many tokens a workflow consumes. The fix is to run the study on an outcome the buyer understands (a resolved ticket, an enriched contact, a generated document, a rendered minute) and derive the technical unit afterward. See AI token pricing and outcome-based pricing.
One price point isn't the decision. In a hybrid model, the buyer is evaluating a platform fee, an included allowance, an overage rate, and a commit discount at the same time. Gabor-Granger gives you one price. Conjoint can handle multiple dimensions, and it's the method I'd reach for here, treating the overage rate and the included volume as separate attributes.
Willingness to pay moves with volume. The per-unit price a buyer accepts at 10,000 units is not the price they accept at 10 million. That's the whole reason tiered usage pricing and volume discounts exist. A single-price study can't see the curve. You need to test at multiple volume assumptions, which multiplies your sample requirement.
Your costs move too. For AI products, unit cost changes when a model provider changes their rate card. A pricing study from six months ago was run against a cost base that no longer exists. This is a real operational problem, not a theoretical one, and it's why margin needs to be a live input rather than a one-time check. We wrote about the volatility side of this in token economics.
Sequencing: what to run and when
Pricing research works better as a sequence than as one big study.
Before launch. Qualitative interviews about the alternative (what do they do today, what does it cost them). Then Van Westendorp or Gabor-Granger for a range. Budget 4-6 weeks. Accept that you're getting a range, not a price.
At launch through the first 50 customers. Stop surveying. Watch what happens in the funnel and on the quotes. Discount depth is the loudest signal you have: if reps are discounting 30% to close, your list price is wrong or your packaging is wrong. Track it in your pricing analytics.
First repricing. Transactional elasticity plus conjoint on packaging. By now you have real usage distributions, so you can model what a change does to actual accounts rather than to a hypothetical respondent.
Ongoing. Quarterly review of discount distribution, net revenue retention by cohort and plan, and margin leakage by customer. Full study only when something material changes: new segment, new model, new competitor, or a cost base that moved.
The teams that get this right treat pricing as something they revisit on a schedule. The teams that don't run one heroic study, ship the price, and then defend it for three years. We've written about why that ownership question is usually the real blocker: pricing velocity is an ownership problem.
Common mistakes in pricing methodology
Mistake | What happens | What to do instead |
|---|---|---|
Treating the Van Westendorp OPP as the price | You ship a number that's an artifact of curve intersection, not of demand | Use PSM for a credible range, then a second method for the level |
Asking "would you pay $X" directly | Respondents anchor, agree, and overstate. Stated intent runs well above behaviour | Force a tradeoff (conjoint) or an escalating ladder (Gabor-Granger) |
Surveying users instead of buyers | You measure enthusiasm from someone with no budget | Screen for budget authority, especially in B2B |
Running the study on the technical unit | Buyers can't price tokens, API calls, or compute-seconds | Run it on the outcome, then convert |
Ignoring the alternative | Every price is relative to what they'd do otherwise | Quantify the current cost: headcount, incumbent tool, or doing nothing |
One study, then silence for three years | The market moved, your costs moved, your product moved | Schedule the review, own it explicitly |
Testing price without testing packaging | You find the best price for the wrong bundle | Conjoint prices the bundle and the level together |
Measuring conversion, not retention | Every test says "lower the price" | Instrument to 90-day retention before you call a winner |
How Solvimon fits in
Pricing research produces a decision. Shipping that decision is a separate problem, and it's the one that kills most pricing changes.
The gap is concrete. A conjoint study tells you the enterprise tier should include 2 million credits with a €0.004 overage rate and a 15% discount at a €150k commit. Acting on that means: a new plan in the catalog, a migration path for customers on the old plan, grandfathering rules for the accounts you're not moving, a proration policy for mid-cycle switches, and a quote-to-invoice path that doesn't require anyone to open a spreadsheet. In most companies that's a quarter of engineering work, which is exactly why the pricing change gets deferred and the study goes stale.
Solvimon exists to make that part cheap. The pricing engine holds plans, rate cards, tiers, commits, and overage rules as configuration rather than as application code, so a new price is a catalog change instead of a release. Usage metering captures the events the price is computed from, so when you reprice from tokens to outcomes, the historical data supports both. Grandfathering and versioned plans are native, so migrating half your base to a new structure doesn't mean maintaining two billing paths. And because billing and metering sit in one ledger, you can run the elasticity analysis for the next pricing decision against clean data instead of reconstructing it from three systems.
The short version: we run your pricing and invoicing so that changing the price is a decision rather than a project. More on how that works in where does your pricing live and headless monetization.
Related terms
Frequently asked questions
What's the difference between pricing methodology and pricing strategy?
Strategy is the intent (price off cost, off competitors, or off customer value). Methodology is how you find the actual number given that intent. A value-based strategy still needs a method, e.g., conjoint or Van Westendorp, to turn "price off the value" into a figure you can put on a page.
Which pricing research method is most accurate?
Choice-based conjoint tends to predict real behaviour best among survey methods, because it forces tradeoffs instead of asking for a number. Transactional elasticity from your own billing data beats all survey methods, when you have enough history to run it.
Can I skip pricing research and copy a competitor?
You can, and plenty of companies do. The cost is that you inherit their cost structure, their segment mix, and their packaging assumptions, none of which are yours. Benchmarking is useful as a constraint on your range. It's a poor substitute for knowing what your buyer will pay.
How much does a pricing study cost?
A DIY Van Westendorp through a panel provider runs in the low thousands. An agency-run choice-based conjoint with a proper sample typically runs into the tens of thousands and takes 6-10 weeks. Prices vary widely by market and panel quality, so treat those as order-of-magnitude.
How many people do I need to survey?
Convention is 150-300 for Van Westendorp, 200-400 for Gabor-Granger, and 300+ for conjoint. Multiply by the number of segments you need to analyse separately. In enterprise B2B, where the addressable buyer population might be a few thousand people, you often can't hit those numbers and have to lean on interviews and win/loss data instead.
Do these methods work for AI products?
Partially. The methods work, the units don't. Run the study on something the buyer can reason about (a resolved ticket, a generated report, an enriched record) rather than on tokens or GPU-seconds, then convert to the technical unit you actually meter. See AI agent pricing.
What is stated preference vs revealed preference?
Stated preference asks people what they would do (surveys). Revealed preference observes what they did (transactions, tests). Stated preference reliably overstates willingness to pay, so a common practice is to discount survey-derived prices before acting on them.
Who should own pricing methodology in a company?
Someone with a name. In practice it lands with product marketing, a dedicated pricing function, or the CFO's org, and it fails when it's "shared" across all three. We've argued this at length in who should own pricing in B2B SaaS.
How often should we redo pricing research?
Full study when something material changes: a new segment, a new pricing model, a serious new competitor, or a cost base that shifted. Light monitoring (discount depth, win rates by price band, NRR by plan) should be continuous.
Can pricing research tell me my packaging?
Conjoint and MaxDiff can. Van Westendorp and Gabor-Granger can't. If your open question is "which features go in which tier," you need a method that values features individually.
What's the biggest failure mode in pricing research?
Asking the wrong person. In B2B the user loves the product and has no budget, and the buyer has the budget and has never used it. Surveying the enthusiastic user produces a price you can't sell.
Does pricing methodology apply to usage-based pricing?
Yes, with adjustments. You're finding a curve rather than a point, so you have to test at several volume assumptions and treat included allowances and overage rates as separate dimensions. Conjoint handles this better than the single-price methods do.
Educational reference. Solvimon is the billing and pricing infrastructure layer: catalog, metering, rating, invoicing, and revenue in one ledger, so a pricing decision ships as configuration instead of an engineering project. See how to design usage-based pricing for the practical version.
Ready for billing v2?
Solvimon is monetization infrastructure for companies that have outgrown billing v1. One system, entire lifecycle, built by the team that did this at Adyen.
