Abhilash John Who Owns the Rationalization Process? Why Pricing Teams Can't Do This Alone
When your underlying model costs change, who is responsible for deciding whether to update the customer-facing price? A deep dive into Monetization Operations.
AI Summary
Here’s a question that has no clean answer in most AI SaaS companies: when your underlying model costs change, who is responsible for deciding whether to update the customer-facing price?
Not who should be responsible in theory. Who actually gets the task on Monday morning?
At most companies you’ll find the same cast of characters arriving at a meeting room with overlapping jurisdictions and no clear mandate. Finance has the COGS data. The pricing manager has the market context. Engineering owns the billing system. The product manager defined what an “outcome” means. And the VP of Sales has three enterprise deals on the line that will crater if anything changes before quarter-end. Everybody has a stake. Nobody has the write access, the data, and the business authority all in the same hands.
That organizational gap is where AI gross margins go to die.
Cursor’s CEO said the quiet part out loud in a post that circulated widely in SaaS circles: “Our users love per seat pricing. It’s just the cost side makes it harder.” From Metronome’s 2025 field report on AI pricing practices comes this exchange that will feel familiar to anyone who has sat in one of these meetings: “The product team wanted to include AI features in the core plan. Finance said: ‘Not unless you want to blow up margins.’” And Notion’s CEO Ivan Zhao, in a published interview, has framed the stakes directly: he believes selling work and outcomes rather than seats will unlock a market roughly 10x the size of traditional SaaS tooling. That’s not a pricing adjustment it’s a full business model transition. And business model transitions don’t happen in a quarterly pricing review.
Deadlock, margin leaks, and bet-the-company model transitions. The common thread in all of these is not bad strategy. It’s that nobody owns the operational loop.
This article is about why the problem is structural, not strategic and what a team that actually solves it looks like.
The Five Personas Who Think They Own Pricing (And What They’re Actually Missing)
Before proposing a fix, it’s worth being precise about the dysfunction. In most AI SaaS companies, the rationalization process the loop that converts observed COGS into customer-facing conversion rates is implicitly owned by five different functions, each of whom has an essential piece of it and none of whom has the whole thing.
The Pricing Manager owns the price list, the packaging, the competitive benchmarking, and the annual pricing review. This is the person who decides whether a contract draft should cost 10 credits or 12. They have market intuition, positioning instincts, and often a solid spreadsheet model. What they don’t have: real-time access to COGS data, write access to the billing system, or a mandate to update rates when model prices change between quarterly reviews. Their cadence is annual. The problem is weekly.
Finance and FP&A owns the unit economics. They know the gross margin by customer segment, the COGS waterfall, and the margin target the board is holding the company to. They have the numbers, but they have them late aggregated, historical, and formatted for a board deck, not for operational decisions. When COGS drift shows up in the P&L, Finance is the first to see it and the last to be able to do anything about it directly. Their output is a spreadsheet; the system they need to update is a billing platform they don’t own.
Billing Engineering owns the ingestion system, the credit ledger, the pricing rules, and the invoice generation. If you want to change a conversion rate in the production billing system, this is the team that makes it happen. But billing engineering takes direction on pricing they don’t set it. When asked to change a rate, their input is “how do you want this configured,” not “here’s what the rate should be.” They have write access without economic authority.
FinOps owns the cloud cost attribution the AWS bills, the Anthropic API invoices, the model inference spend. They’ve gotten very good at tracking cost per API call, allocating infrastructure spend to teams and features, and optimizing commitment levels. CloudZero’s argument that “cost per API call” should be the most important metric engineering tracks has resonated with FinOps teams. What FinOps doesn’t have is the revenue side of the equation. They can tell you that your COGS per resolved ticket went up 22% this month. They cannot tell you what that implies for your customer-facing price, your credit drawdown rate, or which customer segments are now unprofitable. They live on one side of a gap.
The Product Manager owns the outcome definition. Someone has to decide what events constitute a “resolved ticket,” what counts as a “successfully drafted contract,” and what combination of product signals the billing system should interpret as a billable completion. This is fundamentally a product problem it lives at the intersection of user behavior, product design, and legal but it has deep billing consequences. When Intercom evolved Fin from charging per “resolution” to charging per “outcome,” that wasn’t a pricing decision or a billing engineering decision. It was a product decision with pricing downstream effects. The PM who made it may not have had visibility into what that change would do to the COGS-to-revenue ratio at different resolution rate levels.
Five functions, five pieces of the puzzle, and a gap at the center where the operational loop needs to live.
Why Traditional Pricing Teams Cannot Close This Gap
The simplest version of the argument is this: the rationalization problem is an engineering problem wearing a finance hat, and traditional pricing teams are not engineers.
But that understates how structurally misaligned traditional pricing functions are for this role. The problem isn’t capability it’s organizational design. Pricing teams were built for a world with different operating characteristics:
Annual cadence versus weekly reality. Traditional pricing processes run on a budget cycle. Pricing reviews happen quarterly at best, annually at worst. In the AI era, OpenAI released structural pricing changes to GPT-4 in 2024, Anthropic introduced prompt caching with a 90% discount on cache reads, and AWS raised GPU instance prices in January 2026 for the first time in two decades. These are not things that wait for a Q3 pricing review. A pricing team that is structured around annual reviews will discover margin erosion at the annual review which is nine months after it started.
Vercel’s bandwidth pricing saga is a clear illustration of what this cadence failure looks like from the outside. For years, Vercel’s data transfer pricing was opaque enough that developers only discovered the real cost at the point of an unexpectedly large bill a pattern well-documented in Hacker News threads and developer community forums. Their April 2024 response more granular usage metrics, lower prices on fundamentals, hard spend limits with automatic project pausing at budget thresholds was the right fix. But it came reactively, after significant community backlash had accumulated. Guillermo Rauch’s announcement of the updated Pro plan framing said it plainly: “more transparent, more self-serve, with automatic spend controls.” That transparency gap between what developers were paying and what they expected to pay is what the rationalization process, built with the right cross-functional ownership, is supposed to prevent in the first place.
No write access. The most fundamental problem is operational, not analytical. When a pricing manager discovers that cache hit rates have shifted and the current credit cost of a complex query is now 15% below the margin floor, they need to change a number in the billing system. That change goes through billing engineering, who logs it as a ticket, queues it against other work, and ships it in the next sprint. In the meantime, every transaction at the old rate is a margin leak. A function that doesn’t own the system it’s supposed to manage cannot be the operational owner of that system.
No real-time COGS visibility. Traditional pricing analysis uses historical cost data the kind that comes from the finance system, the kind that’s closed out at quarter-end and reviewed in the monthly business review. This is fine for strategic pricing decisions (should we be in this market at all? is this segment profitable over a six-month average?). It is not fine for drift detection (our margin turned negative on Tier 2 customers six weeks ago and nobody noticed). Pricing managers who don’t have live access to token-level cost attribution cannot run the monitoring loop.
Outcome definition is not a pricing decision. One of the hardest parts of building the rationalization process is defining what event triggers a billable completion for an outcome-priced product. This requires deep product knowledge, legal review of customer contracts, and engineering work to propagate the right trace context through the orchestration layer. Traditional pricing teams are rarely involved in any of those three things. They get told what the “outcome” is; they don’t define it.
The Metronome field report quote captures the resulting dynamic perfectly: product wants to expand access, finance wants to protect margins, and neither team has the system or the data to model what the right answer actually is. The pricing manager mediates but doesn’t resolve. The deadlock is the default state.
A Framework: Monetization Operations
The analogy that I think is most useful here is the emergence of Revenue Operations as a function. A decade ago, sales, marketing, and customer success each had their own operations teams, their own data systems, and their own metrics. RevOps unified those functions under a shared system of record and a single accountable function. The insight was that the handoffs between sales, marketing, and CS were where value was leaking and the fix wasn’t to make each function better at its job in isolation, it was to own the connective tissue.
The rationalization process needs the same treatment. What I’d call Monetization Operations is the function that owns the connective tissue between COGS and customer-facing price the loop that the rationalization engine runs, operated by humans who have the data, the system access, the business authority, and the right cadence.
The team has five roles. Not five departments five roles, some of which can be held by the same person in an early-stage company.
The Monetization Engineer is the new role and the spine of the function. This person owns the rationalization engine as operational software infrastructure. They maintain the provider price book (and keep it current when Anthropic reprices caching tiers), configure the drift detection thresholds, operate the rate approval workflow, and push approved rate changes to the billing system. They are not a pricing analyst who happens to use engineering tools they are an engineer who understands the business well enough to make judgment calls on what the drift threshold should be, when to escalate versus when to publish, and how to structure the simulation so it gives the pricing strategist a useful answer. This role sits at the intersection of platform engineering and business operations. It is not an existing role with a new name; it is a genuinely new kind of hire.
The Billing Infrastructure Engineer builds and owns the data pipeline underneath the rationalization engine real-time usage tracking from every downstream provider, cost attribution to parent customer actions via trace context, ingestion of provider invoices, and the temporal cost store that the engine queries. This role is not a FinOps analyst doing spreadsheet work. It is an engineer solving a distributed systems problem: how do you attribute the cost of four asynchronous LLM calls, two vector DB queries, and a tool invocation to a single parent customer action, in real time, across providers with different billing latencies? Anthropic’s Billing Infra team and OpenAI’s Monetization Infrastructure pod are both doing this work at scale. The output is not a dashboard it is a reliable, low-latency cost signal that the Monetization Engineer can act on. Without this foundation, the rationalization engine has nothing to rationalize.
The Revenue Platform PM owns the product roadmap for the monetization platform which is a broader mandate than it sounds. It includes the billing experience customers interact with (invoice clarity, spend visibility, credit balance interfaces), the internal tooling that lets the Monetization Engineer configure rates and simulate changes, the enterprise contract integrations (how CPQ feeds into billing, how usage gets reconciled against committed spend), and the marketplace integrations that matter as AI products increasingly distribute through third-party channels. Anthropic’s open PM, Revenue Platform role describes this scope directly: “pricing, billing, enterprise contracts, and marketplace integrations.” This PM is also the person who owns the outcome definition question what events constitute a billable completion because it lives at the boundary of product behavior and billing trigger, which is exactly the Revenue Platform PM’s domain.
The Pricing Strategist sets policy rather than operating the system. They define the margin targets by customer segment and product line, make packaging decisions, conduct competitive analysis, and establish the strategic parameters the rationalization engine operationalizes. When the engine flags a rate change, the pricing strategist reviews the business rationale, not the system mechanics. One important observation from how companies like Anthropic and OpenAI are actually building this: in practice, the Pricing Strategist function tends to be embedded inside the Monetization team (as Anthropic’s Monetization pod and OpenAI’s Pricing & Packaging pod demonstrate) rather than sitting alongside it as a peer. At smaller companies, the Monetization Engineer and the Pricing Strategist may be the same person operating at different altitudes on different days. The separation of strategy from operations is still the right design principle but the org chart often doesn’t reflect it cleanly until significant scale.
The Enterprise Commerce Lead owns the revenue lifecycle from contract to cash and this is an operational, engineering-adjacent role, not a finance partner reviewing quarterly outputs. They own the automation of quote-to-cash flows, the provisioning of entitlements on contract signature, the reconciliation of actual usage against committed spend for enterprise accounts, and the payment infrastructure that settles what the billing system says is owed. Anthropic’s Enterprise Commerce team is explicitly chartered to “automate and standardize the revenue lifecycle end-to-end, powering new sales-led growth motions.” OpenAI has a Financial Automation pod for the same reason. The FP&A function still exists it reviews the outputs, validates margin targets, and signs off on material rate changes but it sits outside this team, not inside it. The Enterprise Commerce Lead is an operator, not an approver.
The loop the team runs: Billing Infrastructure Engineer feeds real-time COGS attribution → Monetization Engineer runs conversion rate calculation and drift detection → when drift crosses threshold, Pricing Strategist reviews business rationale → Enterprise Commerce Lead validates contract and revenue lifecycle implications → Monetization Engineer publishes the updated rate to the billing system → Revenue Platform PM monitors whether product-side event signals and billing experiences remain clean. The loop is continuous, not quarterly.
Early Movers and What They’re Showing
No company has stood up a function called “Monetization Operations” as far as I’m aware. But there are clear directional signals in how the early movers are organizing.
Intercom is the most complete case study for what cross-functional ownership of an outcome-priced product actually requires. When they launched Fin at $0.99 per resolution, they didn’t just change a number in a price sheet they reorganized their incentives. Resolution rates climbed from around 27% at Fin’s launch to over 66% across their customer base today, with the best customers exceeding 80%. The CEO’s framing was direct: “the entire company is now focused on driving resolution rates, because for Intercom to win, their users have to win.” That’s not a pricing team outcome. That’s what happens when the outcome definition becomes the organizing principle for engineering, product, customer success, and sales simultaneously. The pricing decision created a cross-functional operating model. Outcome-based pricing, done correctly, is not a billing feature it’s a company architecture.
Clay is the most transparent example available of what a cross-functional pricing process actually looks like in practice because they published it. Their March 2026 pricing overhaul (data costs cut 50–90%, three plans collapsed into two, a redesigned credit rollover system) was accompanied by the release of the internal pricing memo that the team had written to itself during the process. What that memo reveals about the organizational machinery is more instructive than the pricing change itself.
According to Clay’s own account, the first conversations that led to this change started over a year before the announcement. The process ran through three distinct phases of iteration the first being the longest and hardest, where a small cross-functional working group formed specifically to develop the initial hypothesis. They talked to more than 30 agencies, interviewed self-serve customers and enterprise buyers across segments, and ran the math in parallel with the qualitative research. When the decision was made, every executive posted on LinkedIn explaining the reasoning in their own words, and the CFO published the math publicly alongside the announcement. This is not how a traditional pricing team runs a pricing review. It’s a description of a monetization operations function operating as a first-class cross-functional initiative with finance owning the math, product owning the architecture signal, sales owning the customer feedback loop, and leadership owning the external communication. Clay didn’t call it that. But the operational model is recognizable.
OpenAI is the most structurally instructive example, and it comes with receipts. Sara Conlon, OpenAI’s Head of Financial Engineering, publicly documented how she built their billing organization in a Metronome case study. When she joined, the situation was precisely the dysfunction described earlier in this article: each product team had its own approach to transactions, billing, and payments. The result was fragmentation duplication of effort, inconsistent customer experiences, and engineering fragility. Her mandate was to consolidate all of that into a single financial engineering layer, “a substrate that every product could plug into.”
The organizational answer she arrived at was a dedicated financial engineering group structured into four pods: Pricing & Packaging, Monetization Infrastructure, Financial Automation, and Payments & Internationalization. Each pod owns a distinct set of responsibilities but contributes to the larger monetization infrastructure. The framing from the case study is worth quoting directly: “treating monetization like any other production system: modular, observable, and testable, with clear separation between access, metering, and billing.” This is exactly the Monetization Operations model articulated as engineering doctrine rather than organizational theory. OpenAI isn’t calling it “Monetization Operations.” But the pod structure dedicated pricing logic, dedicated metering infrastructure, dedicated financial automation, dedicated payments maps almost exactly to the roles described in this framework. They got there because fragmentation became untenable at scale. Most companies will have to get there the same way.
Stripe made the structural bet explicit with its $1 billion acquisition of Metronome in January 2026. What they’re building model price tracking, configurable markup percentages, high-volume metering infrastructure, and a provider price book is the rationalization engine as infrastructure. When Stripe’s CEO says “metered pricing is the native business model for the AI era,” he’s describing a world where the rationalization capability is table stakes, not competitive differentiation. The companies that build this capability in-house will be the ones who don’t need to buy it later.
Cursor’s situation is an honest view of what happens when the rationalization process doesn’t exist. The CEO’s acknowledgment that users love per seat pricing but the cost side makes it harder is a description of a company that launched a pricing model without an operational mechanism to detect when that model stopped working. The margin problem had to surface at the level of company-wide economics before it became visible. A Monetization Operations function with live drift detection would have flagged this much earlier and given the team options that didn’t require a public pricing restructure.
What the Job Postings Are Actually Saying
The clearest leading indicator of an organizational function becoming real is what companies are willing to pay for. The hiring signals across the AI tier right now are unusually specific and they validate the Monetization Operations model role by role, in actual job descriptions.
Vercel’s Product Manager - Pricing posting is the most precise description of the Monetization Engineer role I’ve seen in the wild. The job requires “technical chops as an engineer or PM of an infrastructure product” and frames the core work as designing “pricing models that fit how developers actually want to buy” collaborating with engineering on AI and agentic offering integration, building customer-facing pricing calculators, and iterating on infrastructure pricing in lockstep with EPD and GTM. The compensation range ($189,000–$270,000 base) is closer to a senior engineering salary than a traditional pricing analyst. Vercel is not hiring a pricing manager. They are hiring someone who can own the boundary between product architecture and billing logic.
Anthropic’s billing platform team structure is the clearest organizational mirror to the framework in this article, and it is documented by two of their own financial engineering leaders posting publicly. Shanmugasundaram Alagumuthu, who leads Financial Engineering at Anthropic, describes the function as hiring for two kinds of roles simultaneously: a Software Engineer, Billing Platform to “build the billing and pricing infrastructure that powers all of Anthropic’s products real-time usage tracking, revenue reconciliation, and payment systems where correctness and scale both matter”; and a Product Manager, Revenue Platform to “drive the product roadmap for Anthropic’s monetization infrastructure pricing, billing, enterprise contracts, and marketplace integrations.” His framing: “genuinely interesting problems at the intersection of revenue infrastructure and AI.” That is not a finance team description. That is an engineering-domain description of a function that owns both the infrastructure and the product surface of monetization.
Cameron Fitzgerald, an engineering leader on the same team, describes the three-team internal structure in more detail: Monetization (partnering with product teams to ship billing experiences), Enterprise Commerce (automating and standardizing the revenue lifecycle end-to-end, powering sales-led growth motions), and Billing Infra (building the infrastructure and data foundations that let billing scale with Anthropic’s launch velocity). His hiring pitch: “high-ownership problems at the intersection of product, revenue, and scale.”
Together, the two posts describe a function that matches the Monetization Operations model almost exactly. Monetization ≈ the Monetization Engineer and Revenue Platform PM roles. Enterprise Commerce ≈ the Enterprise Commerce Lead and quote-to-cash motion. Billing Infra ≈ the Billing Infrastructure Engineer and the attribution substrate the rationalization engine runs on. Anthropic is not hiring billing administrators or pricing analysts. They are building an engineering-first function that owns the full loop from usage event to recognized revenue and they are doing it at the speed their product launch cadence demands. Open roles across the three teams are linked here, here, and here.
Intercom is simultaneously hiring for a VP of Pricing and Monetization Strategy and a Senior Product Manager, Monetization. The VP role is tasked with leading the company’s global pricing and packaging strategy, building a measurement framework for the pricing model, and running quantitative and qualitative customer research. The Senior PM sits adjacent, owning execution. Two senior hires, different altitude, complementary mandates: the VP sets policy, the PM operates the system. This is the Pricing Strategist and Monetization Engineer relationship, as observed in a company that has already gone through an outcome-based pricing transition.
OpenAI’s active postings include Software Engineer, Monetization Product & Platform; Software Engineer, Monetization Infrastructure; Quote to Cash Systems Engineer; and Frontend Engineer, Financial Web Platform. The fact that these are distinct engineering roles not “a pricing analyst and some backend help” signals that monetization has been treated as an engineering domain at OpenAI, not a finance or GTM domain with engineering support.
The pattern across all of these is consistent: the companies at the frontier of AI monetization are staffing for it with hybrid technical-commercial roles, at senior levels, with cross-functional mandates, and at engineering-level compensation. The function does not yet have a shared name. But the shape of the hiring is converging on the same answer.
The Organizational Claim
The pattern here is the same one that produced RevOps as a category. Before RevOps, CROs managed three functions sales, marketing, CS that each had their own metrics, their own tools, and their own operations teams with no shared system of record. The “problem” was that the handoffs between them were where deals were lost and churn happened. RevOps solved it by owning the connective tissue: the CRM, the attribution model, the pipeline definition, the quota calculations. The function didn’t replace sales or marketing it made the handoffs work.
Monetization Operations is the same archetype applied to the handoff between COGS and customer-facing price. It doesn’t replace the pricing strategist, the FP&A team, or the FinOps function. It owns the operational loop that connects their inputs to the billing system’s outputs. The Monetization Engineer is the RevOps director equivalent the person who has the technical access, the business context, and the organizational mandate to make the loop run continuously rather than quarterly.
Where does this function report? There’s no single right answer. At companies where the CEO thinks of this as a financial discipline, it will report to the CFO. At companies where it’s treated as a product capability, it will sit under the CPO. At infrastructure-heavy companies, it might sit with the CTO. The reporting line matters less than the structural requirement: someone in this function needs to have write access to the billing system, live access to COGS data, and a clear mandate from leadership to update rates when drift crosses a threshold without filing a ticket and waiting for a sprint.
The companies that figure this out first will be able to do something their competitors cannot: reprice confidently in hours, not quarters. In a market where model prices are dropping, usage patterns are shifting, and outcome definitions are still being negotiated, that operational speed is not a nice-to-have. It’s the difference between discovering a margin problem in the quarterly review and managing it before it becomes one.
The organizational gap is real. The function to close it is new. The companies that build it are going to look very different in 2028 from the ones that are still running pricing on spreadsheets and goodwill.