---
title: "Why Outcome-Based Pricing Is a Trap for Most AI Companies"
episode: 91
podcast: "The LeanScale Podcast"
publisher: "LeanScale"
guest: "Roee Hartuv"
guest_title: "Pricing & Packaging Advisor (ex-Winning by Design)"
date_published: 2026-07-10
date_modified: 2026-07-22
duration: 00:41:09
word_count: 6071
topics: ["pricing-packaging", "consumption-revenue", "ai-in-gtm", "gtm-strategy"]
canonical_url: https://leanscale-knowledge-hub.netlify.app/podcast/roee-hartuv-outcome-based-pricing-trap/
source: "LeanScale Podcast Knowledge Hub — https://leanscale-knowledge-hub.netlify.app"
license: "Free to quote and cite with attribution to The LeanScale Podcast."
---

# Why Outcome-Based Pricing Is a Trap for Most AI Companies — Full Transcript

> Episode 91 of The LeanScale Podcast, with Roee Hartuv.
> Published July 10, 2026 · 00:41:09 · 6,071 words.
> Machine-transcribed and **not diarized** — speaker attribution is inferred, so verify
> attribution against the audio before quoting a specific person.
> Structured breakdown: https://leanscale-knowledge-hub.netlify.app/podcast/roee-hartuv-outcome-based-pricing-trap/

## 00:00 — Cold open + intro

**[0:00]** Rui Hardev is a pricing and packaging advisor based in Berlin who has quietly become one of the sharpest voices in B2B Saas on how to actually capture value. He spent nearly four years at Winning by Design, the firm that pioneered the bowtie model, where he led the revenue architecture team and taught their flagship revenue architecture course to operators around the world. About a year and a half ago, he made a very sharp call. Of all the levers a GTM operator can pull, pricing and packaging consistently produced the fastest and biggest results. So he walked away from being a generalist and focused on

**[0:44]** nothing else. Today he runs pricing engagements with B2B Saas and AI companies on both sides of the Atlantic, helping them rethink how they package, meter, and price as the category moves away from seats and into consumption and outcomes. In this episode, we get into why most operators are working on the wrong lever, why the days of pure seat-based pricing are over, and why outcome-based pricing, despite being the buzzword of the year, is a trap for most horizontal AI companies. A year and a half ago, you decided to stop being a generalist, GTM advisor, and only work on pricing and packaging. What were you seeing across your

**[1:27]** engagements that made you say, "This is the lever, and I'm giving up on the others for now." That most of the other levers take time to see results. A lot of them are focused on humans, especially when we're seller-led and customer success-led, human-led, not self-serve, and making all these changes take time, and you can train and teach and introduce tools, but as soon as somebody leaves the organization, then it's back to square one. I came to the conclusion that if we fix pricing and packaging, that unlocks many different opportunities along the customer journey, from the acquisition, to the onboarding, to the renewal and expansion,

## 01:42 — Why pricing is the most overlooked growth lever in B2B

**[2:18]** and it touches everything. It touches the go-to-market, but it also touches product, and it touches operations, and by getting pricing and packaging right, you can really fix a lot of different aspects of a company. I do believe that pricing and packaging is like a magic growth lever we have, and it is mostly overlooked. There are not a lot of experts out there, or companies don't have a pricing and packaging expert until they reach that 500 million ARR. Before that, sometimes it's a CRO, sometimes it's a CFO, sometimes it's product or product marketing. There is not a lot of knowledge, and I believe that

**[3:01]** if we start working on pricing and packaging much earlier, we can get much better results. I can absolutely attest to my journey here at LeanScale. I started the company in 2021, and pricing and packaging has been and continues to be one of the biggest challenges that I have had in our business. It hasn't been the messaging, it hasn't been the sales, it hasn't been the delivery, it hasn't been the recruiting. Those things have had decent paths forward, but I personally have had a really, really tough time with this topic, and I'm curious, when you approach one of your clients, what is the order of operations? If they have this

