How to Validate SaaS Pricing During Customer Discovery

Pricing often gets treated as a decision to make after building, once real usage data exists. But waiting until after launch to think seriously about pricing means missing an opportunity to validate it during the exact process — customer discovery — that’s already designed to surface how much a problem matters to people. Here’s how to fold pricing validation into discovery itself.

Why Pricing Belongs in Discovery, Not After

Pricing isn’t just a number attached to a finished product — it’s a direct test of how much value customers believe your solution provides relative to their alternatives. Discovery interviews are the ideal place to start gathering that information, because you’re already asking about the problem’s cost and the customer’s current situation, both of which directly inform what a reasonable, defensible price looks like.

Understand Current Spend Before Asking About Future Price

The most reliable pricing-related question in a discovery interview isn’t “what would you pay for this” — it’s “what are you currently spending, in tools, time, or money, to deal with this problem?” Understanding existing spend gives you a grounded reference point. If a prospective customer already spends $200 a month cobbling together spreadsheets and part-time help, a $50 monthly tool that solves the problem cleanly has an obvious value story; if they’re spending nothing and barely notice the problem, a similar price point is a much harder sell.

Ask About Budget Categories and Approval, Not Just a Number

For B2B SaaS especially, understanding which budget category a purchase would come from, and what approval process it would need to go through, matters as much as the raw price point. A $500 monthly tool that fits neatly into an existing software budget faces a very different adoption path than the same price requiring new budget approval from someone who’s never bought a tool like it before. This connects to the broader SaaS discovery framework in customer discovery questions for SaaS founders.

Test Reactions to a Specific Price, Not an Open Question

Rather than asking an open-ended “what would you pay,” present a specific, realistic price and gauge the reaction. “If this were priced at $99 a month, how would that feel — too high, too low, about right?” produces more grounded, useful information than an abstract question, because it forces the person to react to something concrete rather than invent a number from nothing.

Watch for Segments With Different Pricing Tolerance

As you talk to a range of prospective customers, you may notice meaningfully different reactions to the same price point across different segments — a larger company might find a price trivial while a smaller one finds it significant. This is valuable information, not noise, and often points toward the need for tiered pricing or a clearer initial target segment.

A Simple Pricing Discovery Framework

Discovery Question	What It Reveals
“What do you currently spend on this problem?”	Realistic budget reference point
“Who would need to approve a purchase like this?”	Buying process and friction
“How does [specific price] feel to you — too high, too low?”	Reaction to a grounded, concrete number
“What would need to be true to justify that price?”	Value threshold and unmet expectations

Avoiding Common Pricing Discovery Mistakes

The most common mistake is asking about pricing too early, before the customer has described the problem’s real cost and their current spending in detail — an abstract pricing question asked in isolation produces an abstract, unreliable answer. The second most common mistake is treating a single enthusiastic “sure, I’d pay that” response as confirmed pricing validation, rather than testing the reaction across multiple, independent conversations. For a deeper look at that specific pitfall, see how to discover what SaaS customers would actually pay for.

From Discovery to a Defensible Price

Pricing validated through real discovery conversations — grounded in actual spend, real budget context, and reactions to specific numbers — gives you a far more defensible starting price than a number chosen by comparing yourself to competitors or guessing at what “feels right.” It won’t be perfect, but it starts from evidence rather than assumption.

Frequently Asked Questions

Should I ask directly what customers would pay during discovery interviews?

Direct hypothetical pricing questions are unreliable on their own. It's more useful to understand what customers currently spend on the problem, and to test reactions to a specific, real price rather than an open-ended question.

What's the Van Westendorp method and is it useful for SaaS pricing discovery?

It's a survey technique that asks at what price a product would feel too cheap, a bargain, expensive, or too expensive, which can help identify a reasonable price range. It works best as a complement to interviews, not a replacement for direct conversation.

How early should pricing come up in discovery interviews?

Generally later in the conversation, after you've understood the problem, its cost to the customer, and their current spending, so pricing discussion is grounded in real context rather than an abstract, disconnected question.

What if different customer segments have very different pricing expectations?

This is common and useful information — it may indicate you need distinct pricing tiers, or that one segment is a stronger initial target than another based on both need and willingness to pay.

Can pricing validation happen without existing customers?

Yes. Discovery interviews with prospective customers, combined with an understanding of what they currently spend solving the problem, can meaningfully inform pricing even before you have a single paying customer.