Pricing is a product decision, not a marketing one

The typical SaaS pricing review looks like this: someone opens a spreadsheet, checks what competitors charge, reads a blog post about value-based pricing, maybe runs a few customer calls. The number on the pricing page changes. Everyone goes back to their actual work.

Three months later, conversion is still flat. The problem is not the number. The decisions that actually move conversion from free to paid are not on the pricing page at all. They live inside the product: in feature gates, upgrade prompt timing, and trial structure. These are product decisions, and in most teams nobody owns them.

Where the real pricing decisions live

A useful test: imagine your pricing page went offline for a week. How much would conversion drop? For most B2B SaaS products, not much. Buyers who discover you through a trial or word-of-mouth rarely see the pricing page first. They see the product. They decide whether it's worth paying for based on what they experience in that first session. The pricing page is where they confirm the number, not where they decide whether to buy.

The decisions that shaped that first experience were all made during product development: which features they had access to, when they hit a limit, whether they saw anything that made them want more. Your marketing team probably doesn't know what's in the feature gate configuration. Your engineers probably think someone else made those decisions intentionally. This ownership gap is where most pricing problems live.

Feature gates are the pricing decisions that actually drive upgrades

When you decide which features live on the free plan and which ones require upgrading, you're setting the shape of your conversion funnel. Get it wrong and the economics won't recover, regardless of how competitive your price point is.

The most common mistake is gating features that new users need to see your product's core value. If someone signs up for a project management tool and can't invite a teammate without upgrading, they'll leave before they've decided the product is worth anything. You've put the paywall in front of the value, not behind it. The second most common mistake is the opposite: gating too little, so the free plan is so capable that users complete their primary workflow indefinitely without a reason to upgrade.

Gates that work follow a consistent pattern: they restrict things that matter more as the user's use of the product scales. Collaboration features, admin controls, audit logs, API access, bulk operations. These are features that solo or early users rarely need but growing teams want badly. Gate those, not the features someone needs to get value on day one.

The upgrade prompt timing problem

Assume you have the gates right. You still have to ask for the upgrade, and when you ask matters more than most teams realise. The reflex is to show the upgrade prompt the moment a user hits a limit. They try to add a fourth project, the limit is three, and up pops a modal: 'Upgrade to add unlimited projects.'

This converts poorly. The user just hit a wall. Their emotional state is frustration, not aspiration. The message they receive is that this product has a ceiling, and some decide the product isn't for them. Not because of the price, but because the friction landed at the wrong moment.

Prompts that convert well appear at a different moment: right after a genuine win. The user completed their first meaningful workflow, shared something with a colleague, reached the outcome the product is designed for. At that point the prompt can be aspirational: 'you can do this for three more projects on Pro.' The emotional context is positive. They've already concluded the product is useful; the prompt is an invitation to use it more. Knowing when users have their win moment requires product instrumentation and event analysis. It is engineering work, not something fixed by writing better modal copy.

Your trial design is a pricing decision

There are three basic trial structures, and the choice between them is a pricing decision most founders make by default.

Time-limited trials (14 days, 30 days) are the most common because they're easy to implement. The problem: users often don't reach the value moment within the window. The trial ends not because they decided against the product, but because they ran out of time before getting deep enough.

Feature-limited trials (freemium) give users an indefinite experience with a restricted feature set. This works when the free tier is designed as a conversion funnel: useful enough to demonstrate value, limited enough to create upgrade pressure. Most freemium plans fail because the gate structure wasn't thought through. Either too limited to demonstrate value, or too capable to create a reason to upgrade.

Usage-limited trials set a cap on a meaningful unit: reports generated, API calls, documents sent, rows processed. These often outperform time-limited trials because the limit appears at the user's natural scale point, not at an arbitrary calendar date. The user runs out of capacity when doing real work, not after a fortnight of occasional exploration. Choosing between these structures is not a question for a quarterly pricing review. It is a product architecture decision with long-term implications for instrumentation, billing infrastructure, and conversion mechanics.

What the pricing-as-product team actually does differently

Teams that get this right don't necessarily have a different price. They have different ownership.

Someone on the product team owns the upgrade flow as a product surface. Upgrade prompts get A/B tested the way features get A/B tested. The team instruments moments before upgrade, asking what the user was doing in the 30 minutes before they converted, and uses that to inform gate placement and prompt timing.

The free plan has its own retention and engagement goals. If free-plan users are churning before they see the product's core value, that's treated as a product problem, not a marketing problem. Feature gate decisions get reviewed alongside product decisions, not separately. When a new feature ships, the question of which tier it belongs to is part of the spec, not an afterthought.

This doesn't require a new role. It requires a team that has agreed these are product problems and has someone who owns each one.

Your pricing page matters less than your pricing decisions. The next time you run a pricing review, skip the competitor spreadsheet and go to the product instead. What are you gating, and does it map to where users find value? When do upgrade prompts appear, at a wall or after a win? How does the trial end, in frustration or at the moment of real usage? Those questions won't be answered in a spreadsheet. They'll be answered by whoever owns the product.