**[3:50]** intuition that their pricing and packaging is not working, where do you even begin? I begin with packaging. Packaging is how we bundle our different features and functionalities of our product. The classical way of doing packaging, of bundling, is usually it used to be considered a product exercise, where the product team just looks at our existing customers. Let's look at who uses what features, and let's rank all the features and how many customers are using it. This takes the first 60%, the first batch, and put that under the basic. The better package gets the 60 and additional 30. The best is that 10% of features

## 04:27 — Why you start with packaging, not pricing

**[4:38]** that are maybe the premium features, that's the AI, that's the advanced analytic capabilities. This is how the classical way of doing packaging worked. The new way or how we believe it should be done is around jobs to be done. It's around what your customer is looking to achieve using your product. It's that value that everybody talks about. To give you an example, before I became a consultant, I was a software seller. I climbed my way out from a solution engineer, account executive, to a couple of sales leadership roles. Every time we do value selling, of course, everybody wants to do value selling. Only when I got into pricing and packaging,

**[5:24]** I discovered that you can talk and you can say that you're doing value selling, but if your packaging is not aligned to values and jobs to be done, then you can talk all you would want, but at the end of the day, you will always fall back to talking about features and about the product itself and not around the customer. If we can bundle and package around jobs to be done and what the customer wants to get out of the platform, that solves a lot of friction across the sales process and the renewal. If a customer can see the jobs to be done, the different packages and say, "Hey, this is the job that I'm looking

**[6:02]** to achieve. This is the right package for me." It solves most of the scoping aspects of the sales process. And one of the things I know you mentioned is you leave the actual price point for the last thing. What are your opinions on pricing high, pricing low? How do you come up with a number that makes sense once you've gone through the packaging exercise? This is where we try to understand the customer's willingness to pay. You're right that we leave it to the last step. So we start off with packaging and then we do the pricing structure and then the pricing metric. The pricing metric is what we price on. And then how do we price?

## 06:18 — Packaging by jobs to be done vs. by features

**[6:42]** Do we price on front or backward looking? So they pay only after they consume, et cetera, et cetera. And the price point comes last. In B2B sales, which I assume is most of our listeners today, it doesn't matter for our customer if it's 12,000 or 13,000. The deal will not, we won't win or lose. It's not like retail or B2C where yeah, every dollar could have an impact. It's B2B. We all know this. We all know that if we put our best sellers, they will be able to sell at 12 and 13 or even 15 because it's all about value. So that's why the price, I wouldn't say it's less important, but compared to all the other

## 07:16 — Why the price point matters least in B2B

**[7:25]** mechanisms that we have when defining pricing and packaging, usually that's the least important. Yeah. And on the B2C side, typically the packaging part is pretty easy. You have a single product or something very simple that you will put a price on. So then a lot of the science ends up being on the number. But in most B2B, we're selling very complex products or services to solve very complex problems and to very different industries that may value certain things differently. So there's a lot of complexity for us to walk through that. I have been in B2B SaaS my whole career, and it's always been one of the toughest things for us to

**[8:12]** figure out. Yeah. Complexity is we have a budget of complexity. Now, obviously the higher your ACV, which correlates with the type of customers that you're selling to. So the bigger they are, the more complexity you can add into the sales process or your pricing. So for example, if I'm AWS and I'm selling big seven eight figure deals with enterprise accounts, of course it is very complex. There's so much things in the pricing and packaging. But when I'm selling to a startup that is just starting off and the ACV there is very low and the complexity has to be very low as well. So that's why they have the startup packages.

**[9:05]** So to keep it simple, to have the buying process as simple as possible. So that's we call that complexity budget. How do you sell? Who do you sell to? And what is the level of complexity that you can introduce into the pricing mix? And by the way, if you're selling to multiple segments and multiple type of customers, you might have multiple levels of complexity. That's also where packaging might come into the play as well. Okay. And let's get into pricing and packaging in the new world of AI. There's so many new things. I had worked in companies that had consumption based pricing before. So it's something I was familiar with.

