How to Discover What SaaS Customers Would Pay For

Founders often assume customers will pay for the feature that took the most effort to build, or the one they personally find most impressive. In practice, customers pay for outcomes — problems solved, time saved, risk reduced — and those outcomes don’t always map onto the features founders expect. Discovering what customers would actually pay for requires asking different questions than discovering what they’d merely enjoy having.

Customers Pay for Outcomes, Not Features

A customer doesn’t fundamentally want “AI-powered scheduling automation” — they want to stop losing hours each week to manual coordination, or to stop double-booking appointments that cost them client trust. The feature is the mechanism; the outcome is what they’re actually willing to spend money to achieve. Discovery interviews that focus on outcomes tend to reveal much clearer pricing signals than interviews that ask people to react to a feature list.

Ask About the Outcome They’re Trying to Reach

Rather than describing your product’s capabilities and asking for reactions, ask what the customer is ultimately trying to achieve, and what’s currently getting in the way. “What would need to be true for you to feel confident this problem is handled?” often reveals the real outcome being sought, which may be narrower — or different — than the full feature set you had planned to build.

Separate What People Like From What They’d Pay For

It’s entirely possible for a customer to genuinely enjoy a feature during a demo or conversation while still not being willing to pay extra for it. Test this distinction directly: after describing a specific capability, ask “if this were a separate add-on at an additional cost, would that be worth it to you, or would you expect it included?” The answer often reveals which parts of your product are core value drivers and which are pleasant extras.

Use Real Spend as a Value Yardstick

Understanding what a customer currently spends — in money, time, or a combination — to achieve a similar outcome gives you a grounded sense of how much value they place on solving the problem. If a business currently pays a part-time employee several hours a week to manually handle something your software could automate, that existing cost gives you a realistic sense of what they might be willing to pay for a solution, discussed further in how to validate SaaS pricing during customer discovery.

Watch for the Specific Moment Value Clicks

During interviews, pay close attention to the moment — if it happens — when a customer’s tone shifts from polite interest to genuine engagement, often marked by them asking practical questions like “when could this be available” or “how would this actually work for my team.” That shift usually corresponds to the exact outcome or capability that matters most to them, and it’s worth noting precisely what triggered it.

A Simple Discovery Framework

Question	What It Reveals
“What outcome are you ultimately trying to reach?”	The real value driver, not just a feature list
“What’s stopping you from reaching it today?”	The specific gap your product needs to close
“Would you pay extra for [specific capability] as an add-on?”	Whether a feature is core value or a pleasant extra
“What do you currently spend solving this?”	A grounded reference point for pricing

Avoiding the Trap of Building What’s Interesting

It’s easy, especially for technically minded founders, to gravitate toward building the feature that’s most interesting or impressive to develop, rather than the one customers have actually indicated they’d pay for. Regularly cross-checking your MVP scope against what discovery interviews revealed about real, paid-for value helps keep development effort aligned with what the business actually needs to succeed — see how to turn customer discovery into an MVP feature list for the broader process this fits into.

From Discovered Value to a Focused MVP

Once you understand which specific outcome customers are genuinely willing to pay to achieve, you can scope an MVP tightly around delivering that outcome well, rather than spreading effort across a broader feature set that includes plenty customers like but few would actually fund.

Frequently Asked Questions

Why is it hard to know what customers will actually pay for?

Founders often assume the feature they find most technically impressive is the one customers value most, but customers usually pay for outcomes — time saved, risk reduced, revenue gained — not for features in themselves, and those two things don't always align.

How do I find out what part of my SaaS product customers value most?

Ask customers directly what outcome they're trying to achieve and what's currently stopping them, rather than asking which features they like. The outcome they describe usually points to what they'd actually be willing to pay for.

Should I test willingness to pay for individual features or the whole product?

Both can be useful. Testing the whole product tells you if the overall value proposition works, while testing reactions to individual capabilities can reveal which specific parts are actually driving willingness to pay versus which are just nice additions.

What if customers say they love a feature but won't pay extra for it?

This is common and important — genuine liking doesn't always translate into willingness to pay. Treat features people won't pay for as valuable for retention or satisfaction, but not necessarily as core to your pricing or MVP scope.

How does this discovery process change what goes into an MVP?

Understanding what customers would actually pay for helps you prioritize the MVP around the outcomes with the clearest, most defensible value story, rather than the features that are most interesting to build.