Pricing Is Not a Launch Decision: 7 Steps to Build a Willingness-to-Pay Habit

If you stick to the old SaaS playbook, you’re on a path to building an AI product that customers will use — but that won’t sustain your business.

In my previous article, I covered why AI product teams confuse traction for viability, and why that confusion is so easy to make. The bottom line is that traction doesn’t tell you the business works.

You can’t just hope to figure out monetization after you’ve got traction. You have to tackle it as part of your discovery approach. Make no mistake, at this level, we talk about both product and business model discovery.

Why is this so?

First, AI always comes at a cost. Unlike SaaS, where adding one more user costs you essentially nothing, you now have to pay for usage. This holds whether you call an external model or host your own. If you train your own models, add compute, data, and experimentation costs on top.

Second, and less commonly discussed, AI brings significant value upside. When you can automate entire workflows or departments, you can break out of classical software pricing and tap into labor budgets, which are 10x larger than software budgets, according to Madhavan Ramanujam of Simon-Kucher.

And that’s why the two biggest risks of building AI products are: 1) You lose money on every usage event. 2) You leave money on the table.

Both risks come down to one thing: not knowing what customers will actually pay — and whether that number can sustain your business.

So the central question becomes: what will customers actually pay for your AI product?

Enter Willingness to Pay (WTP).

WTP is a product discovery technique for testing the viability risk: will customers pay enough to sustain your business? It measures the maximum price a customer is willing to pay for your product or service and is therefore a direct reflection of the perceived value.

The problem is that WTP doesn’t always make it into product discovery. One reason is that the SaaS playbook didn’t require it. Another is that product managers aren’t always incentivized or empowered to run it.

When WTP becomes part of your discovery practice, you price from evidence and not from vibes. You know what customers will pay before you invest in scaling. And your monetization model works not just at launch, but with every major update that follows.

For AI product teams, WTP validation is the defining commercial practice.

I’ll give you some common mistakes from AI startups and growth-stage companies alike:

• Product discovery runs its full course without a single conversation about what customers will actually pay.
• WTP surfaces across product, sales, and leadership meetings but never lands as a decision. Each function assumes another will resolve it.
• Pricing gets set at launch, a customer signs, and the number gets treated as market validation for everything that follows.

These mistakes share a single root: Avoiding WTP is rational. A real finding can kill a roadmap that is already funded and defended. So the question stays off the agenda. And a signed customer at launch feels like proof, so why revisit it?

As a result, the product gets built around a price no one actually tested. This leads to a commercial model that stops working once the product starts scaling, customers who churn when the price outruns the value, and board conversations you can’t win on fundamentals anymore.

Here are seven steps to make WTP validation a continuous habit.

Step 1: Make WTP a product discovery habit

Product discovery is how you de-risk before you build.

Product discovery typically covers four dimensions: value, feasibility, usability, and viability. WTP specifically de-risks viability. It tells you whether customers will pay enough to sustain the product at the infrastructure and personnel cost you’re running.

Pricing decisions, however, belong to sales, finance, and leadership. WTP sits in discovery. That makes it a product responsibility. The gap between them is where the signal gets lost.

The problem is that no one owns WTP and someone else will eventually figure out pricing. Sales assumes product has it covered. Product assumes finance will set the number. Finance assumes it’s a launch problem.

So add WTP to your discovery habits, right alongside customer interviews and market research. The product manager’s job is to present WTP findings to product, sales, and finance before any roadmap priority or pricing decision gets locked.

The team that owns WTP continuously owns the pricing conversation in their category.

Step 2: Start with one customer segment

If your WTP data came from three different customer types, which price would you use?

WTP varies by customer type, use case, and context which all determine the WTP range. A price that works downmarket won’t work upmarket. And vice versa. You may end up undercharging the enterprise and overcharging the SMB. Both mistakes cost you real money. The segment you define determines your pricing model and value metric.

The common mistake is testing with whoever will take a meeting. One enterprise buyer, two SMBs, a startup founder. The range is wide enough to be useless for any of them.

Pick one segment and one use case before any WTP conversation. Run all testing against that pairing. Add segments in subsequent cycles.

A B2B AI company defined their segment as “enterprise product leaders with >500 employees” before running a single WTP conversation. They tested only that segment. The result was a clear price ceiling of $50K (not a useless range of $5K to $50K). They set a price, built a sales motion, and closed their first three enterprise deals at full price.

You set a price that works for a specific customer, a value metric that reflects what they care about, and a sales motion you can repeat.

Step 3: Translate features into benefits before you talk to anyone

Every WTP conversation that starts with features ends with a competitor comparison.

Feature presentations invite spec comparisons. Customers benchmark against competitors with similar lists, and the conversation shifts inevitably to price pressure.