## 09:20 — The complexity budget framework

**[9:54]** So many things to figure out on that side. But we're also being introduced to outcome based pricing as well. How are you helping companies navigate this whole new environment? So outcome based pricing is the what you price on. You price on outcomes. So that's one topic. Usage based is how? How do you price on that? And you could do both, right? I could do consumption based on outcome. An example of that FinAI, that's a company that does service agents and they just close customer tickets. There's a consumption element. So you pay based on how many tickets were closed. And those tickets are outcomes. So we only charge you. It is

**[10:42]** the what we only charge you on closed tickets. So you can have both consumption. Let's talk about what's changing in SAS. Our cost to serve is almost zero. The marginal cost to serve the 10th client or the 10,000 client is the same. It's practically zero because in SAS you build the product once you have infrastructure, AWS compute and storage. And it's basically zero. That's why our margins were so high. Our margins was in classic SAS 80, 90, 95%, right? 95% the best companies out there. But we all know that AI comes with the costs. Some say that margins for AI companies is 50%. And we all know that companies like

## 10:46 — How AI broke SaaS pricing economics

**[11:33]** OpenAI are losing money. In OpenAI, it's clear they just released or their financials were released. So they're losing a lot of money. So their margins are actually on average, they're negative. And when that happens, when your cost is not zero, all of a sudden your cost to serve as there's a cost to it. So every customer that you bring with your onboard, it adds more costs. So if the way you price does not follow your cost and cost is usage, then you're probably going to lose money down the road. And I think a lot of these companies are not used to that dynamic. They're used to having

**[12:21]** these almost near 100% gross margins. And now that they have to manage the cost side of it, it's creating a lot of complexity in how they package. And we have so many classic SAS companies that have bolted on AI capabilities. So they're already in market with a certain offering with certain promises and certain packaging that's typically revolved around seats or user access or something. And then you bolt on these things that start exponentially increasing the cost side of the equation. How are they navigating that change? So first of all, we can, again, coming back to OpenAI, even the best company in the world

**[13:05]** or second best depends on which camp you are part of, they're losing money. So even them, they are losing money. So all the rest of us probably doing not as good as they are. So we're all struggling to navigate that. And it's very hard. And again, coming back to SAS, in SAS, we only cared about top line. So our cost usually serves on marketing and development. All of a sudden we're introducing another line item, which is cost to serve. SAS native companies, they don't even have the tools to measure that. And when I come in and work with my clients, it's like, what is the unit economics of selling to this type

**[13:46]** of client? We don't know. We can give you the total support and customer success team. But we don't know. We never measure that. They don't even have the infrastructure to measure that. Every company that now wants to introduce AI needs to understand that it's not only a pricing and packaging exercise, it's an operational and a product exercise as well. To give you another example, I recently did a work for a company that they bootstrapped 40 million in ARR. They're probably the leader in their space. And they introduced AI into a seed based model. They launched that in

**[14:26]** November of last year. In February, they called us up and told us, hey, we were a profitable bootstrap company. Since we did this launch, we're losing money like crazy. We need to stop the bleeding now. Again, they were a SAS company, introduced AI capabilities and kept the seed based model. So we worked and we finished the project a month ago to redefine their pricing and packaging, mostly the pricing, to follow that cost of the AI and to make sure that they're not losing money. And again, it's not all the users, right? We will still have some users that are profitable, but the ones that are not, it goes exponentially.

**[15:22]** So if you're doing a seed based, for example, let's take again, open AI cloud. I'm using 20, I pay $20 a month. I'm sure that I'm costing them five times that with the amount of tokens, et cetera. So even they don't want to limit that. So a lot of other companies are struggling with that as well. So in that case, you have a company seed based model. They bolt on some AI capabilities, costs increase. You have to start pegging some of this to usage. And then I think the next layer that comes in, because then sometimes your customers will say, Hey, I want you to be efficient with my usage or certain jobs

