Pricing velocity is an ownership problem

Insights
Read time: 11 min

Arnon Shimoni
✓ Expert opinion
In all companies I've worked at, I could name a pricing owner on the org chart, but mostly they were figureheads.
As I do a lot of consulting on pricing, it usually goes in many different directions. For example:
Finance says it's a margin question, so theirs.
Product says it's a packaging question, so theirs.
Sales says it's a deal question because it affects their compensation.
RevOps says it's a systems question.
However, somewhere in the building there's an engineer who built billing v1 and knows the real answer is "me" because they're the only person who can actually change anything.
That last one is the problem. I was in that position (granted, as a product manager, but me and my team felt ownership). We weren't wrong, but that was because no one else decided about who owns pricing - we just let it happen.
So let me give you the answer I'd defend in any room.
Pricing should have one accountable owner, and it should be the CEO, the CTO, or the CPO.
Plenty of people feed that decision, but only one person makes it.
Two different questions hide inside "who owns pricing"
Most of the confusion comes from the conflating of those two questiosn.
The first is who decides pricing. What's the model, what's the unit, what does a credit cost, where do we run the next experiment, and what do we call it. That's a strategic call for most companies.
The second is who can change pricing. Who has their hands on the rate card, who ships the change, who can run a cohort experiment without filing a ticket, and who actually sets the name on the website.
In a healthy setup these are different people doing different jobs.
In lots of cases however, it's the same person (again, that was me) - but it was by accident.
Originally, I didn't ask for strategic ownership. I got it because changing pricing requires touching code that I owned, and touching code required… well, me.
So the ceiling on what the business can price became whatever that me and my team could build and was willing to maintain... which is a strange way to run your most important commercial lever.
The accidental owner is likely most senior billing engineer
Billing isn't taught anywhere. There's no certification, no curriculum, no community of practice the way there is for security or ML. Everyone who knows billing learned it by building it, usually once, usually at one company, usually because building felt faster than evaluating.
That builds real expertise and real ownership (the IKEA effect is strong, you trust what you made). It also builds a single point of dependency.

In Kyle Poyar's 2026 State of B2B Monetization data puts a number on the cost: at $150M+ ARR, 29% of companies still hold onto legacy seat-based pricing, the highest share of any cohort. These are the companies with the deepest billing teams and the most entrenched systems. The expertise and the lock-in turn out to be the same thing.

