Who Owns Pricing? (And Why The Question Itself Is Broken)
A pricing decision got made without your consent. Now you're explaining to customers why a feature they relied on just moved to a higher tier. This is what the strategy execution gap looks like.
I found out about a pricing change to my product through a customer support ticket.
Not an internal memo. Not a heads-up from the revenue team. A confused customer asking why they’d lost access to a feature they’d been using for eighteen months.
I walked over to the RevOps lead’s desk. “When did we change the packaging on the analytics module?”
He looked genuinely surprised that I was surprised. “That went live two weeks ago. It was in the pricing committee notes.”
Reader, I was not on the pricing committee. I was not invited to the pricing committee. I did not know there was a pricing committee.
The Organisational Fiction We’ve All Accepted
Here’s the official story most companies tell themselves about pricing:
Product management defines what gets built. Finance and RevOps define what it costs and how it’s packaged. Clean separation of concerns. Everyone stays in their lane. Decisions get made by people with the right expertise.
Here’s what actually happens:
Pricing decisions shape what gets built, because features only matter if customers can access them. Packaging decisions determine which users experience which value, which changes what “product-market fit” even means for different segments. Tier structures create incentives that influence user behaviour, which feeds back into product strategy.
And PMs, the people supposedly responsible for value creation, often learn about these decisions after they’ve been made.
The separation isn’t clean. It’s a convenient fiction that lets organisations avoid the harder question of how these deeply intertwined decisions should actually be coordinated.
Pricing isn’t downstream of product. It’s part of product. Pretending otherwise just means the integration happens badly instead of well.
Why This Split Exists (And Why It Persists)
I’m not suggesting this happened by accident. There are real reasons organisations separate pricing from product management.
Pricing requires financial modelling expertise. Understanding price elasticity, revenue impact analysis, competitive positioning from a monetisation perspective. These are genuine skills that most PMs don’t have and probably shouldn’t spend years developing.
There’s also the political dimension. Pricing decisions have direct P&L impact. Finance and revenue teams have accountability for numbers. Giving PMs pricing authority means giving them power over metrics they don’t formally own. That makes executives nervous.
And honestly, many PMs don’t want this responsibility. Pricing involves difficult conversations with sales about deal flexibility. It means telling customers why things cost what they cost. It requires defending decisions that will make some users unhappy. Building features is more fun.
So the separation persists. RevOps handles pricing. PMs provide “input.” And the strategy execution gap quietly widens.
The Gap Nobody Talks About
Here’s where this connects to something larger.
Most product strategies include assumptions about value delivery. We’re building Feature X because it solves Problem Y for Segment Z, and that’s worth paying for.
But the translation from that strategy to actual revenue depends entirely on pricing and packaging decisions. Which segment gets access to Feature X? At what price point? Bundled with what other capabilities? Available in trials or only after purchase?
These aren’t implementation details. They’re strategic choices that determine whether your theory of value creation actually works.
When PMs aren’t involved in pricing, you get a specific failure mode. The product team builds something valuable. The pricing team packages it based on their model of what maximises revenue. And the two models don’t match.
I’ve seen this play out repeatedly. A feature designed for mid-market adoption gets packaged into the enterprise tier because that’s where revenue thinks it belongs. A capability built to drive viral growth gets put behind a paywall because finance wants to capture more value. A differentiation bet gets buried in a bundle where nobody notices it because packaging was optimised for upsell paths, not user experience.
The strategy said one thing. The pricing said another. And the product ended up serving neither goal well.
The RevOps Perspective Isn’t Wrong
Before this becomes a “PMs should own everything” argument, let me steelman the other side.
Revenue operations exists because monetisation is genuinely complex. The people who do it well understand things that product managers typically don’t. Price sensitivity analysis. Discount impact on lifetime value. Channel conflict in packaging decisions. Competitive pricing intelligence.
When PMs meddle in pricing without this expertise, bad things happen. Prices get set based on gut feel. Packaging gets designed around feature logic rather than purchasing psychology. Discounting becomes arbitrary. Revenue becomes unpredictable.
I’ve watched a PM insist that a feature “felt like” it belonged in the growth tier despite data showing it was the primary driver of enterprise conversions. Their instinct was wrong. The RevOps analysis was right. The feature stayed in enterprise, and revenue performed as modelled.
There’s also the question of focus. PMs already own too much. Adding pricing responsibility means something else gets less attention. If you had to choose between a PM who deeply understands their users or a PM who deeply understands pricing mechanics, most organisations would choose the former.
The RevOps counterargument isn’t just turf protection. It’s a legitimate position about specialisation and expertise.
But The Current Model Is Still Broken
That said, the current model in most organisations doesn’t work either.
The “PM provides input” structure treats pricing as a downstream decision when it’s actually a concurrent one. By the time RevOps is asking for PM input, the key strategic choices have often already been framed. The PM is picking between options that all miss the point.
I remember being asked whether Feature A should be in Tier 2 or Tier 3. The right answer was that the tier structure itself was wrong, that we needed a usage-based component that didn’t exist in either tier. But that wasn’t on the table. The framing had already been set.
This is the translation layer problem. Strategy gets made at one level. Pricing decisions get made at another. The translation between them is weak or nonexistent. And the people who understand the user value best aren’t present when the monetisation architecture gets designed.
“PM provides input” often means “PM validates decisions after the important choices have been made.”
What Good Looks Like
I’ve seen organisations handle this well. It’s not that common, but the patterns are recognisable.
Pricing and product strategy are developed together, not sequentially. When the product team is defining a new capability, the revenue team is already modelling how it might be monetised. The conversation happens in parallel, with both perspectives informing the other.
PMs have genuine influence over packaging, even if not final authority. There’s a difference between “input” and “influence.” Input means you give your opinion and someone else decides. Influence means your perspective materially shapes the outcome, and decisions that override it require explicit justification.
Tier and packaging structure reflects user value architecture, not just revenue optimisation. This is subtle but important. Good packaging makes sense to users because it maps to how they experience value. Bad packaging makes sense only in spreadsheets.
There’s a shared language for discussing value. The PM talks about user problems and outcomes. RevOps talks about willingness to pay and conversion rates. In good organisations, these aren’t parallel conversations. There’s a shared understanding that connects user value to monetisable value.
Pricing reviews include product representation, and product reviews include pricing representation. If your pricing committee doesn’t include product, you’ve decided that monetisation and value creation are separate concerns. They’re not.
The Organisational Design Question
This is ultimately about organisational design, not individual responsibility.
Some companies solve this by making PMs responsible for pricing. This works when you have PMs with commercial sophistication and finance teams willing to share authority. It falls apart when PMs lack the skills or when the accountability structures don’t support it.
Other companies solve this with cross-functional pods where product and revenue work together from the start. This works when the pods have genuine autonomy. It falls apart when central functions override pod decisions.
Still others create hybrid roles. Product marketing or commercial product managers who sit between product and revenue. This works when the role has real authority. It falls apart when it becomes a coordination tax without decision rights.
There’s no universal answer. The right structure depends on your company’s size, your sales model, the complexity of your pricing, and about a dozen other factors.
What I can tell you is that the structure needs to be designed, not defaulted into. Most companies don’t have a deliberate model for how pricing and product decisions connect. They have an accidental one. And accidental structures tend to create gaps.
Signs You’re In Trouble
A few patterns that suggest the pricing-product interface is broken in your organisation:
Customers are confused by your packaging. If support tickets regularly include “why isn’t this feature in my plan” or “I don’t understand what I’m paying for,” your packaging probably wasn’t designed with user logic in mind.
Features ship and then get repositioned in tiers. This happens when pricing and product are on different timelines. The product team ships, then revenue figures out where it belongs. That sequence is backwards.
PMs can’t explain the pricing rationale. If you ask a PM why a feature is in Tier 3 versus Tier 2 and they don’t know, the integration is too weak. Even if they don’t set prices, they should understand the logic.
Pricing changes surprise internal teams. If sales, support, or product learn about pricing changes late, the communication structure is broken. This usually indicates that pricing is siloed rather than integrated.
Your strategy documents and your pricing structure tell different stories. The strategy says you’re targeting mid-market growth. The pricing is optimised for enterprise extraction. Someone’s wrong, and nobody’s reconciling the contradiction.
What You Can Actually Do
If you’re a PM without formal pricing authority, you’re not powerless. But you have to be deliberate.
Build a relationship with your RevOps or pricing counterpart. This sounds basic, but it’s rare. Most PMs interact with revenue teams only during planning cycles or when something goes wrong. Regular, informal conversations build the context that makes formal collaboration possible.
Learn enough about pricing mechanics to be credible. You don’t need to become a pricing expert. But understanding concepts like price elasticity, anchor pricing, and packaging psychology makes your input more valuable. RevOps teams dismiss PMs who talk only about features and users.
Frame your input in revenue terms, not just user terms. “This feature should be in the lower tier because users expect it there” is weak. “This feature in the lower tier increases activation by 20%, which drives upgrade conversion, which the data shows is worth more than direct tier revenue” is strong.
Ask to be included earlier, not just more often. Don’t ask for a seat at the pricing committee. Ask to be involved when the pricing structure is being designed, before decisions are framed. That’s where the leverage is.
Document when pricing and product strategies conflict. Not as a gotcha, but as a diagnostic. If your feature roadmap assumes one thing and your pricing assumes another, someone needs to reconcile that. Making the conflict visible is the first step.
The Honest Answer
Should PMs own pricing? The honest answer is: it depends, and most organisations haven’t thought carefully about where the boundary should be.
The pure PM position (pricing is core to product) overstates what most PMs can realistically own and understates the genuine expertise that revenue functions bring.
The pure RevOps position (PMs just provide input) understates how deeply pricing shapes product value and overstates how cleanly these domains can be separated.
The right answer is probably somewhere in the middle, with PMs having significant influence over packaging architecture and value positioning, while RevOps owns the commercial mechanics and financial modelling. But that middle ground requires deliberate design and ongoing coordination.
Most companies don’t have that. They have an unclear boundary, a few frustrated people on both sides, and a strategy execution gap that nobody quite knows how to close.
That pricing committee I mentioned at the start? I eventually got invited to it.
What I found wasn’t a cabal making decisions in secret. It was a group of revenue people trying their best to make good packaging choices without the context they needed to make them well.
They didn’t exclude product out of malice. They excluded product because nobody had designed a structure that included us. And in the absence of design, defaults took over.
The gap wasn’t created by bad people. It was created by nobody owning the integration.
That’s usually how these things work.