Library/GTM Vault Podcast 38
When Revenue Models Outgrow the Systems Running Them
Why pricing, CPQ, and billing failures are coherence problems, not execution mistakes
The core question behind this episode is uncomfortable and increasingly common.
Why does revenue break after growth, not before?
Deals close, ARR climbs, and headcount scales. Then margins slip, exceptions pile up, and finance starts asking questions no one can answer cleanly. Nothing looks obviously broken, and yet revenue stops compounding.
Welcome to GTM Vault, trusted by 25,000+ founders and operators building durable revenue systems.
This week’s guest is Mark Walker, CEO of Nue, a modern quote-to-cash platform powering some of the fastest-growing SaaS and AI companies in the world.
Mark has spent decades inside pricing, CPQ, billing, and revenue infrastructure. He has seen the same failure pattern repeat across early-stage startups, scaled SaaS, and multi-billion-dollar enterprises.
It is about why revenue systems fail quietly when pricing models evolve faster than the infrastructure supporting them.
Inside this episode
This conversation breaks down why most revenue failures are not sales problems, marketing problems, or people problems.
They are coherence problems.
Pricing, packaging, quoting, billing, and revenue recognition drift out of alignment. Teams compensate with heroics. Growth hides the cracks. Then scale exposes the limits.
By the time dashboards show trouble, the system has already been broken for quarters.
Listen & subscribe now across:
Discussed in this episode
1:36 Why revenue failures are system failures
4:48 The first signal founders miss before things break
6:31 Why fear, not price, drives buying decisions
10:42 How pricing uncertainty kills deals late-stage
12:42 Why committed spend models dominate AI and SaaS
16:19 Where teams get burned with usage-based pricing
22:04 Why legacy billing systems fail at scale
24:36 How fragmented revenue data makes AI dangerous
32:25 Why fixing downstream friction accelerates GTM
Key takeaways
Revenue does not fail loudly.
Revenue almost never collapses at the close of a deal. Contracts are signed, quotes are approved, finance signs off, and everything appears healthy on the surface. The failure happens downstream, when billing systems cannot reflect commercial reality, exceptions multiply, revenue begins to leak, and teams compensate manually. Growth masks the damage until scale makes the problem impossible to ignore.
Pricing models evolve faster than revenue infrastructure.
Modern SaaS and AI companies change pricing constantly. Seat-based models give way to usage, usage becomes credits, credits become committed spend. The product evolves and the revenue model evolves, but the systems running pricing, quoting, billing, and revenue recognition remain static. That mismatch is where friction is born, and it compounds quietly as the business grows.
Revenue leakage is the earliest warning signal.
Most teams look for churn, pipeline decay, or slowing sales velocity when something is wrong. They miss the first signal, which is almost always revenue leakage. It starts small, often one or two percent, and growth hides it. At scale, that leakage compounds into margin erosion and valuation damage that no forecast ever modeled. This is not a finance issue. It is a system design failure.
Pricing is now GTM architecture.
Pricing is no longer just a number or a spreadsheet exercise. It is infrastructure. When pricing, CPQ, billing, and revenue recognition live in disconnected systems, experimentation becomes slow and expensive. Every change requires approvals, workarounds, and manual fixes. The fastest-growing companies win because pricing is configurable, not rigid. Flexibility is speed.
Coherence beats heroics at scale.
Early-stage companies survive on heroics. Scale exposes them. At growth, systems must absorb complexity so people do not have to. When teams are forced to negotiate deals with customers and internal finance at the same time, velocity collapses. Smooth systems move faster than reactive teams. Coherence is speed.
Frameworks from the episode
1. The coherence test
Before chasing growth, ask a single question: can pricing, quoting, billing, and revenue recognition change together without breaking? If the answer is no, growth will expose the gap. Coherence is not a nice-to-have. It is the minimum requirement for scale.
2. The revenue leakage audit
Before fixing pipeline or demand generation, audit the fundamentals. Contracts, quotes, orders, and invoices should reconcile cleanly across systems. When they do not, revenue is already leaking. Leakage is rarely visible in dashboards. It hides in mismatches between systems.
3. The pricing flexibility rule
Design pricing systems for the company you are becoming, not the one you are today. If enterprise contracts, usage-based pricing, or hybrid models are anywhere in your future, lightweight systems will create drag later. Simplicity now often becomes rigidity at scale.
4. The AI data coherence rule
AI does not fix fragmented systems. It amplifies them. When revenue data lives in disconnected models, context degrades, accuracy drops, and trust erodes. AI is only as effective as the coherence of the system underneath it.
What to do this week
- Audit whether pricing, CPQ, billing, and rev rec live in disconnected systems
- Identify where revenue leakage is being masked by growth
- Review whether pricing experimentation is constrained by infrastructure
- Map where teams rely on manual fixes instead of system design
- Remove one heroic workaround and replace it with a durable system decision
Why this matters
This decade does not reward brute-force execution. It rewards design.
Revenue does not scale because teams work harder. It scales because systems absorb complexity without breaking. When revenue models outgrow the systems running pricing, quoting, billing, and recognition, growth stops compounding and friction replaces momentum.
The companies that win are not the ones with the most heroic teams. They are the ones that invest early in coherence, flexibility, and infrastructure that can evolve as fast as their business model.
Build systems, not heroics.
This is GTM Vault.
If this episode changed how you think about pricing, revenue infrastructure, or GTM systems, forward it to one operator responsible for scaling revenue this year.
Connect
Follow Mark Walker: LinkedIn | Nue
Follow Rick Koleta: LinkedIn | GTM Vault
Full transcript
Machine-generated transcript from the episode video. Speaker labels are not included and some names and product terms may be transcribed phonetically.
[0:00] that really aligns with how people are thinking, how people are feeling. Add on complimentary hardware to software. So I map where clarity exists and where it doesn't. Also wanting to take advantage of this massive opportunity GTM vault where enterprise GTM actually gets built. The deal closed, the quote was approved, finance signed off, and revenue still broke downstream. Not because sales failed, not because demand slowed, but because the revenue model outgrew the system running it. In this episode of GTM Vault, Mark Walker explains why most revenue failures are not people problems. They are coherence problems inside pricing, CPQ, and billing. Welcome to GTM Vault, trusted by over 25,000 founders and operators building the future of revenue. Today's episode is about what actually breaks as companies scale. Not sales execution, not pipeline, but the infrastructure between pricing, billing. My guest is Mark Walker, CEO and co-founder of new.
[1:01] New is a modern quote to cache platform for SAS companies backed by over 50 million. Mark has spent his career inside pricing, CPQ, and billing systems, helping teams see why revenue failures show up only after growth exposes system limits. This is not a conversation about tools. It is a conversation about coherence. So today's question is, what happens when revenue models evolve faster than the systems designed to support them? Let's get right into it. Mark, what pattern kept repeating across your career that pulled you into quote to cash? Hey Rick, thank you so much for having me on. I think I think the I've operated lots of different companies generally speaking in the enterprise system space but you know sort of Netswuite Salesforce um financial infrastructure space but not exclusively because I've also run companies have nothing to do with that and so I've both been watching companies grapple with the disconnectedness of systems and watching them grapple with the inappropriate unified systems like so systems that were great for wholesale distribution like Netswuite but not really great for recurring ing revenue
[2:08] companies and so um I actually had uh sold a company to TA that was a compliance company in this space in the in the Salesforce Netswuite space that was a bootstrap company so we owned it and I was basically planning to go kiteboarding and it was really this product this vision that was created by Tina Kung who's actually the founder of new um I'm actually not a co-founder I'm sort of like the very unusual thing of a CEO gets dropped in at the beginning but it was her vision for how that we can make this dramatic ally better and what the future systems would look like that um that immediately struck me and brought me into this version of quote to cache anyway like this version of quote to cash order to cash aentic to cash service to cash when did you realize revenue failures were system failures not execution mistakes I think um look Toyota has this great saying they go other people achieve average results with extraordinary people running broken processes and at Toyota they achieve extraordinary results with average people running brilliant processes. Uh I learned that from a co-founder of mine at my last company, Yasu Vegeta. And that basically encapsulates the problem, right? During the early stages of a company, you have
[3:20] a lot of heroism, right? And a lot of change. And you have these people who make things work because they have to work and because they would leave blood on the floor to make it happen. Where things break is when all of a sudden the big company gets too big for heroics and you can no longer attract the everybody can't be an A player anymore. You just simply can't hire like just a players. We were committed to spend you know 87 hours a day on solving the business's problems. And so that's when things start to break and they become and those those breakages are system problems. But the interesting thing is that's how that's one way of looking at it from the growth perspective. But the way that Tina got to it was first of all by working at Steelbrick and working at Zora. Um you know Steelbrick Salesforce CPQ we think about it now and seeing the problems that people were having trying to make these two all these systems work together. And then she literally did what you're supposed to do when you found a business and went and talked to like 70 CFOs and revenue leaders and just simply asked them what was breaking and that was so both from my experience of you know a ridiculous amount of time
[4:26] in SAS and Tina's also great experience in SAS but but she actually did the homework and so she came with specific points of failure and that's why news been so successful. It wasn't sort of like a vague idea of what would needed to be fixed. We were very very specific about what needed to be fixed. What's the first signal founders usually miss before things start breaking downstream? I think the first thing that they miss is their revenue leakage, right? In other words, they're growing so quickly and they're bringing on capital and everybody's looking at their at their AR growth and because they're hiring people so fast, they don't really realize that there's a revenue leakage problem because initially it's like 1 or 2%. But if you're actually growing your team at like 30 or 40%, or 50% or whatever it is, like the 3 or 4% doesn't really pop out and it doesn't show up easily in any system because you signed a contract and then you sent an invoice and it's very very hard to get the contracts resolved to the invoices because they're not the same system, right? So they don't realize it. So in every single company that we've been brought into, I wouldn't say every single company because I would like say that that's maybe overstating
[5:35] it. In almost every single company we've been brought into, we found revenue leakage. Sometimes it's a little bit, sometimes it's a lot. MGI Research has a really good paper on this. It says that it that for companies switching to to usage based systems, it can be as high as 5%. But the worst thing we ever found was we found one company, we found $2 million missing AR, right? And unfortunately, the team that found it was not the team that lost it, but they was they that was such a big number that they were convinced that our software wasn't working right. and be like, "No, we definitely know. Here's your quotes. Here's your bills. Here's the orders. Here's the bills. These two things do not line or these things line up perfectly. It's a different number than you build your people last quarter." And so, and that's and so I think that's the first thing people miss is in the fog of growth. They miss the fact that they're actually bleeding that that two to 5% and that 2 to 5% materially affects your growth rate and materially affects the valuation of your company. You said fear is the real competitor. What are buyers actually afraid of? Well, I think there's obviously new is a very big platform,
[6:40] but one of the things we're known for is that um is that we have, you know, a CPQ and a self-service system and a billing system and then the agentic version of those things. And um and the interesting thing is they're all world class like they're all built by people who are complete experts in those areas and they all have the same data model. So you can actually, you know, they work very well together, but people buy them independently. So when people are buying a new system, they're either buying it because they're afraid about what's going to happen, which is either that they're going to outgrow or they've already outgrown their existing system and they need to do this, or they're afraid about not being able to respond to what's coming next. And in fact the the the first one um actually the second one is the predominant dominating factor like the reason why new has essentially everybody you've ever heard of in AI except Gemini or already and there's obviously some customer there's always customers more we always want more customers but like open anthropic glean jasper lora Harvey cursor coder Sierra Anaconda and I feel bad when I say that because I know I've left off some amazing companies right um the reason we have those people is they
[7:52] know they don't know what the future revenue model is going to look like. Right? That's a good example of fear being a very positive driver of a decision. When you're thinking about switching out the billing system for a company though, it's kind of opposite. That is going to that is perceived. It's no longer true. It's no longer true with systems like new. But historically, that was such a bad thing that the fundamental thing that the person's worried about is getting fired for messing it up. So people used to joke that to get somebody to switch a billing system, you had to put a gun to their head. No, I don't think that's sufficient. That's just kind of the situation they're in. You have to put a gun to someone else's head to hit them. You have to basically get them in it totally. And so that's not the case with new. The reason why the most common situation is people buy our CPQ first and then they realize, oh my god, I can just turn on the billing, right? But that's what you got to deal with. It's a very human emotion and we're very very cognizant of the fact that this is a huge decision for the people who are making it and very proud and very gratified of some of the amazing companies who have made it with us. But that's fundamentally switching business systems is not like buying you know a new marketing app or something. When buyers say we're not ready, what what are they protecting? I think when we get into a situation where um and by the way that by the way
[9:03] that response is plummeting. So I'll give you an idea. The average sales cycle for new has gone down by 33% a quarter for multiple quarters in a row. Right? And what that is and what that that is being driven by is people have already done their homework. They've already made a decision that they're going to have to move. And that is primarily being driven by an understanding of the pace of change and that they need to now start testing new pricing models and new go to market models and therefore they can't do that on existing systems. So the fear balance has switched. When they say they're not ready though, when companies say they're not ready, there's two versions of that. One is the correct one which is you don't just simply don't have the right team to go through this transition and the second one is you don't have the right business case to do it right the right business case one really means lack of executive support right but the first one is a real thing you know to do this well open AI went live in 8 weeks on new multi-billion dollars multiple currencies multiple product lines multiple verticals that says so much about the leadership at open AI and by the way anthropic went live in 12 weeks. So this is the same thing about them. You know, 8 to 12 weeks, you know, it
[10:14] seems like a big difference. That's not a big difference for the size of these companies. It's amazingly fast. Billy Piper famously went live fast. We have lots of customers who go live super fast. They had really good teams that were led really well. And the version of not ready that that is true that I think people should pay attention to is if you don't think you have the right team, we talked to people about this. If you don't think you have the right team, you should probably not embark on the project. How does pricing uncertainty increase perceived risk late in the deal? The more uncertain, let's put this right. Let's go to two different examples. There's two companies and they have the same productish and one product is priced on seats and the other one is priced on outcomes, right? Okay. So, the seat one, the uncertainty is am I going to get value out of all the seats I use? Am I overpaying for the product? Right? and and companies deal with this by having different types of seats or you know other types of things right and there's diff obviously a different way of doing that you know we have c our customers we offer everything we sell as you know in a transactional or seatbased model or in a revenue based model and different customers pick different models but on
[11:22] the other side if you go over to outcomebased the uncertainty is well first of all how much of this stuff are we actually going to do we have any top end on what we're spending because at least if you buy like 150 seats you know, you're paying for 150 seats and whatever happens happens. But if you're doing 150 million ticket resolutions, you're like, is that the right number? Is it 150? Are you actually going to resolve 150? Are you going to resolve 20? You what is the right thing? And also, is the definition of resolution right? Like in other words, like the joke I have is like if you're in a call center and somebody phones and they pick it up and they go, "Sorry, we're too busy." And they hang up, is that a successfully completed call? Right? Right? In other words, are you measuring it? So, the types of uncertainty we're seeing is both in the old uncertainty was I'm not sure if I'm going to get value out of these seats, but I can deal with that by price to receipt to adjust for the expected value. On the new models, people are unsure about whether they're buying the right number of credits, whether they've negotiated the right price for them or dollar pool, whether they're out of all the possible products the customer is introducing, have they negotiated the
[12:29] right contract across all of this and this is causing problems. Part of the answer is just give people lots of options. But um but that's what we're seeing in the marketplace. What pricing models are dominating AI and modern SAS companies right now? Very very clearly committed spend models. So committed spend models are models in which the pricing is determined by the amount of revenue you commit to provide to the company in a a defined period, say a 12-month period. So I commit to spend a million dollars with your company. At the million-dollar commit level, I have a pricing engine that discounts all of the possible inputs that you can buy with that spend. And those deals cross um they include subscription elements, they include professional services elements, they include obviously consumption elements, what we often think of as tokens, but also other forms of elements like API calls, lots of different flavors of model or product. And the reason people are adopting those is because the products underneath them are changing so quickly that actually contracting for a thousand of X makes no sense at all. Right? Because the company may not even be selling X by the time you get to the end of the contract. The
[13:39] other thing is that customers are are concerned about contracting being caught overpaying for something where the perceived cost of things is plummeting. So they're you know the in the hyper competitive market the later buying customers may be getting better pricing than the earlier customers and so there's a lot of negotiation around that issue as well regarding brand to be able to provide that level of ondemand customization has not only a revenue function it's impact on the brand completely that's and that's why we get multiple different versions of these committed spend models. So, there's prepaid committed spend. That's kind of like Snowflake or Amazon where you basically you commit to spend $10 million and you send them $10 million, right? Like, and then you draw down that $10 million. Then there's postpaid committed spend, which is I promise to give you $10 million, but I'm just going to get build every month for what I actually do use as I ramp up the use of your product in my company, but by the end of the year, I should have consumed $10 million. And then the question becomes, well, what happens if I don't consume $10 million? I mean, if I do consume over more than $10 million,
[14:46] there's an overage or something like that. But what happens if I don't? Because those things are not easy to back out because the pricing you got was because of the $10 million commitment. So, if say you only spent $8 million, well, you don't get let off $2 million. You get let off some fraction of that because you now have to basically say, well, at $8 million, we would have given you this much. This becomes a very tricky customer retention issue. So we then see things like and also a very tricky revenue recognition issue and a very tricky contact adjustment issue and that we're working very closely with many of your AI vendors to work on. But then there's the third type which is the forgivable post-paid committed spend which is the wink wink maybe I'm maybe I won't bill you, maybe I will. And which just drives the finance team insane.
[15:33] Like so the CRO is going, "No, there's no possible way that we're billing more than 10% of the contract at the end of the contract. That's our policy." In which case, the auditors, the accountants go, then you can't recognize the revenue, right? If you actually have that policy, you can't recognize the revenue till you've actually done it. So fascinating a really good example by the way of how a real pricing problem causes a cascade of issues across systems that are really really that you really need to be quite careful in managing and why having a single system is maybe makes things a lot easier. And if you were to pick one area where teams get burned first when they adopt usage based or hybrid hybrid pricing what would you what would you uh they pick too simple of a system. So the fun when they start out they go they go okay we're going to go with like a PLG kind of our needs are super light because we're just selling to like bring your own we're going to we're at hyperrowth and we're going to make this super super simple and and then they pick too simple a system and they and then they discover now that I'm actually now that now I want to do enterprise contracts I've now got significant
[16:40] footprint now all these contracts are going to end up being different right and I don't have the I don't I either have I now have to try to stick a more complex front end on a less powerful back end. Right? So, so that would say the number one thing people I say buy the systems for the company you want to be, not for the company you are. Unless you think it's going to take you a long time, like do you think it's going to take you three years to get into that problem, then maybe go with something light and simple. But, you know, there's a reason like let me point this out. the fastest growing companies in the world run on on newome ripe and salesforce. So, and it's not that all of them run all of those things, but they are all running three out of four, right? And most of them are running all of it, right? And the reason for that is that in that combination of tools with new sort of like think of it being the quarterback um or being brought in to control all the pricing and everything um they have both the flexibility to do things that are really lightweight. Stripe is famously good at famously good
[17:48] at the ability to meter and manage incredibly complex things as they grow really quickly which metronome is famously good at. the ability to describe incredibly complex markets and to customize their data in a way that describes their business as it is and has the inputs to drive pricing and then a pricing engine that actually works with all of those things, right? So that's like so they so they they may and the funny thing is they buy it in different orders based on the uniqueness of their business. It's not like you have to buy everything at once. They go, "Okay, we're going to do this, but our plan is that then we're going to add this and then we're going to add that." But but literally what you don't see is like Bob's bait and tackle. They have side solution and some madeup CRM and like any of that because these companies are too going too fast to mess around. They're just going for let's pick best of breed, best of breed, best of breed and and also all of those companies are fully integrated together. Or let's put it this way new makes all of those companies fully integrated together. So we're the glue that that brings it together. Make sense? About a year ago, I was using Hen paying 30 bucks a month for uh the same amount of usage that I
[18:59] pay 130 bucks a month now. And a pricing restraint back then because, you know, they were growing so fast. They hadn't figured out the modular approach to how they can have these add-ons to their um their base SAS offering. And over time, they they got there. So, I can see how they were leaving revenue on the table and why it is so beneficial for these companies to architect this from the get- go. It just seems like it leaves then the CRO to be a lot more creative with how he can configure the revenue team's budget because when you have access to ondemand product analytics and you could identify what's really moving fast, they're leaving money on the table and and if you can easily configure your platform to to provide that solution, yeah, it has a huge impact on revenue. Yeah, I think I think um look, you know, if if OpenAI and Anthropic and all the companies I mentioned all do
[20:07] all their homework and all actually pick the same stack, not necessarily 100% the same stack, but the same, you know, three out of five, you know, four to five, three, three out of four, four to four stack, then basically say, well, look, all these really bright people with absolutely no revenue constraints have picked the same stack. So there's probably a good reason. So as a young company having that as your plan, not necessarily buying it all the same way, but having that as your plan is probably a good idea. And then the other interesting thing is is that those companies these companies work well together, right? In other words, so we have a billing system. Stripe is a billing system, right? The what makes Stripe billing, there's reasons why Stripe billing system is great, right? And there's reasons why news billing system is great. And then you can sort of think metronome as being an input to either of those billing systems or a kind of a billing system itself. Right? Now, that's owned by Stripe now. But the point of it is is don't pick things that don't have a really great ecosystem because that will be limiting. But if you pick one of any one of those vendors, then then you're in you're not going into a blind alley. You actually have, you know, this this you're going to this ecosystem that uh that basically has to work together. We actually like
[21:15] working with these companies but has to work together because of the multiple billions of dollars of business like many billions of dollars of business that's already going through the collective integration integrated version of of that stack. Make sense? Why do you think uh legacy pricing and billing systems fail faster than teams expect? Well, I think if you'd um set up legacy pricing in 2010, um I don't think you'd be having this problem. I think that people would be reviewing their pricing. You know, the innovative companies be looking at changing it every 6 months. That that would be like 20% of the market. Most people would look at it maybe a year, maybe every two years. And they're changing the what, not the how. So they conventionally didn't. And this is what made it possible to use disparate systems because you couldn't change it very quickly, but you didn't have to. All right? So I think what's happening now is there are two major threats that people are facing. One is the actual pricing model threat where somebody actually just starts selling a competitive product in a way that makes more sense. And I give you a good example of this. We all pay Amazon or
[22:23] most of us pay Amazon a h 100red bucks a year for the privilege of overpaying for things from China, right? It's not actually free shipping. It's built into the price of the good. Amazon charges the vendor for the fulfillment and that's built into the price and that's why we're overpaying for things from China. But it makes sense to us as pricing model. So the sent number one is somebody innovates pricing in your space that actually makes more sense to your customers and therefore forces you to adapt in a way that might basically and you might not be very good at it and you might churn revenue. That's what problem number one. Problem number two is that somebody enters your market really freaking fast and they they literally because they built the software so fast, they're literally going to sell it at a fraction of the price. And if you haven't bound your customers into a chain of value they feel very comfortable with or they go, "Yeah, I know that's like that new thing, but we don't really care because we buy all of this from this company." Then you're in trouble. Both of those things require you to have immense pricing flexibility because at a scaled company, you need to be able to change this without churning revenue. Like it's not so much you return customers is that you will lose like if you innovate your pricing in a
[23:34] way that drives your $500 million subscription business down by 10% you have totally messed up. And that's uh that's what's that's why they're failing. They're failing because people need to experiment really quickly. They're also failing because the re people are realizing the revenue leakage problem gets worse with usage. So that they they actually it's a different problem. Like there's a finance form of failing where they go sorry this isn't working at all we we're leak we're leaking revenue but the more common one is we just can't change fast enough that's the most common reason I want to dig into sometimes when you don't have some companies don't have the infrastructure but they want to dive into AI but the issue is they have fragmented revenue data and so makes it more dangerous can you talk about some of the dangers there right so there's two aspects that one is they want to dive into introducing AI products The other one is they want to diet to you using AI to more completely optimize or understand whites space and other things. Right? I think you're referring to the second one more than the first one. I'll give you an example. So I recently I have a painting and I
[24:40] hung it on the wall. It's a beautiful painting of a young woman in a in a bathing cap. I think 1920s really a beautiful portrait by an art artist named Kelly Grace. And I wasn't sure that I'd hung it in the right place. So I asked one of the AIs to paint me a picture about where it should be positioned in the position that it was in and it did. But when it painted it, the painting it painted in the picture was not the same painting that was it that originally taking a look at. It was actually a different painting and interestingly a very good one. Like in other words, if I'd walked in the gallery and seen the second painting, the AI generated painting, I probably would have bought that too, right? So So why am I telling the story? the less typified the reason it did that is it it didn't actually have enough context to know that specifically I cared about the painting itself and maybe actually I didn't right and so so the less typified or the less context AI has for your problem the more difficult it is to be accurate in its answer right and so if you have disperate systems disperate systems mean disperate data models and therefore when the system is trying to
[25:48] understand what's going on it's trying to understand how the same thing is represented in multiple different places. And the way it will do it is just the way a human being would do it. The reason AI is worse at that is because humans are worse at that. Like because basically if I say to you, hey, I've got two spreadsheets. They both have exactly the same data model. The one actually represents, you know, all my quotes and the other one represents all my orders. Can you help me understand what my revenue might be like in a year? Right? You go, yeah. Right? If I go, hey, I've got these two spreadsheets. one represents like, you know, zoo animals and the other one represents shoe sizes of people I've ever met. Can you use this to come to some reasonable assumption? You would hope that the answer is no. But if I'm using an absurd example, but imagine they're just slightly different, then what you're going to get is an approximate answer and you don't you don't know whether that approximation is useful or not. So having disperate data models, so no has a single model that goes all the way through is a massive advantage. I'll give you an an idea how this works. So our agentic has been described by some of the major AI companies as the most advanced transactional agentic system in the world. What they mean by that is it
[26:56] works from anywhere like not just in Salesforce but also in Stripe and also in Slack for example. And secondly, it does exactly the same thing that you can actually do as a human being. But it also understands when you don't ask a full question and asks you to fill in the details. And so it does that because it has very very high context. And that's the problem you're going to get into when you have different different systems. Like if you have different systems, your context will be less acute. The And by the way, this doesn't not to do with one model being better than the other. Doesn't matter which model you throw at it. If you throw at two different data models and you don't have really clear alignment, it'll just be like a person trying to solve it. Yeah. Where where do hidden quote to cash bottlenecks slow deals without teams realizing it? In a perfect world, your deal team would like to be able to with appropriate constraints around approvals be able to offer what exactly the customer would like, the perfect balance between what the company would like and what the customer would like. And people don't people don't normally think that the ability to customize contracts and make them exact even if actually the economic output is the same going back to my Amazon example but the way in which the
[28:04] waiting is done makes sense to this customer that flexibility which companies have at the beginning of their life when they're basically using like word and a spreadsheet or whatever you know panda do or something they can just put whatever they want in a quote right now it's okay because they actually can hand bomb it into the billing system so that's okay At scale, what happens is that end of quarter, people are trying to get things done and they literally can't describe. Either the reps can't do it or even the order desk can't do it or even if you did it, the finance team can't bill it. And that means that there's that you're trying to negotiate with two parties, right? You're trying to negotiate with your customer and your own finance team. like one of the major companies we're dealing with, they literally can't make a change in pricing to close a deal without talking to an engineering team, right? Because they have a homebuilt billing system and so it's like you have to talk to the engineering team, right? Imagine how much that's going to slow down your your thing. So yeah, big bottleneck.
[29:01] What accelerates time to value without adding headcount? Um so ours obviously you know a thing that massively does it is if you just actually have a fantastic solution that meets people's needs and people start to understand the use cases and and do that right that's so that's the classic the classic thing but being able to go into a conversation with a customer and say we have multiple different pricing models for the same thing because we have customers who look like this we have customers who look like that and we actually are completely dedicated to bringing uh making pricing that works not just this a beginning of a multi-year relationship that that is a superpower and we do that at new we literally say how would you like to buy it and people follow their own journey. Imagine two companies one has a thousand customers honestly they they a thousand customers bill $100,000 a year and the other company has uh 100,000 customers they bill $1,000 a year. What the value of all the pieces of our system is is massively different. the price for those people might be the same, but the structuring of that price and what drives it might be quite be quite different. So that's the one thing. The
[30:08] second thing is going back to our fear conversation, when your customer comes talks to you, they're not really trying to figure out whether they should buy your system. They already kind of know that they should you're in the top three by the time they're talking to you. What they're really trying to find out is why they shouldn't buy your system. So you should probably start there. You should probably just start talking to them about why they might not want to. And like in other words, if you have Nvidia came to us and said, "We love what you do. We'd love to." And we're like, "No, no, you you need logic. We know your business. We know it. I mean, we would love to have you as customer, but tell us more about your business case, but we would be very reluctant to do that. What is that? What happens? We I mean lots of street cred. You may you obviously I still regret that we don't have video as a customer. They're the amazing company. You know, most exciting company in the world. you know, perhaps maybe leaving out, you know, some of the customers we already have and and so but um but I think we should take that attitude.
[31:02] Let's get on the customer side of the fence and let's basically have a have a straightforward conversation with them about whether or not why they wouldn't like why they wouldn't be a good fit for for our company. And and the long and short of it's not like they're never going to find out. They're either going to find out before they buy the software or after they buy the software. So, you might as well just get to the point. And if you do that, you can speed up things. Remarkable. Yeah, that I can see how that stance is going to help you guys on your instead of going for a win really uh prioritizing the relationship and and what the company means for the long run. Well, why why does fixing downstream revenue friction speed up the entire GTM engine? Right, we talked a bit bit about it already in the extreme the extreme example I was talking about with the company that literally couldn't actually propose new pricing.
[31:51] um because they had to talk to an engineering team. That's not usual. That's a that's an unusual level of um complexity, but they often are situations that are that are like that. So, I think the um the number of different systems you have greatly impeded the level of flexibility you're able to offer, but that's probably not the most important thing. Unless you're like an omniscient genius, it massively impers impedes the number of experiments you can run. That's the big thing. It's not that you can't like go for this one customer cuz honestly for this one customer like it's really necessary. The CRO will mandate it and the CFO will figure out some way to get it done like you know we have to do a manual building process on this customer or I don't know what we'll do right but it's the hard thing about growing innovating and go to market is that you own your experiments.
[32:42] I you know I say like if you basically price based on the number of you know penguins somebody owns right you're stuck counting penguins for the next 3 to 5 years. The reason I pick penguins is they all look the same so they're hard to count. So the um but maybe just cuz I'm not a penguin but the um but the the point of it is is is you've now locked yourself into something that is actually going to be really hard to do. And so but if you actually then go oh it's okay because actually even though if we if we you know say for example some of our customers they come in hey we're not sure we're going to do this we're actually going to run the first version of this with new and then if it turns out we're going to do this at scale you'll have conversation whether we should be doing this in new or whether we should be doing this with new plus metronome or maybe just metronome or maybe new test tells metronome what to do but that kind of flexibility allows teams to go this and the finance team is like yeah do whatever new is completely integrated to both ends of things will be totally fine. You mention completely integrated system. Let's just grow, right? And that's the big thing. It's not that people couldn't do the thing that they knew to do. It's they couldn't do they couldn't test to find out what they should be doing. And that I think is the biggest. In fact, I don't
[33:49] think that this that I don't think I'm actually, you know, bring any news to the major to the executives at at many of the companies that are looking at all of the people I mentioned. They all get that that's the number one challenge. They all get that the that that experimentation is the biggest challenge while supporting the three or $500 million of revenue or in some cases billions of revenue some of our customers that you already have. They have to do both of those things at the same time. Why is the next AI wave in revops and not chat bots? Well, I think I think it's over let's put this way. It's not just in chat bots, right? I think that you can think of so new is really a revenue infrastructure company, right? So all of the things that uh we have um all of our capabilities are really sitting on top of an AWS stack, right? So you can more think of like the AWS engine is the heart of it and and that includes our agentic. So agentic you know connects to that what what the future of this is is agentic stored procedures gentic like basically you know agent agents that actually do things you know for example
[34:58] you got to think of agents now as a programming capability not as a chatting capability now some of the steps in that may involve interacting with somebody with something that does have some kind of chat modality hey I'm on Slack I go to Slack and I go hey new can you, you know, spin up a new renewal quote for, you know, company X. I want all subscriptions and, you know, all of our contracts with them. I'd like a three versions like that. It can be a chat a chat interaction and they never even go into Salesforce at all. They just do it through Slack. That's coming really really quickly and that's a chat modality. But the way that got built, the way that actually was executed is basically software. There are and you can imagine the the scheduled versions of the same thing, right? that is basically using agentic and what that means is that non-engineers will be able to program really really powerful agents which we're already seeing directly within the models well that will also emerge in software and you know not in the agent forcy way where it's a lot of development more in the literally I write a prompt like in new to program what we do you literally write the
[36:06] prompt and you know you go I would like this kind of summary to go with the approvals and this is what I want in the in the in it and make it kind of, you know, reasonably dense but not overly dense because the person wants to read it really quickly. That kind of thing. Take a take a preview against a quote. Okay, that's it. But I like it to be more like this. That pro way of programming is going to be very very important. And this this orchestration would also be updating the whatever their single source of truth is their CRM on the back end I imagine. Yeah, absolutely. And in fact maybe lots of other things too or maybe drawing from lots of other things. You know you can imagine um you know hey our policy for a renewal policy is dependent upon um their midyear growth rate which is measured from new and their their sees score out of gains and in fact how much of their product they're using from gains. We got that done and you can imagine that that that like procedure is actually talking to multiple systems and then maybe updating a score in Salesforce but actually also figuring
[37:16] out what to set the uplift flag on new. You can imagine and this is not like science fiction like this literally that's what news how new is designed and that's how everybody's got an MCP server. That's how they designed the design for interoperability and the design that you don't necessarily have to program it because you can expose the things in a way that makes things super super efficient. It's very exciting. It's very exciting. Those product integrations are letting the whole revenue department have access the dynamic data in real time and also be able to collaborate so much more efficiently. And as a result of that 10x the expectation that teams are going to be a lot more efficient happens through the infrastructure first because if you didn't allow this to happen the teams wouldn't be able to collaborate. I think there's two big impacts. one is the 10x output or whatever x output and then the other one is enablement, right? Like you imagine that um no matter how good a system is if you know I hire Bob or Mary or whoever off the street and matter what they've already known they literally don't know how my pricing and packaging works and if I and they're
[38:25] trying to put a quote together and they've never done it before and but they do know what the customer wants to buy because they've had the product training enough to understand that and they are able to basically be guided through the pricing very much like guided selling but a guided contracting that's actually in new now it's just in beta. It's being released right now, but that's coming really quickly. So that basically people like, you know, even the most complex things like please, please swap out this product for this product in this mid in this three-year ramped contract, you know, effective this date, like that stuff. That's an enablement. That's a massive enablement gain because you literally now don't have to go and explain it to somebody else. You can literally just, you know, send send a Slack message or or type into a chatbot and then what it produces in that case is either an output or it can it produce actually an interface, a new build. The chatbot isn't an answer. It's an interface. It's it's a new version. Think of CPQ as a different thing now because now what you've got is a bunch of different options that you can pursue that are basically software, right? It's basically like a software interface. So,
[39:31] so the person goes, "Oh, okay. Now they see that I just want to go right into the quote line editor and I'm just going to adjust the discount a little bit because that's easier to do than actually change. So it's not like chat or quotine editor, it's chat to quote line editor. And so I can see how this impacts sales and customer success teams. And then having this access to being able to change the pricing so dynamically and offer different bundles is going to be huge for marketing and growth to experiment because now you can run different campaigns to see what ICP, what verticals, what kind of configuration of features is going to work best for audience that we're going after. And that allows you to do so much more with growth and marketing. That's super exciting stuff. And also remember also for finance teams. So the ultimate flexibility comes when you actually have not just this really a powerful front end and middle and so the CPQ and the and the revenue life cycle management piece but when you have the billing connected to or you have this integrated billing environment because then the finance teams are literally like we're just paying attention to whether or not this is an economically good idea. Run
[40:42] your experiments but the finance team has all the analytics. They can do the analytics by product. They can do analytics by you know campaign the this amazing in fact most of the major deals that we are seeing in the up market you know the solid mid-markets you know $300 million and up those are seale driven deals they're CFO or CEO driven deals they're basically like do this either to get us out of the strategic position we're in or do that so that we have the billing infrastructure before we get in that strategic position that's this way so So they they even when they don't actually buy the billing system, they're buying the CPQ because they know that the billing system is there and therefore they know that either their existing billing system or new can handle this case and let's just go right and they don't worry. They'll go oh we'll worry about the revreck getting it aligned. So there's a lot of companies basically saying because new has a billing system that's really really powerful, we don't have to make the decision whether to switch billing systems right now. We could just augment for our tests and that would be a perfectly good answer. Right. So, so there's a lot of very innovative and interesting people. You know, people
[41:50] kind of think of CFOs as not creative and not the CFOs we're running into. really creative and being very quite aggressive in how they manage this transition through billing system um from CPQ and billing system is and uh I I assume that's your primary decision maker that you guys are targeting in in most cases or would it ch change based on whether it's mid-market or enterprise level customers? Yeah, I think it's um as you move up to enterprise, there's more CIO COO involvement. Sort of about $500 million and up. You have more CIO COO involvement. Um there are obviously companies that are primarily engineering first companies that went an awfully long way with PLG where um CIO DTO can actually be really important because they want to get out of the business of doing billing because that's not the that doesn't bring any unique value to their customer and uh you know one of our customers saved I think was like eight engineers that's a that's a huge saving right we should have charged them more but the uh but we're super happy so it can be different but the most common
[42:56] is the CFO OS the CRO and the CFOs have a problem solving a problem and either one or one of their teams comes in but they both know that there's a two-ended problem. They may not know how to solve it, but they're interested because they know we have CPQ customers, we have billing customers, we have both, we have endto-end customers, and they're trying to figure out where they fit considering this is uh in order for it to really work a teamwide solution. Am I correct? What's that timeline look like? There's many many different options. Some companies like OpenAI we were talking about because I can talk about them specifically because they have talked about it. Um they they just went with go to market. They basically thought of it treated like hey we got lots of smart people knew incredible data model. We have a plan for what this is going to look like downstream but we don't necessarily have to do that right away and they just went CVQ first. Other customers hey we're moving heavily into usage based things or outcome based things. we actually need um full end to end and they make the entire decision right away. So the roll out really depends upon what the scope is and what
[44:08] the plan is. Obviously if you don't own the whole thing then you've got the integration question and and how how's that going to be handled and that will vary by by company. Obviously if you're a certain scale those integrations have to be but for example we have integrations either existing or coming out very shortly with you know workday and netswuite and intact and business central and but also real and campfire and sphere and aval I'm living with some amazing companies we have lots and lots and lots of integrations and the reason for that and actually partnerships with billing platform and uh we have sis who are doing things with um with zone billing. So we have lots of lots of flexible ways in which you can become a customer because um and that will affect how the rollout goes because you know if say oh well actually there's a known way of using a you know new with this system to solve this problem then great person's most likely going to go I'll do that then I won't burn the entire thing.
[45:08] That's not as good in my view as using new all the way. You don't get the same analytics bounce but these are all good companies too. So the customer can make their own decision about where the break point is. Make sense? Are there any decisions you should never automate inside revenue systems? I think that it is just as a matter of compliance, you shouldn't be automating all of your approvals. But I think that you know one of the big happy things for most people who have dropped our approvals pro product is they realize they can automate a hell of a lot of them because you know like in other words the more point is you could like it it went through and it got screened not necessarily by a human being right and so particularly with the new agentic version of approvals pro that's coming out but but I think it's a matter of principle there are certain changes that that from a compliance perspective if you want to survive an audit or you just want to basically not dig yourself a smoking hole in the ground. Probably paying attention to what those contracts are and making sure that you're protecting your margins and your unit economics is probably something you shouldn't be doing. After that, I think thinking about what pricing should be. I
[46:16] don't I think people are very long way from having an agent go, you know what, I think you should sell your product as I think that's a long way away. I think that people just then want to very rapidly implement it. I think uh and I think that but everything else like actually actually we have a product coming out our version of of contract life cycle management called jur and it automates the review of contracts right and basically decides what level of approval executive approval it needs based on the severity of the red lines right and so you know that's a pretty severe level of automation and we use it internally it's amazing it's like cuts like hours off off that and and uh and it's uh that's a good example of automating something that people really never thought that they could automate. Yeah, I love that. And when do founders misunders and what do founders misunderstand about speed versus coherence?
[47:06] Um, yeah, this is a tough time to be asking that question cuz speed is the ultimate feature, but I would say coherence like having a coherent system that does everything in a unified way is speed. There's this old saying in the army, smooth is fast, slow is smooth, so slow is fast, right? So that's why the army always seems like they're not doing like they're not doing anything and all of a sudden like they they've taken an entire division and moved it over a mountain, right? And they did that by very methodically doing things. That's what business systems should be like. You do not want heroic going on inside your business systems. In other words, having it having the right infrastructure, having a really really oh, I see this goes into this and this goes into this and they're one system and it makes it really smooth. Smooth is is which is really what coherence is. Smooth is fast. If you're not smooth, you can't go fast. You're just going to break things when you go fast. And I think and so that's why today where going fast is not is unavoidable, right? Like you know, if you got a 20% growth rate now, your company's in trouble. And so times have changed. Yeah, that's huge, right? And so I don't I think that'll
[48:14] even out after a while, but but but there's that perception and so companies want to break out of that. The answer is get smooth first, then you can go fast. Like to move on to the rapid fire section of the pod. Mark, in one sentence, first instinct. What is one broken assumption inside quote to cash? The broken assumption is that you should buy them. You buy one of them first and then buy the system that works best with that other thing. People think that it's too big of a problem and they should just they should buy they should bite off in pieces. Biting off in pieces is way more complicated. What is one sign pricing has outpaced systems? Well, this revenue leakage is the biggest example but before that your finance team going why did you sell this? What is one mistake founders at 5 million to 15 million ARR keep making? They think their problem is a quoting problem when it's actually u a growth engine problem. So they they they buy the simplest possible system when actually what they really need is to let to to to implement something smooth and powerful at a time when it's
[49:21] easy to do. So what is one belief about CPQ or billing that is simply wrong? The the belief that about CPQ and billing that's simply wrong is that they are different things. CPQ is literally configuring billing. That's what it is. That's why we do it in systems. And so thinking about them as different things is just setting yourself up for pain. For years, GTM rewarded speed, faster deals, faster launches, faster growth. The next era rewards coherence. Revenue does not fail at the close. It fails when systems cannot keep up with the model they support. Mark, thanks for showing us what modern modernization looks like. When systems, data, and judgment align. This is GTM Vault. Build systems, not noise. Thanks, Rick. The GTM operating system for teams building repeatable revenue.