The pricing manager feels this most clearly. They're the one person who understands the system well enough to change it, which makes them the person most aware of how expensive every change is. So they propose fewer experiments. The business gets less pricing intelligence every quarter, and nobody chose that outcome. The architecture chose it.
That's an accidental owner. Useful, expert, indispensable, and exactly the wrong person to be the ceiling.
Why the maker is the CEO, CTO, or CPO
Pricing used to be a finance exercise bolted onto a stable product. Set the list price, discount on the deal, recognize revenue evenly. You could let it live in a spreadsheet and a quarterly review.
That's not the job anymore. When the unit of value is a credit tied to a model whose cost moves whenever OpenAI or Anthropic moves, pricing becomes a product decision with a margin clock attached. GitHub's June 1 2026 change is the clean example, the old SKU was a "premium request," the new one is AI Credits in cents with per-model multipliers (Opus at 27x, Sonnet at 9x, GPT-5 at 6x). The unit of value moved underneath them and the price had to move with it. That's not a thing you delegate to whoever has time.
So the maker has to be someone accountable for the whole shape of the business, not one function inside it:
The CPO owns it when pricing is fundamentally a product and packaging decision (credits, ratios, what's metered, what's bundled).
The CTO owns it when the bottleneck is architectural, the rate card is a system artifact and the question is whether it can bend at all.
The CEO/founder owns it at the stage where pricing is the strategy, and the credit-to-token ratio is a first-class number they read, change, and audit.
RevOps, Finance, Sales, the pricing manager, they all feed this. They bring the margin report, the deal friction, the cohort data, the reconciliation reality. They're essential as inputs. They just aren't the decision, because pricing by committee moves at the speed of the slowest committee member, and the market isn't waiting.
One owner only works if the architecture lets them move
Most "fix your pricing ownership" advice kinda stops working at this next point:
You can put the CPO's name on pricing in the org chart, but if every change still routes through the one engineer who built billing v1, you haven't moved ownership.
Naming an owner and giving them an architecture that can't bend is how you get a frustrated executive and an overloaded engineer, both technically correct, both stuck.
So the ownership question and the agility question are the same question. A single accountable maker is only real if the rate card is a thing that can change without a platform release and without that one person's approval on every move.
That's what headless monetization is for. The rate card becomes one versioned, queryable artifact instead of a property buried in someone's code. The decision sits with the maker. True meritocracy!
The operation is available to everyone who needs it, across four surfaces over the same source of truth:
The pricing manager edits the rate card in a UI built for that job.
RevOps / SalesOps runs bulk changes through the CLI when 400 contracts need a coordinated update.
Product embeds billing into onboarding and upgrade flows through the API.
The agent (a real human that is - support, sales, procurement) needs to access all of these details. You know what, even if it's an agent operating through MCP, with the same permissions and the same audit trail as a human.
So nobody owns the whole thing by holding it in their head. The maker decides, the surfaces execute, and the system is the source of truth instead of the person who built it. At least versioning means a bad change is reversible.
Introducing the Pricing Velocity Index (PVI)
Two things are happening to pricing at once, and they pull in opposite directions.
The stack is getting deeper: A "hybrid" plan used to mean a subscription with a usage line on top. A typical hybrid now runs five mechanisms at the same time: a subscription, a usage meter, a credit pool, seats, and some flavor of overage or platform fee. Kyle Poyar's data again backs this change as hybrid pricing went from 25% to 37% adoption in a year and AI credit models grew 126%. It's getting stacked, not simplified.
…. but almost nobody got faster at changing any of it.
That tension is the whole game, so it's worth a number. Call it the Pricing Velocity Index:
PVI = how many pricing mechanisms you can change / how long it takes to change one
The pricing velocity index has you counting the mechanisms you actually run (most hybrids land at four or five). After that, you measure the real time from "we have an idea" to "it's live for a cohort".
A company running five mechanisms that each take a quarter to touch has a low PVI no matter how sophisticated the pricing looks on the contract. A company running five mechanisms it can move in an afternoon has a very high one.
Plot it and you get four places to be:
Slow to change (a quarter or more) | Fast to change (days or hours) | |
|---|---|---|
Many mechanisms (4-5) | The trap. Five-mechanism hybrid, one engineer, a quarter per change. Most $150M+ ARR companies live here. | Pricing agility. Vercel ships around 5 changes a month against a deep stack. The goal. |
Few mechanisms (1-2) | Frozen. Flat or tiered and still slow. No reason to be here. | Nimble but shallow. Early startup, easy to change because there's barely anything to change. It doesn't survive your first real hybrid. |
The move the market is making, all at once, is straight up the left column with everyone adding mechanisms.
I don't think many are quickly moving right (getting faster) just yet.
How to actually get to pricing agility
We run a six-stage spectrum with commercial teams and ask one question: where do you think you are?
Stage | What it looks like |
|---|---|
1. Flat pricing | One price. Everyone pays the same. |
2. Tiered plans | Good/Better/Best. Static. |
3. Usage bolt-on | A usage component held together with a database table and a Slack channel. |
4. Credit system | Credits live in a table someone built in a weekend that everyone's afraid to touch. |
5. Hybrid model | Subscription + usage + credits. Three systems, one engineer who understands how. |
6. Pricing agility | The commercial team changes pricing without engineering. Iterations in hours. |
Most companies land at 3 or 4 when they're honest, and the gap between 5 and 6 is where they stay longest. Not for technical reasons. The engineering hours are committed elsewhere, the rebuild keeps landing on next quarter's roadmap, and nothing is broken enough to force the issue while everything is a little too slow.
You don't get to stage 6 with a 12+-month rebuild of your billing system
The teams that got there started with the rate card, because it's the one artifact every other system reads from. Centralizing it doesn't migrate your existing contracts. Customers stay on their terms, new contracts go onto the new system, renewals migrate as they come up. Within two or three renewal cycles most of the book has moved and nobody's invoice changed unexpectedly.
The test is smaller than people expect, and it's really a PVI test in a trenchcoat: can you run one pricing experiment this month that would have taken a quarter before?
If yes, the architecture is working and you're moving right.
If not, you're still in the trap, and the cost of staying is another quarter of experiments not run and margin not defended while your cost surface keeps moving.
The maker decides, everyone feeds
Same insight, by seat. Each of these people has a question to answer. Four of them are feeding the decision. One is making it.
Role | What to ask | Maker or feeder |
|---|---|---|
CPO | Can you ship a pricing experiment in the same sprint as the feature it monetizes? | Maker (product-led pricing) |
CTO | Is the rate card a versioned object that bends, or a vendor ticket in a queue? | Maker (architecture-led) |
CEO/Founder | Is your credit-to-token ratio a first-class object you read, change, and audit? | Maker (strategy-led) |
CRO | Can your worst-shaped enterprise contract be encoded without a parallel spreadsheet? | Feeder (deal reality) |
RevOps | Can you pull a margin report by feature, model, region, and segment in real time? | Feeder (margin truth) |
CFO | Can you walk any invoice line back to source events inside the close cycle? | Feeder (audit reality) |
Pick the maker by stage. Product-heavy AI company, it's the CPO. Architecture is the wall, it's the CTO. Pricing is the company's whole strategy right now, it's the founder. The other seats stay loud and stay essential. They just don't get a vote on the call, they get a voice in it.
So here's the question worth asking your CTO this quarter:
Can the person you'd name as owner actually change unit, rate, pool, and cohort without a platform release and without the one engineer who built billing v1 signing off on every move? Well, you have a pricing bottleneck with a nicer title…

This is the short version of a longer e-book. The full argument, including the AI pressure coming at all five commercial seats and the credit-and-token economics underneath it, is in the e-book Pricing at Product Speed. Download it here.
Ready for billing v2?
Solvimon is monetization infrastructure for companies that have outgrown billing v1. One system, entire lifecycle, built by the team that did this at Adyen.