## 15:51 — The $40M bootstrap company that bled out on AI

**[16:06]** I'm trying to get done with the usage that you're bolting on. And then that opens up this world of outcome based pricing. And for some companies, it feels like it's the perfect fit, but for others, it's a trap. And for those listening who are probably scrolling through LinkedIn and getting the outcome based pricing feeds constantly, I was at a RevOps event in London. There were three presentations on outcome based pricing, and it's usually framed as everyone should do it. For those listening, what does a good profile for outcome based pricing look like? And what does a trap look like?

**[16:48]** A profile is that you're setting into a very specific vertical and that the outcomes are identical between all your customers and all your users. Coming back to the Fin AI example. They outcome is ticket closed. That's what they do. Although they're serving different type of customers, the outcome is basically the same. We're closing tickets. There are some what exactly is a ticket? What happens if a ticket gets reopened? Do you get paid, etc? But those are the edge cases. So I think they nailed it. But let's back to open AI. I'm using open AI or Claude. I do very advanced financial planning and analysis using Excels,

**[17:41]** etc. And I'm really wasting tokens on that. And I still pay 20 bucks a month. I discovered that my mother uses open AI. But she uses the same thing to how to make a turkey sandwich recipe. Same thing that you can Google, right? So the outcome for me and the outcome for my mother were both getting the results that we're looking for. But for my mother, if you try to capture the value there, it's a Google search, almost free. And what I'm doing, I'm replacing what would have taken me two weeks work to do the analysis and the financial planning. The value for me, the outcome, I would have been willing to pay much more than

## 17:50 — Why outcome-based pricing is a trap for most companies

**[18:27]** that. But they can't charge us differently. They don't differentiate. And that's why when you go above that 20 bucks or the 100 bucks, the next one is to pay based on usage. And they're going like Claude is already introduced and getting used to that. They are like, I think the design is based on usage and code is supposed to go into usage at some point. So yes, that's why outcome based is different when you're selling to a horizontal solution or horizontal segment. Different use cases, outcome means different things for different users. And how can you price based on different outcomes? You can't. And that's why most companies

**[19:15]** who are selling to different use cases can never define what the outcome is. And that's why I think you said it. It's a buzzword. Everybody talks about it, but it's really, really difficult to really nail it. And again, you need to be very specific or vertical needs to be very specific to really be able to do that. I think that's really good guidance. Horizontal versus vertical. So horizontal, it sounds like, hey, there's probably don't even attempt it because the use cases are so broad. It's not really worth the exercise. In the vertical realm, what are some good frameworks or ways of thinking about if your

**[20:02]** outcome is uniform enough across your customers? Because even in the example you gave with Finn, okay, there are some edge cases, ticket sizes might be different, but I'm sure they, hey, we have the calculus to figure out that we have a good median mean of what this look like and we feel comfortable pricing in here. When does the variance look like too much to where, hey, even if you're in a vertical, it might still not be a good fit for you. I want to switch that around. When it's good, if you can ask what is the outcome and you can clearly define that, that's the first question. And if you are able to answer that,

**[20:42]** let's go into the next question. Can your customers define the same outcome and can you agree with your customers on that outcome? So if Finn defines close ticket, can they define exactly what a close ticket means? And again, coming back to the example, if it reopens in two weeks, if it's closed on your end or the customer end, et cetera, we need to make sure that the customers accept that definition. And then the third question is the value similar to all your different customers? And in tickets, for example, probably yes, because closing a ticket on average, your support team needs to spend on it on

**[21:31]** average 20 minutes and then you can put a price tag next to 20 minutes of a support manager. So that is something that we can do. So first of all, can you clearly define it as one across your customer base? Can the customer agree with you and accept that as what you're pricing on? And then is the value the same across your customer base? And if you answer all these as yes, then you probably are in a good situation to do outcome-based pricing. And within those outcomes, are you seeing any differentiation of like in Finn's example, it sounds like it's mostly these cases are

