SaaS pricing isn't a marketing decision — it's a product decision

Most B2B founders treat SaaS pricing like a number. They look at what competitors charge, pick something in that range, maybe test two price points on the landing page, and move on. The decision feels made.

It isn't. What they've actually done is delay three harder decisions until the product forces them to surface. And by then, fixing them is expensive.

Pricing is not a dial you turn at the end of the build. It is a statement about who the product is for, a commitment to a roadmap, and the equation that determines whether your customer acquisition motion makes economic sense. Get it wrong early and you don't just leave revenue on the table — you build the wrong features for the wrong customer at the wrong price for two years before you realise it.

What SaaS pricing is actually deciding

When you set a price, you are not picking a number. You are picking a unit of value — the thing a customer is paying for when they pay you.

A per-seat price says: the value is access. The more people using the product, the more it is worth. A per-transaction price says: the value is each workflow completed. A flat-rate price says: the value is the capability itself, and you're betting the gap between your cost to serve and the market's willingness to pay.

Get the unit wrong and the number is irrelevant. A per-seat model for a document-workflow product makes expansion revenue hostage to your customer's headcount decisions, which they make for reasons entirely unrelated to you. A per-transaction model for a collaboration tool charges your most engaged customers more precisely when they're most engaged. Sometimes that's the right signal. Often it punishes the behaviour you want to encourage.

Stripe charges per transaction. That metric works because each transaction is a discrete unit of value and the more transactions Stripe processes, the more infrastructure and risk it takes on. The metric reflects the actual cost and value structure of the business. Most SaaS products have a very different cost structure — but they still default to per-seat pricing because that's what the category uses.

The unit of value is a product decision. It determines what you instrument, what you optimise for, and which customers your pricing model rewards for growing.

Price is a positioning statement

Price signals who the product is for, as loudly as your homepage copy. This is not a soft observation. It has hard downstream consequences.

A $29/month self-serve plan says: this product is for small teams and individuals. It works without a sales call. You can start without commitment. The onboarding is designed to get someone to value in minutes, not weeks. That is a product commitment, not just a number.

A minimum annual contract of $5,000 says: we expect a buying process. Probably involving procurement, possibly legal review, almost certainly a conversation with a real person before money changes hands. We have built the features that justify it: SSO, audit logs, admin controls, role-based access. That is also a product commitment.

When Notion raised prices on its business tiers in 2023, it was not simply capturing more revenue. It was signalling that the product had repositioned from personal productivity to team infrastructure. The pricing change was the product pivot, communicated in the one language every stakeholder reads: the bill.

This is why price changes land harder than feature changes. When you change a feature, you're changing the product. When you change the price, you're changing the implicit contract about who the product is for. Customers who signed up under one identity feel misled when you reveal another.

Price shapes what you build

The roadmap follows the revenue model. This is not a figure of speech.

At $29/seat, you need high retention and low churn to make the unit economics work. That pushes the roadmap toward stickiness — integrations that embed the product in daily workflows, templates that get new users to value quickly, notifications that bring people back when they drift. Every feature that improves daily habit protects revenue.

At $500/seat enterprise, you need to win larger deals and justify higher total cost of ownership. That pushes the roadmap toward admin controls, compliance certifications, audit logs, and customisation. Stickiness matters less than features that pass a security review and satisfy a procurement team.

These are not the same product. A team that tries to serve both price points simultaneously usually ends up building features that matter to neither customer well. The roadmap negotiates endlessly between opposing requirements, and neither segment gets what they need.

Datadog ran into this deliberately. They moved from a flat per-host pricing model to usage-based billing in their early growth phase. Not because per-host was wrong at the start — it was the right model to get the first customers in — but because usage-based better reflected how enterprise customers consumed monitoring infrastructure at scale, and enterprise was where the product needed to go. The pricing change forced clarity on the roadmap: what got built next had to serve the customers who would grow fastest under usage-based billing.

The companies that move upmarket successfully almost always have a deliberate break point: this is when we stop building for the bottom of the market and start building for the top. The pricing change follows the product decision. It does not precede it.

Price determines how you sell