The underlying assumption is that customers can figure out the benefits from the features on their own. They can’t. So they compare on price. The value translation hasn’t been done for them.

The translation also gets skipped because it’s uncomfortable. Map a feature to a measurable outcome, and suddenly the gap between what you charge and what you’re worth becomes visible.

Before any customer conversation, map each feature to a measurable outcome: hours saved, risk eliminated, revenue unlocked. If you can’t quantify it, the customer’s budget owner will price it at zero.

April Dunford calls this the “so what?” chain:

“We go down that list of features and we say, ‘So what? You got advanced AI, whatever the heck the thing is, so what? Why does anybody care?’ And the answer to that so what is your value. And because it came from this differentiated feature, it’s generally value that the other guys can’t deliver because they don’t have the capabilities that underpin it.”

That question is the translation. The answer is the value your customer’s budget owner can actually price.

The team that defines the outcome frame (not just the feature list) owns the category.

Step 4: Ask the two questions that do the work

Asking customers what they’d pay is one of the least reliable ways to find out what they’d pay.

Customers need an anchor, something to reason from, before they can give you a defensible price. Psychologists call this anchoring bias. In pricing, the first number mentioned often becomes the reference point. And if you’re the one who mentions it, you just set the ceiling.

The assumption is that a direct price question produces usable data. This is wrong: First, the customer anchors to the last SaaS tool they remember paying for, and suddenly your price is built on someone else’s product. Second, in new AI categories, there’s no reference point at all.

The direct question is dangerous because it feels like it worked.

The two questions to have in your repertoire are:

1. “Which of these outcomes matters most to you?”
2. “At what point would this price make you pause and reconsider?”

Stop talking after the second question. The first question anchors to value. The second uses loss aversion. The customer reasons from a price point rather than inventing one from nothing. Five conversations using this sequence will give you a price ceiling you can act on.

You enter the market with a price you can defend. In a category with no established benchmark, that’s a competitive advantage most teams never earn.

Step 5: Test the pricing model, not just the number

Changing a price takes a conversation. Changing a pricing model takes a contract renegotiation.

The SaaS era handed AI product teams one default: per-seat. They inherited it without testing whether it fits their dynamic cost structure. Test your pricing model before you sign the first customer, not after.

The assumption is that the per-seat pricing model is a safe default. Because it worked in SaaS, it will work here too. The model gets inherited because choosing it requires a commercial conversation no one wants to have before the product is proven.

Identify what your segment gets measured on: that’s the value metric. The model that maps to their accountability metric is the one they’ll sign and renew. According to Patrick Campbell, the right value metric cuts churn by 20-25% and typically doubles expansion revenue.

Present at least two pricing models in customer conversations and ask which they’d prefer and why. The why is the data. The main models to test are seat-based, usage-based, and hybrid — including credit systems that smooth out consumption unpredictability for the customer.

You scale with a commercial model built to hold. Teams that test their pricing model capture more value from every power user as the product scales.

Step 6: Choose the right experiment

Customer conversations tell you what people say they’ll pay. Purchase behavior tells you what they’ll actually pay.

Customer conversations produce stated preferences. And stated preferences are not reliable predictors of purchase behavior. In a conversation, customers say yes because they’re engaged and want to be helpful. When the invoice arrives, the answer changes. The experiment needs to make the cost real before you read the signal.

The most enthusiastic customer in the conversation is often the least likely to sign. Enthusiasm in an interview costs nothing.

So design your pricing experiment around the question you want to answer. Before you build: run a fake door test or a pricing survey (Van Westendorp for the price range, Gabor-Granger for demand drop). Once the product is live: run anchoring tests across cohorts.

A pricing page with a “get started” button and no product behind it produces behavioral intent data that twenty customer interviews cannot.

You ship with a price that real customers have already voted for with their behavior.

Step 7: Run it at every major roadmap cycle, not just at launch

Every feature you ship after launch creates value your price doesn’t capture.

When customers renew, they anchor to the original number. To them, every price increase feels like a penalty. The value accrued is invisible to them. Each release cycle, the gap between price and value grows. At renewal, the customer anchors to a number that reflects the product from twelve to eighteen months ago.

The assumption? If customers are renewing, the price must still be right. WTP was confirmed at launch. The product works. No signal that the price is wrong. Until a competitor launches at a price that reflects actual value. Then the conversation changes.

Build a WTP review into every major roadmap cycle. The owner named in Step 1 presents findings at the quarterly planning meeting before priorities are set. Pricing decisions made before contracts are signed can be adjusted. After, they cannot.

You price against what the product is worth today. And customers renew at a number that reflects the value they’re actually getting today and not the value you shipped a year ago.

That’s it.

Chat soon, Hayder