SCOTT WOODY: Hello and welcome. This is packed house. I know Sam, I see a lot of friendly faces. Really excited today to bring you a talk that I've been working on for a bit. And it kind of is refining this idea of how do you keep your pricing moving at the same speed as your product in a world where AI is constantly reinventing the value that you provide? And so what we're going to do today is we're going to start with a question. Y'all are here. You know this is about pricing. I assume you didn't wander into the wrong room. So you're thinking about pricing. Who here has made a pricing change in the past three months? Okay. Keep your hand up. Past six months. Okay. Incrementally more. Anyone in the past year? Okay. Interesting. It's like actually less than I would have thought. Okay. But it dovetails with my real question, which is who among you has initiated the following Slack thread?

Hey, I think we should probably change our pricing sometime. Maybe let's think about this outcome-based or this usage-based pricing. And kicked off like an infinite Slack thread. Yeah, exactly. I see some hands. I know you guys are hiding. The reality is, I'm sure every single one of us has thought in the past, in the recent months, that actually I need to change my pricing. My pricing needs to change and yet 200 Slack messages later, you've realized actually this is a futile exercise. I'm really not going to even try. And what we want to talk about today is how do you fix that fundamental problem using technology, using human labor. And then the other thing that we're going to do is we're going to bring an expert onto the stage, the leader of the pricing monetization team at Anthropic, and he's going to come talk to us about how do you build an engineering team that actually enables you to move at the speed of AI.

So what are we going to cover? We're going to first start by talking about what is blocking. Why does every pricing change seem to stumble and fall and not get to production? We're going to talk a little about the underlying fears that go into that. What is actually happening there? Why is that happening? The second thing we're going to do is we're going to talk about the core idea of treating your pricing like the product. How do you actually build a product that promotes the growth of more usage of your product, especially in this AI usage-based world? And then the third thing we're going to do is we're going to learn from Shaa. Shaa's going to come up here and teach us all how to build a team that moves as fast on monetization and pricing as the rest of your engineering team moves on the product.

So that's our agenda. We're going to start by understanding why are we here? Why is this room full to bursting? The reality is AI is ripping through every single company, every single product, every single thing that we do in the world. You heard it on the main stage just now. The world is becoming agentic. And the way that I hear that is our products are getting better really, really, really fast. The value that we are creating in the world is accelerating in a very non-linear way. And yet our pricing is kind of stuck in the Dark Ages. Our pricing is still seat-based. Our pricing is inertial. Every pricing change somehow requires the janitor to sign off on it before I can put it into production. And then when I do put it into production, customers get mad at me and then I pull it back.

And we want to just dissect that. Why is that happening and what is happening next? And how do you actually move faster in the age of AI? And I think the key thing to start with, at least for me, is that the conventional wisdom in pricing has historically been don't change it. If it's working, don't change it. And I think that conventional wisdom kind of is completely wrong in this current world. I think changing pricing and packaging is going to happen a lot faster. And I want to try to dissect how to essentially build an organization that is capable of moving faster on pricing.

So let's talk about the first fear, the thing that I think blocks most teams at first. And the way that it manifests is someone has an idea for a new pricing model that they want to roll out. And then they go talk to the go-to-market leader and the go-to-market leader says, "Well, we have 100 million dollars of revenue on this business line. It's seat-based. I don't want to kick the hornet's nest. I don't want to introduce this new pricing model. I don't want to introduce an outcome-based thing. I want to protect my revenue." And my fundamental problem with this is that cannibalization in the age of AI is the goal. The reason why you're putting AI into your product is to disrupt your product. And so if you are stuck fearing for how am I going to handle the fact that my revenue's going to get cannibalized, you're literally optimizing for the exact wrong thing. You actually want to be cannibalized. You want to be like biting your own arm, turning yourself into food for the next version of your product, because if you're not doing it, your competitors are. And I think it's really, really important to kind of take this idea of cannibalization and in fact invert it to say, how do I actually disrupt myself in terms of pricing?

How do I introduce enough net new value in my product to justify all of the work that I need to do in order to change my pricing? And so a failure mode is to change pricing, but not add new value to the product. If you're doing that, you're doing it very wrong. In fact, the way that I like to recommend it is instead of thinking of this as cannibalization, instead think about how do I create new value in the product and then how do I go ask the customer for more money in exchange for that value? That is essentially capitalism working as an intended, and it is the best way to kind of combat this idea that actually I'm really afraid of losing the money that I previously earned. The second fear that we see, and I think this is like where the conventional wisdom tends to live, is that pricing changes should be rare. Pricing changes should be something that you approach with a lot of caution and pricing changes are one-way doors.