**[22:17]** solved, get these tickets are resolved kind of uniformly, but are there different types of outcomes? Have you seen a company package it well, where there's more than one outcome in their offering that they're pricing against? No, it's a good idea. I haven't seen that yet. And again, that goes, I haven't seen a lot of good examples of outcome-based pricing out there. Everybody wants to say, hey, when you introduce agentic AI, you should price based on outcomes. Great, show me a company that does it well. I haven't seen that much. So if it's hey, this might be for a very select few, very repeatable, very well defined outcomes.

## 22:47 — Roee's three-question test for outcome-based pricing

**[23:11]** That's what that pricing model is for. Do we then mostly revert back to nailing down a usage based pricing model with maybe some other fees involved? How? Maybe we can dive into that because I know I've seen all kinds of different usage based models. There's ones that ramp, there's stair steps, there's commitments and then overage, penalties for overage, blah, blah, all the mechanisms. For a company that's introducing a usage based model or has one and could refine it, what are some best practices for company's pricing that way? Let's start off with the downside of usage based. And the biggest downside is customers hate it.

**[23:59]** People hate to buy usage based products because it's not predictable. Because it's not predictable. That's the main reason. I don't know what's my bill going to be at the end of the month or at the end of the quarter. Thereby Bill shock is a real term. So the CFOs really see, are really scared of scare. They don't like to commit to usage based models. However, there's no other way around it. I think that the industry is going there. And that's why you need to introduce different guardrails and different capabilities to increase that Bill shock. Sorry, let's go back. So the customers don't like to, sorry, just hearing some noise.

**[25:00]** Can you ask that again? And let me start off. Yeah, no problem. So for companies that are not really a good fit for outcome based pricing, it sounds like we really need to refine what their usage based pricing model is. And I've seen all kinds of different levers, accelerators, decelerators, stair steps, minimum commits, overage. What's the guidance for a company that is launching or refining their usage based pricing model? Yeah, let's talk about the reason why CFOs hate usage based billings. It's because it's not predictable. Because on usage, you might get different bills based on how you use it, obviously. And then companies

**[25:54]** in order to create that visibility and predictability, companies introduce different techniques to do that. At the end of the day, you want to create as much predictability to your customers as much as possible to guard them and to also guard you, right? So they want to understand how much they're paying and to cap it or create guardrails or notification, etc. And you on the other hand, you need to report to your investors and forecast how much revenue you're going to make. And that's why you also need that predictability. And predictability is creating those different mechanisms. One of the best mechanisms is to create some sort of recurring

## 26:10 — Designing usage-based pricing CFOs will accept

**[26:36]** base fee and usage on top of that. So that allows you to be comfortable or to be confident you're going to get that base from your customers and that's predictability. And then the usage on top might fluctuate, but then you can define how much. And then you need to create visibility to your customers. Do they know how much they're using in real time? Can they control who is using what? So for example, if I'm buying certain usage based product for my entire team, I want to make sure that my IT are restricted and the marketing team doesn't use more than these, what they're budgeted for, etc. So you need to create that control. And then you

**[27:28]** need to be able to create all the operations around that. So you send billing and you sell your invoices based on how much they used it. And you're able to track every single token back to when was it consumed by whom and how much because if you don't, every bill is going to create that back and forth. Why is it so high? Is it so low? You need to be able to trace all that. I think the first time you send out a massive bill to a customer, they're going to demand the audit anyway, and then you're going to have to go lay down all of that infrastructure to make sure you can report against it. One of the things we're

**[28:13]** talking about earlier that I think is an interesting approach is really going deep on the jobs to be done. And for a company or a founder or maybe a CRO who's working on this, what's the best way to make sure you're thoughtfully going through the jobs to be done and then use that information and mining to inform your packaging? What do you recommend they actually do? I had a workshop yesterday with a new client and we were in this workshop, which is the packaging workshop, and we focused on jobs to be done. And actually, I did not do a good job. I wasn't able to take them from the mindset of, hey, this is the product