There is a rough threshold — call it $1,500 ACV — below which human-assisted selling almost never makes economic sense. Above roughly $10,000 ACV, pure self-serve rarely closes deals large enough without at least some human involvement at the right moment.

These numbers shift with market and category. The point is that your price sets the economics of your customer acquisition. At $49/month flat, acquiring 17 new customers per month is required to hit a $100,000 annual sales quota. At $499/month, two customers achieves the same. These motions look nothing alike, and they require completely different teams, tools, and content.

A founder doing personalised outreach at $29/month is working against the economics of their own pricing. A product trying to close $6,000 ACV deals through a frictionless self-serve funnel is leaving conversion to chance exactly when a conversation would close it.

Neither is an error in execution. Both are errors in the relationship between price and motion. And fixing the motion without changing the price — or fixing the price without changing the motion — rarely works.

The three decisions inside SaaS pricing

Most teams treat SaaS pricing as one decision. It is three, and the most important one is not the number.

The metric. What do you charge for? Seats, usage, transactions, storage, API calls, active users? The metric determines which customers grow your revenue, which churn, and what you need to measure. Change the metric and the entire revenue model changes, even if the number stays the same.

The packaging. What is in each tier? Packaging determines what capabilities you gate, which customers land where, and whether expansion revenue exists at all. A single-tier product has no expansion path. A poorly designed two-tier product either gives too much away at the bottom or charges too much at the top. Good packaging creates a natural migration path as customers grow.

The number. The price itself. Most founders spend most of their time here, and it is the least important of the three — because a wrong metric or wrong packaging structure will not be rescued by picking the right number.

Start with the metric. Build packaging around your customer segments and the natural expansion motion you want. Set numbers that reflect your cost to serve and your market's reference points. Most teams do this in reverse: they pick a number first, choose two or three tiers to justify it, and then reverse-engineer a metric.

Why repricing is harder than it looks

Existing customers get emotional about price changes in a way they rarely do about feature changes. A feature removal generates support tickets. A price increase generates cancellations and, in some cases, public complaints.

The pain scales with two variables: how far you are moving, and how long customers have been at the old price. A team with 400 customers at $49/month who wants to move to $199/month for new customers faces a compounding problem. The existing base is economically grandfathered at a price that no longer reflects the product's value. New customers see a higher price and wonder why others pay less. Both groups end up with questions the pricing cannot cleanly answer.

The teams that reprice most cleanly almost always do one specific thing: they change the metric, not just the number. Moving from per-seat to per-document, or from flat-rate to usage-based, reframes the conversation entirely. It is not 'you are paying more for the same thing.' It is 'we have changed what you pay for, because the basis on which you get value has changed.' That narrative exists. It is defensible. Customers can accept it.

Raising the number alone gives customers one narrative: the company wants more money. Some will stay anyway. Some will leave. But there is no version of this story where the company looks like it is doing the customer a favour.

The deeper issue is that repricing almost always reveals a product gap. A team moving from $49/month to $199/month finds, six months in, that the customers who convert at $199 expect things the product does not yet have. That gap was always there. The price change just made it visible by attracting customers whose expectations the product cannot currently meet.

A practical starting point

If you are at the beginning of pricing a new product: start with the metric. Ask what unit of value customers get from this product, and which customers get more of it in a way that shows up measurably. That answer almost always points at the right metric.

If you are reconsidering your current price: resist the reflex to move the number. The better question is whether your current metric still reflects how customers experience value. If the customers growing fastest are exactly the ones your pricing model rewards, the metric is probably right. If the model rewards customers who are not actually your best customers, fix the metric.

If you are about to close a large deal that requires a pricing tier you have never offered: the deal is useful signal. But a tier designed for one customer is a support burden and a credibility problem for every future negotiation. Build the tier for the segment, not the customer.

And if someone tells you to just test a higher price and see what happens — that is not bad advice, but it is incomplete. A conversion test tells you whether prospects will pay more for the current product. It tells you almost nothing about what you will need to build to serve the customers who convert at the higher price.

SaaS pricing is a product decision. The number comes last.