I basically disagree with all of those pieces of advice. I actually think that if you study the best companies in the world, think Anthropic, think OpenAI, think Salesforce. They change their prices all the time. Salesforce, one of the largest enterprise software businesses in the world, has changed its fundamental pricing model like four or five times in the past 18 months, and that's what they've announced. In reality, they've experimented with hundreds of different commercial models. And so if you're sitting here thinking, actually, I need to be very precious with this pricing change, I would argue that you are doing it completely wrong. And the truth is that pricing changes today are quite hard to execute. And so the reality is if you're sitting here and you haven't changed prices in a year or two years or three years, that first pricing change is going to be incredibly hard.

It's going to be very … it's going to require a ridiculous amount of effort. And so the way that I like to think about this is that instead of being afraid of changing prices, think about actually, what if the goal of my entire organization was to change prices? The product team, their goal is to build new value into the product. The go-to-market commercial and product teams, their job is to essentially have that value translate into more dollars in my bank account, a.k.a. I need to be changing prices or at least thinking about the value change and value-capture all the time. And so what we have found when working with a bunch of the fastest growing companies in the world is that they build a habit of essentially, like, going through the motion of actively thinking about what's my value, how can I change for it?

And then working through pricing changes at a rate of speed that would embarrass most of us in this room. And I think that's really, really important because what they are doing is they're essentially every day they're going into the gym and they're saying, “Yes, it's hard to change prices. Yes, there's a lot of friction, but I’m going to go do that incremental workout and I'm going to get stronger and stronger and move faster and faster over time.” Successful organizations that do this, they move faster over time, which is completely against the way that most pricing and packaging happens in Silicon Valley today. Okay. Let's talk about the third fear. The thing that I think is actually the hardest one, which is this idea that pricing changes are actually, the way I like to think about them, they're kind of a collective-action problem. And the way that you experience this is someone will have a great idea for a new pricing model or a new product or a new packaging.

And then they’ll go, “Okay, well, I need to go talk to finance to make sure I'm not wasting a bunch of money. I need to go talk to the pricing expert because I'm not sure what the exact price levels are or exactly the right commercial model. I need to go talk to marketing. I need to figure how to communicate this to customers. I need to go talk to product. Can I even monetize in this way? I need to go think about the end user.” And basically the list goes infinitely long. And so the way that most companies solve this problem is they build a pricing committee. Probably some of you are on that pricing committee. But what you realize when you spend enough time with pricing committees is that pricing committees are there to essentially provide air cover for no one to make a risky bet.

Their job is to de-risk movement across the entire business. Literally, they are designed to promote inertia within the organization and they exist to essentially be governance. The challenge is that AI does not wait for your governance processes to catch up. And so if you're spending months, weeks, years thinking about discussing, debating pricing changes, your competitors who are much smaller, much nimbler, they're not like ... I can tell you as a 10 person startup, you're not having a pricing committee. Your pricing committee is one person, is the CEO, and they're just going to roll it out into production. And yes, maybe they're wrong, but when they're right, they're right much faster than you and they will win market share off of you. And so my actual advice here and the way that I like to think about this collective-action problem is that you can still have a pricing committee.

Think of it like a council of elders, but you need a chairperson of that thing. You need a person who is sitting in that room and whose job they're basically, they are hired or fired based on their ability to get pricing changes pushed through your organization. If you are looking around a pricing committee and you're like, who's the decision maker and you can't answer that question, you need to take a step back and say, who is the person that we're going to push to go focus on this? I've worked with a number of public companies. The way that they solve this problem once they start to realize what's happening here is the CEO will promote someone—someone in strategy, maybe in pricing, maybe in product—and basically give them the mandate of heaven to go move whatever mountains need to happen in order for that pricing change to roll out.

And the metric that that person is held to is, how quickly and how efficiently do I roll out pricing changes. Their goal is speed, their goal is change. And that is very difficult inside of a pricing committee that is like kind of a consensus-based approach. So we talked about these like three fears. We talked about the fear of cannibalization, but instead you should think about it as, how do I grow faster? We talked a bit about this like fear of pricing change, but really in the way that I would encourage you to think about it is you need to embrace pricing changes as value-creation events. We all work in companies that are trying to grow. Value-creation events are exactly how your business grows. You should embrace those opportunities to grow and change things. And then the third thing is, if you are stuck in a mode where basically there's this collective-inaction problem, go have an honest conversation with your boss or your boss's boss or a founder and basically say, who is the single point of failure?