**[29:03]** and this is the features and these are the features that we want customers to buy because these features allow them to use it differently, etc. So this is like product perspective. I wanted them to or tried to take them, hey, let's look at the customer and let's think of what the customer is trying to achieve. So for example, they're doing a marketing automation platform, working with the biggest retails, airlines, these sort of companies, US companies. One of the biggest retail companies is their customers and they just want the most basic functionality. It's the biggest customer and they just use one basic functionality

**[29:47]** of the product. And it's like I said, that's fantastic. That's our first package. That is our entry package because it's only just this basic stuff. And let's build packages that grow. So we're hoping that we can take them from just using that basic feature into more advanced features as we move along and package that. So the first thing, let's look at it from a customer's perspective and try to think what are they trying to achieve and what are the jobs that we're addressing. The ultimate test that I do as part of the validation is to put, to create those new packages and to put those packages in front

**[30:34]** of our customers. So I do validation interviews and then I present the different packaging and say, Hey, these are the jobs to be done. Tier number one, this is what it allows you to do. Tier number two, this is package number two. This is the jobs to be done here. And the job to be done for the third package is this. Can you find yourself which jobs to be done describes you the most. And if they're able to pick without any hesitation, that's the best result that we can find. But if they're saying, I don't know, this is me, but that's also me, et cetera. And that's, that's where we fail. So good packaging structure around

## 31:12 — Building packaging around jobs to be done in practice

**[31:23]** jobs to be done. You put it in front of your customer and you say, Hey, where do you see yourself? And then they pick a package based on that. And it has to be one, one to one. Like there's no binary yes or no, it shouldn't be, I don't know. Yeah. And I think a lot of companies we've worked with, I know they haven't gone through that exercise of bringing that validation from their customer base. How much data do you typically recommend? Like how many interviews should you be doing? Is there a certain size of company that might change what those numbers are? But it sounds like a lot of work. And

**[32:02]** I don't know if people realize how much you should be putting into this and investing into this process. What does it look like kind of full scale doing this properly? Full scale. Let's start off with the end goal. The end goal is to bring or to introduce the new pricing and packaging and migrate our most important customer, which is usually our biggest customer to do new pricing and packaging. So that's the end goal. How do we get there? So in order to move our most important client before we do that, we want to test it out with maybe the second, third and fourth and fifth most important customers.

**[32:46]** Let's do how we do that. Let's take the second segment, which is all the second most important segment, and then go back until we do go to the first customer that we want to migrate them to. How do we have the confidence that we have the right pricing and packaging to migrate our existing customers with test it out with new business? How do we test it out with new business? Let's start off with the least important segment region that we have. So I have a client. They're just rolling into the US market, the European company moving into the US. We're going to test it out, the new pricing and packaging in the US market.

**[33:31]** They don't have a lot to lose there. And once they feel confident, they will go back and do this in their most important markets, London, UK market. How do we get to that? We talk to our customers and do these validation interviews that you just mentioned. We test it out with them first and we tell them, "Hey, we're not moving you. We're not migrating you. We're just designing and we want to hear your thoughts before make a decision on this." How do we go in front of our customers? We go internal validation and we test it out with the sales team, with the sales leaders, with everybody that was not part of the design process. And

**[34:11]** how do we build confidence to go in front of that group? We make a design with the right people in the room to make sure that we can introduce it to the rest of the organization and not lose face. So what I've done here is we are mitigating the risk. The end goal is to move our most important client to the new pricing and packaging. And this is how we do that. We test and iterate and build confidence as we go. I have the impression and if this is a wrong take, let me know that you really shouldn't be messing with your pricing and packaging too much, too often. If there's like an end goal and you want to

## 34:41 — The validation journey: repricing without losing customers

