Monetizing SaaS: Episode 4 with Max Rudman, Founder/CEO of Prodly

Max Rudman, CEO of Prodly, built a platform to automate Salesforce deployments after experiencing weeks of manual configuration work at SteelBrick. He discusses how cloud and low-code tools created new SaaS opportunities, why usage-based pricing is gaining traction, and how pricing strategy bridges product, market, and finance decisions.
Chapters
Max, uh, thank you so much for being here. It's been great to get to know you over the last few months. You've had this really interesting and textured career. You've been an engineer, product leader, founder, executive, CEO now. Um, you've worked on, uh, you know, a number of incredible companies— SteelBrick, Salesforce. Can you now proudly— can you, can you just tell, tell us a little bit about your journey and the steps along the way?
Yeah, sure. Well, thanks for, thanks for having me, Fynn. Um, certainly enjoyed our interactions as well. Glad to be here and Thank you for having me as a guest on your podcast. So look, my journey, I mean, really, I think that if I look at like my career and the journey across those companies that you've mentioned, and obviously a highlight has been founding and building SteelBrick, you know, the mission really is kind of really the same and my passion is the same. It's like, how do we make enterprise software, business software faster and easier to implement and maintain? You know, when I look at what we did at CPQ and SteelBrick, right, it was kind of democratize the CPQ category by doing the very same thing. Like I didn't invent CPQ. People do think I did, but I didn't. It actually existed as a category for many, many years, in fact, decades. But the big problem with it was that it was really, really difficult, really complicated, required a lot of, you know, customizations and, you know, and therefore can only be afforded by only the biggest companies. And we really changed all that, right? And we did that by building on Salesforce platform, but that was more of a means to an end, right? Really, the goal was to, to make CPQ low-code or, you know, declaratively configured or low-code as we say now. And of course, Salesforce was a great platform to do that on. And so we're doing it broadly now is really just continuing kind of pulling on that thread. And, you know, our mission is to do this to the rest of SaaS. And, you know, we saw the problem as many, like often happens, right? As you see problems in your personal experience and like the idea for Prodly was born out of the massive pain that we had at SteelBrick with deploying CPQ projects between environments from test environment that Salesforce calls the sandbox to production literally, literally took our most experienced solution architect the entire weekend to painstakingly, you know, deploy all that configuration data that powers CPQ, right, spread across dozens of different tables, objects as Salesforce calls them. And it was just a massive, massive problem. And it had to be our most experienced solution architect, right, because there's a lot of complexity and nuances in the data model. So you really have to understand the data model well, um, and all the interdependencies to be able to do this. It's not something you could just turn over, you know, turn over to an intern or, you know, somebody offshore. Um, so that's, that's how I probably start.
That's awesome. Um, yeah, I think it reminds me of just like how many businesses get started by simply trying to remove friction from a customer's experience. Um, but you, you've already mentioned kind of something that like you're passionate about But can you talk about trends or inflections that you've either lived through or are living through that are really top of mind for you that you're really paying attention to as you build Prodly?
Yeah, I mean, obviously, I think just move to the cloud, right? The whole SaaS was, you know, a major inflection point, I think, that enabled a lot of, you know, a lot of technologies and kind of like the fundamental underpinnings of what, you know, what needs to happen to make business software, you know, easier to use, right? So kind of when you think about low-code, no-code systems, right? Like that's, that's only made possible really by, by the cloud, you know, by a large degree. And, you know, I think another inflection point that's coming, maybe it's already here, is obviously AI, you know. I don't have a good sense yet of what that's gonna do, and I think it may be a little bit too early, you know. But obviously when I think about You know, what does it take to, um, to run a business system? What does it take to implement it? What does it take to maintain it? Right? Like a lot of that, you know, a lot of the kind of solutioning and architecting skill set, I think AI is probably far from achieving, but a lot of that kind of more mundane, you know, hands on the keyboard, you know, configuration aspects of it that probably can, right, accelerate and if not take over completely. So I think there's a big step function in terms of efficiency that's coming.
Very good. What about the way companies are monetizing?
You mean their products?
Yeah. Do you notice any big changes in the way companies are monetizing?
Yeah, I mean, you see this like certainly over the past few years, like the explosion in interest around usage-based pricing and these more dynamic pricing models, right? So kind of traditionally SaaS has been, you know, really enterprise software, certainly like on-prem has been very, very much user-based, right? Seat-based kind of licenses. And, you know, with sort of in the end, SaaS, I think originally started with that for the most part. But, you know, certainly you're seeing a lot of, right, a lot of SaaS leaders, a lot of SaaS startups experimenting with these more flexible, more more dynamic pricing model. And that's really exciting to see all the innovation that's going on there. We actually, interestingly enough, we did try to sort of— at Prodly, we started with sort of a variance of a usage-based pricing model and it didn't work for us. But it doesn't mean that it's a bad idea, right? But, you know, just, I think, you know, as with everything, right, there's not a one size that fits all. So you really have to I certainly encourage everyone to play around with usage-based, and if it works for your business, you know, it's certainly a great model that, you know, certain kind of customers like.
Can you go deeper into Prodly? What are the problems, what are the specific problems that you want Prodly to solve over the next year or two, over the next 5 years?
Yeah, so, you know, as I mentioned, you know, we started with solving this very specific problem of reducing friction, as you said, of streamlining deployments of CPQ configurations, Salesforce CPQ configurations between Salesforce environments. Sort of the, I have this running joke that my second company, I'm solving the problem I created with my first. And what I mean by that is, you know, a byproduct, a side effect of making CPQ declaratively configured low-code and building it on Salesforce platform a lot of the configuration had moved from metadata, like code and scripts, into data, right? You configure CPQ, and there's lots of other applications on Salesforce platform that follow the same model. You configure CPQ largely by creating records of data, right? But these records of data are, you know, really they're data, but they really are like metadata, right? They're so consequential And so the challenge there is like, it's not about the volume, right? But it's about the complexity. It's about all the relationships. And it's about the consequence of making a mistake in, you know, moving, deploying those records of data. And so that's where the automation is really important, right? Because obviously it's a major productivity driver, but also it is a major driver of quality and, you know, risk reduction, and ultimately, you know, it's about driving business agility, right? Like, so when I kind of zoom out a little bit from this, and, and now this kind of ties to our mission, right? It's like, why do we want to make business software faster and easier to deploy, you know, to implement and maintain? Well, because if you don't, if it's too hard, it takes too long. And if it takes too long to make changes, you're not as agile as you can be. And that's a big problem in today's world. Like when, like Salesforce and everybody else talks about digital transformations, right? Um, well, the core tenet of that is being responsive to the market changes, response to your customers. And you know, how responsive can you be if it takes you 6 months, right, to make a change to your businesses?
Very well put.
The ultimate goal is to drive business agility to accelerate digital transformations.
Yeah, it's so well put, and the points are also really well made on the consequences. Maybe you can speak to those consequences a little bit. I mean, the customer experience here is sort of at the center of things.
That's right. That's right.
What are some of those consequences that, you know, Prodly helps customers, helps your customers avoid?
Oh, well, I mean, think about, you know, again, like, you could, you know, as a prime example, this also exists, you know, in other categories. But think about, think about making a pricing change, right? And making an error on this, right? Like, and this is the big difference between the configuration data, like, or master data, and transactional data. You, you know, you screw up an order, well, you screwed up an order, right? That's one transaction. And You know, maybe it's a big order, hopefully not, right? But it's still, it's one transaction, it's one customer. You screw up a change to a product catalog, you can bring down your business, right? Or you can have massive consequences because every transaction that's getting created, every quote, every order that's getting created when that master data is wrong, is going to be wrong. So just the compounding effect is, is massive, right? And then same, same, same is true, you know, in other categories. You think about field service, let's say, right? Like you make a mistake in a scheduling rule, like now all of a sudden your trucks are rolling in the wrong directions and service appointments getting screwed up, right? And, and it's a mess. And I can't keep going here, right? But you get the idea.
I get the idea. It, it feels to me, and I wonder if you agree with this, that the broader quote-to-cash stack is going through a lot of change. Um, do you think that that's right?
Yeah, I think it is. And, you know, it is kind of driven by what we talked about before, which is experimentation with different pricing models and you know, like this realignment between the front office and the back office, right? Like you kind of traditionally had your ERPs, you know, the SAPs, the Oracles of the world, right? Microsoft Dynamics, lesser degree. Uh, you had your front office CRM systems, right? But I think what people are starting to realize, there's a lot of, uh, integration, there's a lot of dependencies between the two, and You know, in the physical world of like shipping widgets, right? It was fairly simple, right? You have your front office system, CRM, where you keep track of your customers, you create quotes, you quote them, you place orders, orders go into ERP, you ship the widgets, you're done. Now fast forward to today where you have some cases, a combination of the widgets and subscriptions, or maybe it's purely subscriptions, and subscriptions could be, you know, fixed price per seat. They could be, usage-based, there's like changes being done, right? Like there's contracts, annual contracts, maybe no contracts, right? If you have annual contracts, changes being made to contracts. So there's a lot of complexity and there's a lot of interdependence and it's no longer like this clean straight line from front to the back, right? And I think that's what's driving a lot of this realignment is folks are like trying to figure out what's the right, like what's the right mix? Where do I put things, right? Like what are those processes? Invest in front office, back office, middle office, right? Like, where does it go and how does it all fit together?
You know, um, I want to see if you think another thing is, is correct or if it's missing something. I, I, everything you just said sort of stems back to complexity that I've tried, I've been trying to organize in my own mind. You know, what are the kind of core pillars of complexity that modern B2B SaaS businesses are having to support? And I've, and I've started to describe them to myself as you've got to find a way to support multiple go-to-market motions. You have to find a way to support multiple and or hybrid billing models. And you, you of course have to support multiple products if the business is scaling. Um, I wonder if, if you think that's, those are the right 3 pillars for operators to really kind of wrap their minds around, or if you think there's a 4th or a 5th, or, or if you'd think about it and frame it differently.
Yeah, I mean, I think that's right. You know, I mean, it just all depends on how coarse you want to get, you know, but yeah, I mean, at the end of the day, right, it's go-to-market and it's product, right? So those are the two big buckets that you have to play with. And, you know, I think in my mind, certainly like the pricing models and a lot of this experimentation with different, you know, dynamic pricing models, usage, etc. I mean, I would put this under the rubric of go-to-market for sure.
Got it. Yeah. Well, supporting this type of complexity or the complexity that we've been talking about ends up being governed by multiple systems. And so I'm curious, could, you know, kind of if you were talking to other product leaders, other engineering leaders, other CEOs, and you were kind of describing how you've thought about architecting these systems internally at Prodly, could you shed some light on how you've built your own stack? Yeah.
So we're, you know, obviously a Salesforce partner and, you know, Salesforce Salesforce is at the core of our tech stack. You know, we use certainly obviously Salesforce for CRM, we use Salesforce for Service, we also use Salesforce for Marketing Automation. Pardot is, you know, the product that Salesforce acquired through exact target acquisition, right? Part of the Marketing Cloud. We use that and then we kind of augment this with kind of a more modern maybe like platforms or specialized platforms like Gong. We actually kind of standardized on Gong as our revenue intelligence, you know, but also for sales engagement. Interesting. Yeah, a new product that's, I mean, frankly, it's a little bit immature, but kind of like competitor to Outreach/Salesloft, right? But it works for us. I mean, at our scale, it's fine. So look, I'm a big fan of like stack, tech stack consolidation and like the fewer platforms you have, the better. But I think really the important thing is certainly when you think about like a customer experience, right? What is it? What is the experience of buying and a product and making changes? And when I say buying, not just the initial purchase, right? But also buying add-ons and renewing, right? And making amendments to your contract. What does that look like? Right? And you really want to make sure that that's a streamlined, cohesive experience for your customers. And in order to do that, you, I mean, you probably need to make sure that like whatever goes into that for you is, you know, really fits well together, which, you know, may mean it's on the same platform, likely does, but you know, you can, not necessarily, but, but likely does, right? And just like it makes it a lot, a lot easier if it is, right? So. I mean, a classic example I run into all the time, right, is, you know, doesn't make sense, like QuotaCash, like how did QuotaCash come to, into being, right? But, you know, a lot of it came from the realization, right? It's really hard to kind of stitch together different systems. Like if you have one system that does quoting, CPQ, another system that does, you know, subscription billing, contract, right? Who owns the contract, right? Both sides need to talk to that. They need to generate, they need to amend. So like, you know, can you make it work? Sure. But it's really, really, really hard, right?
If it lives in different systems.
So, um, like that's obviously why there's quote to cash and Salesforce got into billing, right? And all these other players are trying to come up with their own stack to do that. Um, so not everything has to be on the same platform, right? Not everything can be on the same platform, but you know, I think you really want to think through kind of a lot of these pillars, right? Pricing and, and, you know, like buying experience, you know, provisioning experience is another, right? Like something I know you're working on, right? Does that have to be the same platform? Probably not. But there you probably want to be tightly integrated into the, into the whatever tech stack the product runs on, right? Because that's, that's, that's the lever, right? That's the, the driver of efficiency there.
You know, one thing that I am really interested to talk about is maybe just the relationship between pricing and packaging and the downstream business tools, but also your product. How do you think about kind of pricing and its relationship to the product, but also its relationship to the downstream business systems that might be sources of truth for a CRO or sources of truth for a CFO?
Yeah, you know, it's pricing and packaging or P&P as it's commonly called is really interesting, right? Because there's just, there's so many dimensions to it, right? There's the commercial, like the obvious commercial dimension to it. How much revenue are you getting or not getting, right? It also signals something about your brand and the product value, right? Like Salesforce's price is a premium product, for example, right? There's good reasons for it, right? But that's a signaling that occurs. And then it also obviously integrates very tightly with your product, right? So like the packaging part of it, obviously, right? Not the pricing. So yeah, I mean, I think it's just really interesting. Like it's like at the center of it all. Like when we talk about these two big pillars, right? Go-to-market and product, it's kind of right there. Right there in the middle and touches everything, right? As well as the back office, which we didn't really talk about, right? But it's kind of at the center.
I run into a lot of companies where they might be trying to support like a self-serve motion. So they're billing through like a Stripe and then they might be supporting a direct sales motion. So they've got, you know, Salesforce as the CRM, for example, and maybe they're using a CPQ product as well. And then as they grow, they might, they might even layer on like a NetSuite. And so now there's like NetSuite for, you know, what is initially perceived to be like GAAP accounting, but they actually end up trying to use it for billing as well. And so to your earlier point, like you have product catalogs and contracts and multiple systems, each of which represents a source of truth for a different executive in the business. And it just gets incredibly painful to reconcile. Yeah. And I wonder if, you know, having seen that and felt that, how do you think about avoiding that type of complexity as you build broadly?
Well, I mean, I think it goes a little bit to what, you know, I'm talking about, like tech stack consolidation, right? And making sure you don't have the disparate systems. But, you know, like it's a hard problem to solve. I mean, there's a term for it called omnichannel, right? And so I know like Salesforce certainly thinking a lot about it and the new product that they're working on launching on now called Revu Lifecycle Management. You know, it's certainly, you know, that's a foundational premise to the product vision is being omnichannel, right? No matter how you transact, whether it's, you know, through direct Salesforce or, you know, through partners or through self-service on the website, right? It all comes from the same product catalog, the same pricing goes through the same billing engine. You know, I mean, for us, like at Prodly specifically, it's not a huge issue because we like, we tend to work with larger customers and it's like, we're very heavily sort of direct, you know, you know, we have partnerships, you know, and kind of a healthy channel practice, but it's really more around kind of sourcing opportunities and lead gen, like we don't really sell through channel per se. So it's not like a huge concern for us, but I know it's definitely like a big topic in the industry and a lot of innovation is going into that. Certainly like at Salesforce, I know that for a fact.
One thing that I feel like operators and maybe more specifically founders are maybe increasingly aware of is the importance of willingness to pay in the early stages. In my first company, I felt like that was one of my biggest weaknesses, and I've tried to address that heavily in this second business. I'm curious how you have approached understanding willingness to pay as you've built Prodly.
You mean willingness of your customers?
Yeah, willingness of your customers to pay.
Okay.
Like literally, how have you approached trying to understand their willingness to pay?
And how much they're willing to pay.
Yeah. Like, how have you, like, what have, what have been like the operating procedures or techniques that you've used to try to understand the market's willingness to pay for your, for your product?
So, I mean, look, being willing to pay is obviously like the only thing that matters, right?
Like, the only thing, right?
That's the true arbiter of value, right? Like, people say anything they want, right? But unless they're willing to pay for your product, like, you, you probably aren't creating enough value for providing enough value, right? Let's just be clear on that. Then like how much? Look, I mean, I don't know if there is like, I mean, in my mind anyway, in my experience, it just comes to experimentation. We probably on our third or fourth iteration of a pricing model at Broadly, right? And like you have a hypothesis and it's like, all right, let's try that, right? And you try it and doesn't work or maybe there's some like unintended consequences and make a change again. Like, obviously you don't want to be doing this every day, right? Or every month even, right? Like, there's probably such a thing as like pricing model change fatigue, right? On the part of customers and your team as well. So I mean, yeah, I would say like experimentation is probably the only way to do it. But I also, you know, I think the other dimension to it is sort of the stage of the company. Like, I don't know if you really want to be optimizing for extracting the most money from your customers early on, you know. I just, I think the juice is not worth the squeeze early on, right? So I, you know, like, you, there's so much opportunity, you know, like, hopefully you're in a big market, right? Then like, I would focus my energies on building the product to capture more of the market and like deliver the value than trying to like squeeze like an extra 5% from, you know, any given deal, you know, or any given customer. Uh, yeah, especially customers, right? Because like you want to reward them for being early on and taking a bet on you. And, and like, you know, you know, there's a lot of risk for buying, you know, an early stage startup solution, right? And so like I You know, and also just like when you look at the numbers, right? Like by definition, right, the, the, the early customers, there's not that many of them, right? So like the opportunity just, just isn't there, right? That's what I mean by the juice is not worth the squeeze. You just, you just aren't going to get a whole much more revenue when you're, when you're early stage from, you know, optimizing, you know, certainly existing customers and probably, you know, new deals given the volume. When you're mature, like late-stage startup or mature company, I mean, that's a different story.
Yeah, I totally agree. It's like at the early stage, you're trying to optimize for something different, which is like early customers and oxygen and the product and usage.
Energy. Yeah. Oxygen, energy, velocity. Yeah.
Max, this has been so much fun. Where can people learn more about you and more about Prodly?
So I'm LinkedIn, Max Rudman, Broadly, Salesforce, Tilburg, any one of those will probably pull me up. And then Broadly is at broadly.co, not .com, .co. So come hit me up on LinkedIn or reach out on the website. And if you have a problem that we solve and, you know, if you're in the Salesforce ecosystem, chances are I'll see you around the ecosystem at the physical events that Salesforce puts, puts, puts on. Uh, we'll be sponsoring, uh, London World Tour in London next month, and then, uh, onto Dreamforce in September.
Excellent. Well, this has been so much fun. Thank you so much again.
More from Fynn

Schematic at Operators Guild Demo Day 2026: How to bill for AI credits without a surprise bill

Should you move to usage-based pricing because AI is compressing your margins?

Why raising prices every year backfires (a pricing leader on the Mastercard quota model)