Who is the single person who's going to go drive this stuff forward? And so now I want to talk … so we talked about a little like the kind of common failure modes of pricing and packaging inside of what I see inside of tech companies. But I want to talk a little bit about usage based pricing because I know a lot of you are probably here to hear about that topic because we're about to talk to Anthropic. And I think the thing that everyone should just understand about usage-based pricing is that fundamentally pricing changes that are usage based or kind of … usage-based pricing is kind of, by default, very hard for users to understand. It is a lot of data. If you're using Claude on a daily basis or especially over the API, it's really hard de novo to understand exactly how you're using that product, especially in an organization like Stripe, which has 12,000 users of the product. It's really hard to understand exactly where that value and that usage is accruing.

And I think the key thing to understand if you are building a usage-based business model is that your goal as a product engineering team is to give every single one of your users the visibility into exactly how they're using your product, how that spend is happening. In Anthropic, they give you visibility at the organization level, the subunit level, the individual person level, the individual agent level, the individual workflow level, that level of granularity and visibility. Why did they build all that technology? The reason they did that is because they knew that their customers needed to understand exactly how they're spending money on the platform because every dollar spent is a dollar of value that they are capturing. And the reason why they're projecting that back to you as the user is because that is the way that they land the value with you as a buyer.

Anthropic goes a step further. They actually help you understand, okay, based on your usage today, how much will this spend accrue over the next couple months? They invest a lot in what I think of as predictability tools. And the goal here is really as a provider of AI products, your goal is to help a user right size their spend on your account. So the, like, bad analogy is like, pretend ... So I have a seven-year-old daughter and we took her to an arcade once and I accidentally gave her my credit card. And it turns out seven-year-olds can spend a lot of money in an arcade in very short amount of time. I don't even know how it's possible. And the bad version of predictability is you build a flow or a product that allows a user to take an unbounded amount of spend and just go run it through the casino.

That's a recipe for very unhappy customers, very upset economic buyers. And that ability, like not providing the tools, the governance, the visibility, the predictability on top of that spend is really, really bad in these usage-based business models. Now, fortunately, obviously I work at Stripe now, we build all of these tools for you. So if you use Stripe billing, if you use Metronome, you get all of this out of the box. And one of our key users, one of the people that we designed this product with is actually Anthropic. So I want to take this moment to kind of say, to welcome Shaa to the stage. Shaa leads the monetization team at Anthropic. He's one of the smartest, I would say, like, engineering leaders thinking about the forefront of the intersection of usage billing, token billing, and engineering platform teams. So I'd like to welcome Shaa to the stage and then we're going to do a fireside chat to talk a little bit about how to run modern monetization teams.

All right. So Shaa, you run perhaps the most important monetization platform team in Silicon Valley at the moment. I am certain that like some 70% of the audience is using Claude Code at this moment. How do you think about success? What is success as an engineering leader for a platform like Claude and Anthropic?

SHAA ALAGUMUTHU: Yeah. I think in my view, success is all about building a platform. I think it's a platform is not about launching a product or a price point one at a time rather. It's building the primitive. It's building the, we call it as building the rails on which our product team can come and incrementally launch. So essentially the cost of building the kind of work to launch the incremental products should linearly go down. I think that's how we define platform. I think everyone knows here. And how do you define success? I think our product really wants us to launch every day. They really like launching products every day in the morning and the evening. So success is like for our platform, our engineers are sitting here, amazing team, it's all about how can we have the rails in place to make sure that the product launch is going smooth and without adding more incremental cost to it and then not breaking anything in production, what we already have.

SCOTT WOODY: Okay. So the thing that you're saying—which I think again, it goes directly against the conventional wisdom or at least the lived experience of pricing—is that over time launches get faster and that's like the way that you goal your team. I think I would love for you to maybe talk a little bit about your experience in balancing that platform element, this ability to move faster and incrementally move faster, but also the fact that actually you are handling probably the most important data inside of Anthropic or at least one of the sources of most important data. How do you balance those two? Because I think in naive terms, you might assume that you would want to operate in a super risk-averse way, but you're also saying you want to move faster over time. How are you balancing that as an engineering leader?