**[34:54]** iterate and get to that, but it's not something that you should maybe be constantly changing every year. Oh, we're usage based, now we're seat based, now we're outcome based. Do you have any guidance on how long you should let your current plan maybe sit or there are certain triggers that say, "Hey, nope, this signal means you need to change your pricing now." In terms of timing, what guidance do you give your clients? So yes and no. You should not change because every change creates some mental burden on your customers. But I do believe that we are in a stage where pricing and packaging gone are the days that you set pricing and

**[35:36]** packaging like when you build a company and then don't visit it for five to seven years. Because our products change so fast, because the pace in which we deliver more and more value to the customers is so fast, I believe that pricing and packaging should reflect that. We have reached a point where pricing and packaging should be referred to as product. We keep on improving, adapting. I'm not saying completely changed, but we need to revisit our pricing and packaging. And again, I'm a cloud user. I don't know if you are, but if you are, how do you notice every week, they're changing something about their pricing

**[36:26]** and packaging. Design is free. Code is credit. No, code is not credit, or you get more credits if you use co-work. That was last year's last week's promotion. So they keep on changing and iterating. And they know why because they're launching new features in cloud on a weekly basis. And by the way, they haven't adjusted their pricing, but they are doing different changes to try to capture more value from us. Yes. And in terms of how much, I would say revisit your pricing and packaging, either every product release cycle or sale cycle, whatever is comes, usually I would say whatever takes longer. So if I'm selling six months

**[37:24]** of sale cycle, every six months, I would say, okay, let's look at the last six months and let's see this cohort and what worked well, what did not, what do we need to change? And same thing goes to the product. If we launch a new set of features, should we revisit our pricing? Because we're now delivering more value, etc. So yeah, I believe that pricing and packaging should be looked more often than it used to be done in the past. Yeah, I really like that framework to thinking about it. It's hey, when your product evolves, that's a good time to revisit. And I do think the products are evolving at a much quicker pace,

## 37:50 — How often you should revisit pricing

**[38:13]** which opens up the need to revisit packaging every time, where maybe the innovation cycles were just longer. So you didn't have the reason to go back to that. Well, I think those cycles make a lot of sense. And I really appreciate you walking through this because this is unbelievably complex. But I also agree with you, this is a huge growth lever. If you can nail this, you can make your customers happy while also extracting the right value that makes sense for what you're offering. And I don't think this is something you just cook up in a couple meetings, it takes the research, it takes the thoughtfulness, it takes the pragmatic

## 38:52 — How to work with Roee + wrap

**[38:52]** approach that you outlined, and making sure you have the packaging that's fit for the product that you're offering into the market that you're focusing on. So I think I know a lot of companies that are struggling with this. What's the best way to reach out to you and your firm? And how do you work with companies to make sure they are getting the most out of their pricing and packaging? Best if somebody is interested, LinkedIn. Yeah, reach out on LinkedIn. I also try to post some interesting facts from the world of go-to-market and pricing and packaging in particular. We engage with the B2B companies

**[39:32]** that either the most common use case nowadays is exactly what we talked about. So traditional SaaS companies introducing or baking in AI components and how exactly are we supposed to price on it? Whether it's because we're losing money or because we believe that there's huge value to capture, and we don't know how to capture that. So these are the common use cases that we do. Our engagement is in demand. So we come in, look at the data, build together in a series of workshops. Usually we engage with the executive leadership, the people that can make decisions, series of workshops. And we go through the process that I explained,

**[40:16]** packaging, pricing structure, pricing metrics, and then pricing points. And then we do the validation, rolling it out to new customers and migrating our existing customers. That takes time, obviously. Fantastic. Well, I appreciate everything you shared on the show today. And I'm sure there's lots of people who need help with this. And as we were mentioning, this is only going to continue to change as dynamics and AI offerings change, as pricing dynamics change. So I think thinking of this as a living breathing thing, you need to maintain and take care of as part of your business. I think it's so important and I appreciate

**[40:56]** what you've done and can't wait to follow some of your content and learn more in the future. Thank you for having me. It was my pleasure.