The pricing meeting you weren't supposed to be in.

You got pulled into a meeting last quarter that wasn't on your usual circuit.

Finance was there. Someone from revenue operations. A commercial lead you'd exchanged maybe four emails with in two years. The agenda said pricing review. You assumed you were there to answer questions about the product. You were not. You were there because someone senior had finally said what a few people had been thinking quietly for a while: the people setting the price have no idea how the product actually behaves, and the people building the product have no idea what the price is doing to user behaviour.

You left that meeting with homework you hadn't expected and a vague sense that something structural had just shifted.

That sense was correct. But most PMs who land in that meeting don't act on it until the second or third time they're summoned.

For most of the history of software products, pricing was downstream of the product. The product team built the thing. The commercial team figured out what to charge for it. The two processes ran in parallel, occasionally intersected, and mostly stayed out of each other's way.

The logic was defensible. Pricing felt like a revenue question. Product felt like a user question. Different problems, different teams, different Tuesdays.

But the logic had a flaw in it that took years to surface.

Pricing doesn't just decide what a product costs. It decides how users experience it. A free tier that gives users just enough to understand what they're missing creates a different relationship with the product than a free tier that actually lets them solve a real problem. A per-seat model shapes collaboration behaviour in ways that a flat subscription never will. A usage-based model creates anxiety at exactly the moments when users should be getting value, and that anxiety shows up in engagement data whether or not anyone in the product team has connected the two.

Pricing isn't a number placed on top of the product. It's a design decision baked into the product. But for years, most product teams let someone else make it, and then wondered why the user behaviour wasn't behaving.

I was brought in to look at a SaaS product about a year ago that had a retention problem nobody could diagnose. Engagement was strong in the first thirty days. Drop-off started around the six-week mark, consistent across cohorts, and the team had tried everything they could think of on the product side. New onboarding sequences. Improved empty states. A redesigned dashboard that tested well but didn't move the retention number even slightly.

Everyone was frustrated. But nobody had looked at the pricing structure.

When I finally did, the problem was visible in about twenty minutes.

The product had a usage-based component that users hit at roughly the six-week mark as their workflows matured. Not a hard wall. A soft limit that triggered an upgrade prompt. The team knew about the limit. But what they hadn't connected was that the prompt was arriving at exactly the moment users were deciding whether this product was worth building their workflow around.

The upgrade ask wasn't landing at a moment of success. It was landing at a moment of uncertainty. The user had invested six weeks. They were starting to get real value. And the product responded by asking them to make a financial commitment before they felt secure enough to make it.

That's not a UX problem. That's a pricing timing problem. But it lived in the product experience, and nobody on the product team had the brief to look there.

The PMs I'm talking to who are navigating this well aren't the ones who became pricing experts. That's a different job. But they are the ones who started asking a different question in roadmap sessions.

Not just: what does this feature do for the user.

But: what does this feature do to the user's relationship with the pricing model.

Those are different questions. A feature that adds genuine value in isolation can create real friction when it interacts with a usage cap. A workflow improvement that increases engagement is a retention win only if the pricing model doesn't penalise the engagement it creates. The product and the pricing model aren't separate systems. But most product teams have been treating them that way, and the retention curves tell you exactly where the two systems are colliding.

The shift being asked of product people right now isn't "become a commercial person." It's narrower than that. It's: understand how the structure of your pricing shapes the behaviour of your users, the same way you understand how the structure of your onboarding shapes it.

Pricing is a UX decision made by a different team. The product person who understands that is operating at a level the one who doesn't simply can't reach.

The meeting you got pulled into wasn't an accident. Someone in your organisation has started to notice the gap.

But the question is whether you walk back into the next one with a point of view, or wait to be asked questions again.

The product teams closing this gap are finding that retention numbers, upgrade rates, and expansion revenue start behaving differently when the people who understand user behaviour are in the room where pricing decisions get made. Not because PMs are better at pricing than commercial teams. But because no one else in that room is thinking about what the price does to the person using the product at ten in the morning when they're just trying to get their work done.

That perspective belongs in the room.

And right now, in most organisations, it isn't there yet.