SHAA ALAGUMUTHU: Yeah. I think in the space of AI, things are moving pretty fast. The model capabilities are really accelerating and your customer segments are moving pretty fast. When you're launching a product, you're targeting one set of customers, but they are using it for different kinds of problem solving. So your total addressable market is expanding fast. I think one of the core discipline our team really tries to have is like being ahead of what we think is the problem we are solving and how do we get to know what is being ahead? Things are already moving fast. How do you even keep your heads up here? I think talking to your partners, like your stakeholders, it could be product, it could be finance who is defining your pricing. Who cares about margin here? Who cares about pricing experimentation here? Try to understand what's important for them, what they are not confident about for the next six months.

Where do they think that they are very clear about what's going to be needed in the next six months? I think the answers for all those things will give you pretty good signals on what you wanted to invest in or are essentially that's going to become your requirements for your platform to build upon. Yeah. I think end of the day, your platform should be adaptable enough to absorb all the changes that's coming in, which you actually don't know that's going to come in.

SCOTT WOODY: Yeah. I mean, I think the thing that I would reflect that you said is you are treating your internal users as customers and you're trying to anticipate their needs, but you're more or less just staying super tight with them, which to me is actually the thing that's inspiring about the way that you run your team is it's very similar to how you would run a new product team inside of a startup where you are just like, it's like, how do you build a good product? Well, you talk to your users and figure it out. It's not super rocket science, but I do think that one of the hard parts about monetization is that you don't have the luxury of having just one customer. You actually have finance because your system has to be absolutely correct. You have end users who need to understand the value and the accuracy and basically understand exactly what's happening under the hood for a product as complex as Claude.

And then the product teams themselves where their kind of goal function is, how do I get a product into market that's the right pricing as fast as possible without any bugs? Make no mistakes. So generally, how do you think about living in a multistakeholder world as an internal platform team?

SHAA ALAGUMUTHU: Yep. Running a billing platform is, you have stakeholders everywhere. You have a lot of fans within the company, isn't it? So I think the three major, I think at least our mental model is there are three categories of stakeholders or your internal customers treat it as you are building internal product. So the first one is the product teams. So what do they care about? They care about how fast they can launch and how much quality is it going to be in there? I think that's more critical for them. And how does that translate to us? We should think about like products can be, there could be some flagship products. In our case, our chatbot or our Claude Code, I think those are very, very much stabilized products. Like what kind of monetization changes that can go on that should be on rails, we call it.

So they should be very stable and that could be our other end of spectrum of product teams like the labs who wanted to experiment things. They wanted to come up with some really interesting idea, they wanted to try, and then they wanted to monetize how do you do this one-off stuff in your platform to still be able to support them. So for product teams, you have to really have this spectrum identified and offer the service accordingly—the speed versus stability and stuff. The next customer is our finance, who cares about pricing, right? They wanted to do pricing experiments. They care about the margin. They essentially care about, as a platform, we need to make sure they understand what is the cost of serving our customers. I think the cost of serving a customer could be very much static or very much predictable in some industry. In AI, it's very dynamic.

So how as a platform we are going to support them. That's very critical. The third one is our end users. I think when you're running billing platform or monetization billing, your end customers are also your customers. And especially in AI, you are trying to build experiences, the one you have been showing. Those are very much … that should be in the front and center of the product experience because the teams wanted to know where they are spending the money and like what guardrails they wanted to have, like how they can better manage their budget. So it's very critical to have their experience incorporated into whatever you're building and into your platform.

SCOTT WOODY: Yep. I mean, I think what you're saying, and at least the way I'm hearing it is a lot of what you're doing is you're kind of keeping the user at the center, like the last one you mentioned, the end user. It's like you are communicating value to them, you're giving them tools for controlling and understanding their own value, and then you are saying, "How do I make sure that my team gives them the best product experience?" You're literally building a product for them. It just takes the form of pricing and packaging that's available to them and then tools on top of it. And you are also kind of treating your product customers as like, "My goal here is to grease the skids so that they can kind of quickly and easily launch new products. And then for finance, you need to make sure that everything is absolutely correct, that the pricing experiments, then information, that data is freely available to them so that they can do their job." I think balancing all of those things is interesting and obviously a very hard job, but the one that I'm most interested in hearing a little bit about is finance because I think the way that Anthropic approaches pricing and packaging from the finance lens is almost as this like margin-experimentation game.

