The Margin is a podcast from MGI Research that explores the evolving world of business monetization. Hosted by MGI Managing Directors Andrew Dailey and Igor Stenmark, the show features candid conversations with founders, CEOs, product leaders, and industry experts at the forefront of pricing, billing, and revenue operations. Each episode dives deep into the strategies, technologies, and trends shaping how companies generate, capture, and grow revenue—from subscription and usage-based models to AI-driven monetization. Whether you're in finance, product, or IT, The Margin offers practical insights to help you navigate complexity and drive growth in the digital economy.
Andrew Dailey: Welcome to The Margin, a podcast exploring the forces shaping business monetization. I am Andrew Dailey, Managing Director and Analyst at MGI Research. Whether a company sells directly via a channel or has a product-led growth model, architecting and managing the quote-to-cash process is difficult. It's even more challenging when an organization has one primary model, and that is introducing a new additional sales motion. In today's episode, we'll explore the architectural considerations surrounding a product-led growth, sales motion, and critical issues to think about before adding a new sales motion like direct selling. I'm delighted to be joined by John Stame, a veteran business systems leader, enterprise architect and advisor. John has more than 35 years of experience designing and transforming scalable business systems at companies like Atlassian, Microsoft and Chevron. In his most recent post, John joined Atlassian when it was still a private company and was involved in many of the key business, architecture and systems decisions. As the company grew from 100 million in revenue to several billion in sales. And as it transitioned from a PLG only sales model to a mix of plug partner and direct selling, he'll share his experience from the trenches and managing quote-to-cash systems in high growth companies like Atlassian and Microsoft, and the considerations of trying to maintain a single or multiple architectures to enable different sales motions. John, welcome to The Margin.
John Stame: Thank you, Andrew. Good to be here.
AD: So let's start with what does it take for a let's just take a product-led growth company. What does it take to architect instrument and be successful and quote-to-cash in a plug business?
JS: Wow, what a question. It's not necessarily easy, right? I think when you think about a PLG, a product-led growth strategy, one of the things that's important is that you're relying on your product not only from an innovation perspective, but your product is doing the customer acquisition, the customer, expansion. And so it's really important that you're getting feedback in that product back into the, the, the back end of the systems that are managing the business. So it's imperative that you're instrumenting the architecture, you're instrumenting the product, but you're also building into the product, essentially the commerce engine itself, the monetization engine, which is taking the orders, processing payments, sending information back to your revenue and back-office systems. And it's imperative that you have a very organized approach to that innovation and governance associated with any changes in the environment. There's challenges with it. And I'm sure we'll talk about some of that.
AD: So a lot of PLG companies will start with a PLG motion and then add some type of direct selling. What does that do from a monetization point of view? How does that change things?
JS: Really tough thing to do. At Atlassian we, as you know, we, built, a flywheel that that almost to this day over 75, maybe even 80% of the revenue growth is in automatic, frictionless sales. And that commerce engine is built into the product, both from a product catalog perspective, quoting perspective, a payments processing perspective. However, there's been large enterprises and governments that want to work with that loss and, and, and large deals, but they want to deal with a sales team and to build a direct sales motion. You need to build sometimes a separate parallel infrastructure, and you have to try hard not to do that because it just doesn't make sense to build, a completely different infrastructure for it. What we did is we looked at and we modeled what are what are the high touch processes that we really need to be successful in a direct sales model. And what you need, you identify very quickly, is you have some new tools that come into play, new applications and architecture that you don't have in your frictionless PLG flywheel scenario. Things like CRM really wasn't there where you're managing customer relationships, managing opportunities, your CPQ engines very different than the quoting engine that's in your frictionless environment. You end up having a challenge about product and pricing catalogs. And do you have multiple pricing catalogs? And if you do, keeping them in sync. You will introduce things like contracts, in a high touch direct sales model. You introduce this concept of a contract that's been negotiated. So you end up introducing a contract lifecycle management capability into that area. So it inevitably has new components that your other side doesn't have. And you need to make really smart decisions about—how do you rationalize that architecture and make it really efficient so that the revenue systems aren't different for those two environments?
AD: Well, just from a governance point of view, how do you put in place a decision framework to help the organization decide what to leave in the PLG stack, what to take out? How do you help work through that process?
JS: It's a real challenge because when you look at a company like Atlassian in particular, very innovative, very nimble and fast, you, when you enter the word “governance” or you introduce governance, there's a push back because it slow—
AD: Immediate organ reject.
JS: Exactly. And so you need to pick a where do you need the governance and where do you want innovation to take over and fail fast and correct fast. But there are some key components of the two architectures that were where you did the needed alignment. Product pricing catalog was one of them. And trying to decide how to either whether you want one central one or multiple ones and you needed representation from product, from R&D, from revenue, from also legal to be involved in where that is and how it's managed. The other thing that you need to think about is those things that are different than the flywheel, like, for instance, a contract lifecycle process. How can we make those things very efficient, where they don't get bogged down? So that again, from a revenue acquisition perspective, it's predictable. It’s accurate and you're not not bogged down in a system where it's not the same as far as the quality of the data.
AD: Is it possible to avoid having two separate stacks?
JS: I personally think it's impossible. I think it's really hard because the when you're instrumenting your product for a frictionless, PLG-led strategy, it doesn't allow for a salesperson to get on there and manage that customer in a direct sales environment, the customer wants the salesperson in the room. They want them to talk to them about the configuration, the order, what they're going to use for the year, what their upgrade strategy is going to be. The salespeople become consultants to the enterprise or the customer in this case. And whereas in the PLG side, you have literally no or low touch with the customer and the customer is making those decisions because it's a very it's very simple, very configurable, very easy to turn on. But for huge enterprises, that's not an easy proposition.
AD: The other thing we haven't talked about is, as a company like Atlassian, others go through this high growth. They not only have to have their monetization engine to keep, keep pace with that growth, but you've got the other, core systems, financials, revenue recognition that also have to keep pace and often you're going through some breakages along the way. How do you keep those things in sync? Or you don't?
JS: Yeah, that's a great question. It's a big challenge. One of the things that we did from an architecture team perspective is we identified key back-office systems that we wanted to monitor their progress and their health and their ability to address transaction growth. Think of a dashboard of meters where you're hitting yellow lines and red lines when things are starting to break and that's the sort of thing we needed of instrument key systems like our ERP, like our customer relationship management, our CRM, our quoting engines, our provisioning systems getting bogged down. And what we would do is we would have governance associated with monitoring those and make decisions about when we needed to address those systems. One of the examples, for instance, that we talked about before is our back office financial system at the time was NetSuite. And for years that we were running NetSuite for over ten, 12 years, and the transaction volume and growth was starting to hit yellow. The yellow flag was starting to hit a couple of years ago and we needed to prioritize some other things in the infrastructure, and we needed to monitor that system while we were deciding whether or not to upgrade. But eventually that system did get moved to a larger and more robust ERP system.
AD: For organizations that have an engineering centric kind of culture. There's always this challenge when you go through this decision of, “do we buy? Do we build?” If you buy, do you take an individual product point solution? Do you take a mini suite? How do you think about those decisions, and how do you get an engineering led culture to open up to maybe embracing off the shelf product?
JS: As you're building out your infrastructure and your enterprise and your scaling, one of the things you want to do is, instead of spending engineering dollars on commodity functions, as I like to call it, you're not going to go build your own financial system. You should be able to leverage ones that you can acquire and buy or rent, and things that are closer to the product innovation, closer to the customer you might want to try and innovate with. And so that was the sort of the main discussion and approach to, to addressing those, those areas.
AD: An outgrowth of the PLG sales motion is you end up with this proliferation of data, data everywhere. How do you, as a company grows? How do you mitigate that proliferation or manage it, at least?
JS: If we step back and think about what I said earlier about innovation and instrumenting the product, as you're innovating, you're constantly identifying new data. And, in addition to modeling the enterprise and understanding your master data, you're also getting new data that you need with regard to the customer expansion and other elements of the flywheel and frictionless approach and what inevitably happens is you have data, a lot of proliferation of the data. What we would try to do is first model the master data elements and we would create data where we call data registries. Think of today like data lakes, but a multitude of data lakes that were keyed off of key areas of your enterprise. So you would have a data registry or a data lake for suppliers, a data registry or a lake for customers, a data or a registry, etc., etc. all the systems would be integrated to that, and there would be a data governance tool, if you will, built into managing that environment to ensure that you had data quality and you were doing the right things with regard to the data, instead of the data proliferating and staying in their siloed systems, you were collecting them from all the systems into these registries and then building your reporting and your analytics off those data registries.
AD: Let's step back from a minute. Every vendor out there is desperate to get into large accounts. They're trying to rise above the noise, and they're trying to differentiate their pitch somehow. What advice would you give to sales exacts who are trying to get the attention of decision makers inside of buying organizations?
JS: And we're talking about the quote-to-cash—
AD: Yeah—
JS: Vendors in particular—
AD: But it could be even more broadly.
JS: It's interesting because especially as you think about quote-to-cash, you have your CPQ vendors that come in and they talk about quoting and they may have some solution to billing and other components, but their key thing is quoting. And then you have billing vendors coming in and talking about, billing. And by the way, we do quoting as well. And now with usage-based models you have metering solutions which do metering great, but they don't do quoting at all or don't do it very well. What I would recommend is that any of those vendors should have a broader view of the world, and either through partnerships or innovation, they speak to the entire code to cash, process and the automations and not diminish the costs and the, the, the, the challenges associated with integrating those components. And we talked a little bit earlier about build versus buy. And I think there's going to be a world where some suite might be great to buy in this whole area of quote-to-cash. But today, even today, there's still very much point solutions. And I think you're going to start to see companies like Salesforce did start to introduce revenue. Cloud and revenue are a whole revenue architecture from front office to back office. Back to your question, I think the sales teams at these vendors need to come in and talk about a bigger picture, because it's not about just coding and it's not just about billing.
AD: And so you're suggesting they shouldn't shy away from the fact that there are integration costs?
JS: Exactly.
AD: There are costs around data. And they shouldn't be afraid of that.
JS: Right. They should accept it and be honest about—
AD: What it's going to take.
JS: What it's going to take, exactly.
AD: Interesting. In your mind, given your experience, what do you think success looks like in quote-to-cash? It's a broad question, but just conceptually, how would you say this is what success is versus not quite there?
JS: I think about it in the context of business metrics and key performance. As an enterprise architect, I want to understand what the business is trying to do and what is their success. Make metrics associated with the whole quote-to-cash stream. And so things like, how fast are you able to create an invoice, how accurate is your billing? How fast are you able to recognize revenue from those transactions? How accurate is your revenue? Once a company becomes public, that's a really important thing that you want to do. You want to get it right because your CFO doesn't want to go to jail the way, that’s the way success looks in that scenario as well. And again, you're monitoring these things to improve them constantly. It's not put in a solution. And it looks great and it's working great. And by the way you're growing 40% a year. You need to make sure it continues to work great.
AD: There's been a lot of talk especially recently around consumption based and usage-based business models. Do you think those have a future? What do you think the uptake is going to be overall? Does it overtake other models or is it just one part of an overall—
JS: Today, it's certainly one model. I think it's attractive when you're on the customer side to be able to only pay for what you use. So I think it might get more traction. Depends on the application. The solution really. But I think there are going to be more of them, usage-based models. And I think up until today, there's been I don't think CPQ and billing vendors have done a great job in this space and I think there's a huge opportunity of innovation here. There are metering solutions now, but it's just another thing to integrate to. And it becomes a very brittle architecture when you have all these moving parts that you need to integrate to. But I think from a customer perspective, it's inevitable that you'll see more of it.
AD: What do you think the future of quote-to-cash looks like in, say, five years?
JS: Well, I think one of the things we've talked about before, a recent innovation that I think will improve it is I think artificial intelligence, agents will help, especially in the high touch environments because, instead of a human doing an order or a quote or negotiating a contract language, you'll have AI agents helping with all those thing, so optimize that whole quote-to-cash process in high touch environments and maybe even in channel sales. Whereas I think in the frictionless and low touch or no touch environment, there might be things that the AI that might help, but I think in those environments they'll continue to be very engineering led, built-into-the-product things in the future. I don't think that changes very much, but I do think there's going to be improvements on direct sales in high touch, environments, too.
AD: Do you think there's any kind of easy button and quote-to-cash?
JS: No. I think it will continue to be hard. Even with the introduction of AI agents, I think they'll still be complexity and that environment, even in addition to that, platforms like Salesforce, Revenue Cloud and other vendors coming into play, bringing suite solutions and large platforms. I think it will still be a very challenging environment. I think there will be always an opportunity to innovate on it.
AD: Let's play a game here. We'll go through a series of questions, true or false, short answers. First one, enterprise architecture is academic B.S.
JS: False, of course.
AD: Of course. It's cheaper to go with a suite than best of breed.
JS: Not necessarily. Not necessarily true and not necessarily false. It depends.
AD: Good consultant’s answer. Putting everything in the cloud is cheaper.
JS: False.
AD: By 2030, AI will redefine how we implement enterprise systems.
JS: I don't think it'll—false. I don't think it will redefine how we implement but it will definitely impact innovation and what the value proposition is for systems.
AD: So by 2030, AI will completely redefine quote-to-cash.
JS: False.
AD: Quote-to-cash will be mature and no longer an area of enterprise investment by 2030.
JS: Very false.
AD: Very false? Next question. Enterprise selling as we know it will be dead by 2030, replaced by AI agents.
JS: False.
AD: And last, in the next five years AI will replace the need for enterprise architects.
JS: Absolutely false. Or is that a trick question?
AD: Well, John, as someone who has ridden the proverbial tiger with a broken tooth, thank you very much for your time.
JS: You're welcome. Real fun, Andrew.
AD: Thanks. So, as we've heard, growing a PLG led business, a product-led growth kind of business model is not easy. There's no easy button you can push. But what we've heard is that as PLG businesses scale, there will inevitably be this need for an enterprise or direct sales motion and figuring out the right architecture for both the continuance of that PLG model, as well as building up the direct model, is something that requires nuance and a real sophisticated governance model to get that right. Thank you for listening to The Margin. If you have questions about today's episode, or if you'd like to schedule a call with an MGI analyst, reach out to us at insights@mgiresearch.com. You can also reach us on LinkedIn, Facebook, and X. You can find more information about our research and advisory work at mgiresearch.com. Until next time.