It's like pricing is really, because you're pricing on a raw material, in this case tokens, you have this interesting idea that like actually our unit cost or our marginal cost to serve is significant. And so our pricing is in some ways a way of experimenting and playing with margin and trying to find the, like, essentially the global optimum for our pricing. How do you think that lesson applies to other folks in this room who might be building either token-based pricing or more usage-based models? How do you actually make margin like a core part of the pricing and packaging experience for your teams?

SHAA ALAGUMUTHU: Yeah, totally. I think that's probably the most interesting part of running a billing platform in this space. The margins are very dynamic here. It's probably not as straightforward as typical SaaS margins because your models are evolving in the way that you are dealing with different versions, you're dealing with different models of different capabilities. And also you are the cost of your task, like what's the token cost for something that is cached? What is a long context token cost and what's a batch? What is synchronous? What is the high QOS inference that you're doing? So the cost to the customer and the cost to the business is very much dynamic. And for a finance team that is really controlling the pricing, it's very much important for them to really know the underlying cost of serving our customers on a specific segment or a specific product line. So this could translate into how real time that you wanted to know the cost of serving the customers on a specific problem or a specific set of tasks.

Today, I think the traditional building platform is not built to track this cost. And also, if you are going to make a decision, pricing decision on a cost which you derived a month ago, that's not going to be relevant for your launch. So this is an emerging area. I don't think we have fully solved this, but this is going to be very important for us to make sure your building a platform, or a platform-monetization platform you’re building, is scaling up to offer a near real-time visibility into the cost of serving our customers segmented by all dimensions.

SCOTT WOODY: Yeah. I mean, from working with you, one of the things that strikes me is y'all ... It's kind of saying that you have a pricing as kind of a misnomer. You really do think about pricing across every model. You think about pricing as a function of time of day. And I know you very famously had some interesting experiments around time-of-day pricing and spot pricing. And I think one of the things that I've observed from working alongside you is that the pricing complexity is just kind of, it's like you have to wrestle with that as a business because your marginal cost to serve is there. It's like in a sense, we are all becoming infrastructure vendors. Even if our product is not a commodity, it isn't infrastructure in any traditional sense of the word.We have to understand our unit costs at that level.

And one of the things I've observed from working with you and then other companies like some of the super AI-native companies is from minute one, they understand those costs and they're really thinking about cost continuously throughout the entire journey. Obviously, like Claude and Claude Code is one of the most successful agents in the world, possibly the most successful agents in the world. How do you think about the rise of agents on your infrastructure and what you provide to your customers? How does it change your job as a monetization platform?

SHAA ALAGUMUTHU: Yeah, that's an exploratory area at this point, but I think if I want to talk about the table stakes things for our end customers, like someone who is running an enterprise organization, their admins wanted to really have a budget on how much spend is going and what control they can put in and stuff. But think of like in the future, and not too far, your production workloads. Your agents could be running tens of thousands of these small tasks, which is going to consume these tokens. How are we going to make sure we have a visibility or the admin has a visibility on how much it is consuming and what's the guardrails that we are going to put on the cost because you're going to set a goal for this agent to achieve. And I think you should also put in some budget with how much resource it can consume to do this.

And it's not going to be humanely possible to set these things manually. So you think of a world where we need to have the platform ready to have this programmatic integrations for these agents to either get to know that they are reaching their limits or giving them the ability to tune their limits and better manage their budget. I think the billing platform, it's going to really push the platform to make it a more real-time system.

SCOTT WOODY: Yeah. I mean, I totally feel that, see that. I think the idea that agents are going to become economic actors. I mean, we're just on stage or we just heard in the keynote about some of the stuff that Stripe is thinking about here, but like this idea that agents are going to have budgets, they're going to spend money. Their job is not to go spend money. Their job is to go accomplish the task, but you're going to want to give them cost envelopes for going and doing that. How does your infrastructure help support or not support that kind of workflow, I think is going to be key going forward. So I want to end and just kind of summarize a little bit of what I heard and what I learned from you. So the first thing that I would say is you approach this problem as a platform, namely, how do you make pricing changes go faster over time?

Second thing is really understand your users and understand how different they are from each other. And then the third thing that I would highlight is that everything is moving toward the agent world—lower latency, more granular, more fine-grain control. How do you build for that future and how do you make sure that you are ready as agents start to take over some of the workflows that used to be run by humans? I want to just say thank you, Shaa. You've been an incredible partner to us at Stripe and we wouldn't be here without you. And I just want to say thank you for all of your time and thank you for your partnership.

SHAA ALAGUMUTHU: Oh, thanks for having me. Thank you everyone.