Pegasystems Inc. (PEGA) Earnings Call Transcript & Summary

Welcome to The Barclays TMT Conference. My name is Vinod Srinivasaraghavan and I work with [ Ryan Mount ] on the U.S. Software Team. And today, I'm delighted to have Ken Stillwell, the CFO and COO of Pega here.

Thanks. Thanks for the invite. Glad to be here.

All right. So look, I want to really start off talking about kind of Pega's journey over the last several years. 3, 4 years ago, you were -- before you started your business model transformation, you were a different company. Now you're focusing a lot more on the cloud. Automation today is, again, much more important just given what's going on around us. So can you just talk about how the changes you're making are allowing you to better serve some of your customers and how that transformation is kind of playing into it?

Sure. I think there's 2 -- if you stay away from the actual like economic transition and you talk about the transition of how we're supporting our clients, and how the technology enables them. There's 2 pretty significant shifts or evolutions that happen. The first one is around the way that our product, and neither of these -- this is not in any order, but the two big ones are one is the way that our product is used and deployed and managed and that would be the difference between Client Cloud and Pega Cloud. When I started in 2016, we had about $25 million in Pega Cloud ACV and next year, we'll be approaching $0.5 billion. So that's a bit a big transformation of the way that we manage the client environments for our clients as opposed to just selling them software that they deploy on a server and they, quite frankly, just let it sit there and update it whenever they feel necessary. So that's one big shift. The value creation around that is obvious in that -- we're helping to manage -- fully manage the offering. But the other part of it, which is not as obvious is the evolution of the product, the evolution and new features, functions, capabilities, security enhancement, et cetera, are much easier to deliver to the clients. And therefore, they can buy those to the extent that there's actual value creation that's incremental to what they purchase, where they couldn't do that as easily when we were selling something more in an on-premise world. The second transformation is this movement kind of that happened probably in a bigger way like maybe 10 years ago, which was the movement away from just selling a process automation platform to selling a process automation platform that can be configured and has out-of-the-box configurations to be able to do common use cases. So when you -- if you go back 10 or 15 years, Pega was really a process -- a business process management tool where the use cases were somewhat bespoke that were built and had a lot of configuration and customization. Now if you look at the use cases, they're much more the process -- the business process management, the heritage is much more orchestration process, connecting to other systems to help institute kind of end-to-end automation, trying to keep it away from physical human beings. And then there's also a whole suite of solutions that we sell that are leveraging the power of the platform but have a configurable kind of environment where it's common use cases, things like customer service, one-to-one customer automation, things like loan origination or underwriting or policy renewal, things that are common use cases for the verticals that we're in.

That's really helpful. And I just want to touch on where does low code play into all of this? Is this something that is complementing the business process automation? Or is it something that for some use cases, it actually replaces some of it? How does it work there?

So I think there is at least a reasonable amount of confusion in the marketplace about what low code is. So I'll give you my perspective on what low code is, not to say that other views aren't more accurate than mine, but this is the way we think of low code. There is -- low code is a technique. It is a mechanism. It is a capability. It is the way you design and develop enterprise applications in a way it can be reused, it can be scaled. It can be done by non-kind of Java, C++ developers someone drag and drop using the UI to really build out robust enterprise applications and also future-proof them and be able to evolve those applications. That's what we think of when we say low code, Pega, that's what we mean. There is another use of low code, which is something that is really focused on very simple use cases that are small numbers of users, they're not complex that a business analyst can actually can create and construct a very simple -- an example of that might be, I need a COVID-tracking app, that someone can log in and say, yes or no. I do have a temperature now, am I vaccinated, no. And it kind of very simple use case. It could still be used by hundreds or even thousands of people, but it's a very basic application and would be built with a low-code platform. We have both but the real value we focus on is enterprise scale, application, design, development and evolution that is done using a low code. We are not in the business of selling at scale, tiny use cases across the mid and down market, where our enterprise clients will leverage both but we're an enterprise seller. We're not a mid-market or smaller use case seller. So that's kind of the difference between -- that I view between low code as a feature and low code as an application.

And that's helpful. Can you talk about the competitive environment in that context? Because I think there's some confusion around that as well.

Sure. So in the enterprise low code, you've got people like ServiceNow, Microsoft and Salesforce and Pega and Veeva and other companies essentially have a platform, and they say, look, we built this platform. We have common use cases, and you can configure them, you can change them, you can evolve them. You don't have to write code. All of those I would characterize as having some level of low-code capability in terms of -- and then the other side, you're talking about things like Smartsheet and Airtable and monday.com and places where you're really doing kind of almost your building an app that isn't probably going to be enterprise, isn't going to be scale and tends to be just a -- and I don't mean this in a derogatory way, but it's really like kind of the capabilities of an excel on steroids a little bit. It makes it a little bit more capable and maybe you can share it across users and you can create certain process. But it's not something that you would ever like build, say, a loan origination application where you might touch 9 different vendors in a step in dealing with confidential information, cross-border warehousing lines, like -- so that's an example where you wouldn't use one of those solutions to build that, but there is capability. So we don't compete. That would even put like UI path in some of the like because you can kind of configure the out-of-box RPA stuff. We don't compete very much in that bucket, but we have a solution. And the reason why we use that solution is because our enterprise companies who buy Pega for enterprise solutions may also want to do some of those lower use cases, and we will kind of put that as part of their license rights.

Got it. And I think you just mentioned you added RPA. You've also added process mining capabilities. Can you talk about customer feedback from those solutions so far? I know it's still pretty early, but what have you heard?

So the kind of the belief that we've had is that the Pega platform, which is kind of the foundation of everything that we do for our clients, any capability that we have must be native to the platform. It cannot be orthogonal. It can't be a stand-alone solution. It has to be a capability that's embedded in the platform because people that use Pega want to build enterprise applications, and they don't want to have to have separate things that they have to deploy, install and manage. They want the capabilities native to the platform. When we bought OpenSpan, which was a robotics tool, we embedded that in the platform. When we brought Everflow, which is our process mining engine, we embedded that in the platform. When we bought Voice AI, we have embedded that in the platform. When we bought Chordiant and had a customer decision hub in AI, we embedded that. So everything that we've had is really making the platform more robust so that you -- when you decide to buy another solution or leverage a solution. It's not a separate deployment. It's a capability that gets switched on and can be configured within that same platform.

Okay. And while we're on the topic of the platform, one thing you've been doing over the last couple of years is trying to kind of future-proof it in a way with Project FNX. Can you talk about what you've done so far there? What capabilities you've added? And then where are you going with it? What's to come?

Sure. So if -- maybe if you humor me for a second, I'm going to go back, say, 20 years and tell you that the Pega platform was about 4 or 5 different capabilities that were stand-alone capabilities that got kind of integrated together when we deployed. We went through an exercise where we really kind of stitched them all together. We made them into one unified platform. Now the negative to that is it's kind of monolithic, right, where it's one platform. But the reason why we did it is that at the time, the analysts and our clients were saying, "Well, do you have these great capabilities, but they really need to be more tightly integrated." We don't want to make mistakes by properly -- not properly integrating them. So we went through this journey of where we put all the capabilities together. We'll now fast forward to 2015, where the cloud emerges and you say, well, you don't want things to be together. You actually want microservices, you want everything to be stand-alone services that then could be updated every quite frankly every 10 minutes or every day or every week or whenever needed, a little bit of the analogous to like a fuse box in your house, right? Where you want zones, you can turn off, fix things, turn them back on, you don't have to shut the whole house down to be able to change an outlet. And that's kind of a microservices approach. So what we did was we originally have these as separate services. We really put them together as one powerful platform. And then over the last 5 to 7 years, we started to break them apart into stand-alone services. That was our Project FNX. What that did was that did something that was obvious and something that we kind of did not expressly tell the market that we were doing until recently. The thing that was obvious was it allowed a microservice as cloud-native architecture for Pega Cloud, where you could really drive the capability deployment at the microservices level, which was the main objective of Project FNX. The other thing that it did, it allowed us to take what we had done there and actually re-purpose that in a multi-tenant environment, which is what's called Launchpad. And we are not selling Launchpad right now. We've just announced it in July, but we've been working with system integrators and ISVs because we're allowing ISVs now in 2023 to build their applications on Launchpad, which means they can come up with a use case or with us design a use case, configure that run it in a multi-tenant environment as a service to all of their clients. An example might be say Boston Scientific as an example, of selling equipment to hospitals. And one of the subscription services they have is deal with the consumables and the service and the maintenance on the equipment, that might be a value-added service that they sell the hospitals, for example. The hospitals could log into an application, they can update there so they could get scheduled service, order consumables, et cetera, and that could be a multi-tenant application that Boston Scientific could sell as a subscription to every single hospital or doctor's office or research or therapy center or a lab that they actually have their equipment. So that's -- and we would get a revenue share in that model. We would have a sales model. So this Launchpad is almost Pega for the mass market. right? That's what it could be. So what FNX was, was both of those things. We just never -- we never talked about that when we did it because we didn't want to overpromise until we kind of knew how it was going to play out. But we've feel confident now that we're far enough along that we talked about that earlier this year.

No, that's interesting, and I think it will give you another selling mechanism into a pretty tough year that's coming up. And then I think on that, I want to switch and talk a little bit more about macro, given that that's been a topic in every fireside chat we've had today. Obviously, next year, you're going to be -- we have a lower budget coming up. Pega is going to be selling into that. Can you talk about kind of your place in IT budgets? How mission-critical is Pega, and how you're kind of navigating these customer conversations right now?

Sure. So there are -- in any time period where the economic landscape causes friction, which I think 2023, it would be reasonable to believe that there would be some of that. Clients have to make decisions. So they make decisions on which project, which one is more important and some of that relates to new projects. Some of that relates to getting rid of an old application and updating that application to something new. So there's a lot of different dimensions of how clients will think about that. There's areas where I think we're not really exposed much, right? We're not -- like there's not a lot of risk, right? And then there's areas where there is risk, right, where we just need to be thoughtful about our clients' propensity to buy. So example, an area where we think there's just really not a lot of risk or things like modernization activities that they have around Pega, around other applications where they're trying to get off of old legacy systems that may not be congruent with new security standards with new operating systems, very little risk there, right? There's the existing Pega kind of applications that clients are already using. I think there's very little risk there because our retention rate is approaching 100%. So it's not -- we're not simply a system that gets shut off. They're typically a system that lives forever within the organization and grows and the volume grows. And then there's applications, a third one is a bucket of part of digital transformation initiatives. I think those will have reasonably good momentum, but clients can't do everything in times where budget pressures. So I think some of that will be maybe a little bit more scrutinized heavily, but I still think there's a tremendous lot of opportunity. And then the last bucket is the net new things that are around generating more customer demand, driving customer spend. I suspect those will be the ones that are scrutinized the most. Unless they're replacing a system that may have been a system that needed to be mothballed, I would expect that customers would slow down on investing in new selling type tools, focus on the ones that are obvious savings and still move on their journey in digital transformation. So if you kind of blend that all together, we would not be insulated completely from a recession, but I think we should fare well because we tend to sit in the mission-critical modernization, digital transformation bucket, which I think will hold its own in terms of -- from a priority standpoint.

And in terms of your sales approach, given what you just said, how you kind of realigned your approach to maybe focusing on some of your existing customers versus new logos?

Yes. So we made an investment or a strategic decision that I think we've realized probably was not playing out the way we hoped. About 3 or 4 years ago, we decided to increase the amount of selling capacity we had, including go into some new markets, go into some new verticals, sell-through partners, really ramp up the non-primary quota carrier type sales capacity model with the hopes of 1 of 2 things. One, a lot new logo growth, and that our sales that would help our sales teams become more productive, our direct selling teams. I think what we realized was, although there was some value to helping the sales teams, much of the investment that we made was getting new logos, but not necessarily efficiently. And so we made a shift at the beginning of 2022 because we saw a tougher economic climate coming in kind of the beginning to the middle of 2022. And we made a decision to really shift our selling capacity to sell onto new logos, companies that knew Pega because shorter sales cycle, higher win rate, an obvious -- we already have salespeople in those organizations, talk to the clients. It just was an obvious. And our productivity is like 2x what the productivity was on selling to new logos. So what we did was we took some of the sales capacity that we had selling new logos, and we shifted that on to existing. And then we looked at the kind of the sales overhead structure that we have, the people that were supporting the different lines and have really started to rationalize that down because much of that was related to new logos, to selling new. And I just think in today's climate, I just -- I believe that selling a new logo is going to be materially harder than selling to an existing, especially if they're -- if they don't immediately need the solution that you have and you're trying to really sell on the value. I think that's going to be a highly inefficient model, at least in 2023. And so we're just -- I think we're more just being practical about where the opportunity is. And we have a plan to become more efficient in our selling and marketing as we exited our cloud transition. So that's consistent with that initiative as well.

Got it. And is this just -- is this reallocating more reps towards selling to your existing base? And are you also incentivizing them in a different way?

So the -- no, the commission plans are not noticeably different because they're based on net new ACV growth. So we're not paying them on renewals or doing anything new there. But we are -- but we -- the two things we're doing is, one is shifting selling capacity to existing logos and reducing the amount of non-primary quota carrier costs compared to primary quota carriers because we don't need as much selling overhead for an existing logo. We need it more for new logos. So it's kind of like -- it almost becomes a positive, like a double whammy in kind of a good way where you basically get more capacity on your existing logos with a smaller amount of sales tale.

Got it. And I just want to circle back for a minute and just talk about the guidance that you've given this year. I think it was in 2Q when you did lower your ACV guidance, a decent amount. Can you kind of talk about, just remind us, what were the drivers behind that? And can you talk about cloud uptake versus on-premise uptake? And kind of how do you see that evolving into next year?

Sure. So when we started the year, we kind of pinned that we would grow ACV by 20%. When we got halfway through the year, we had enough disruption in the first half of the year from the change in our go-to-market leadership and also a legal matter that we were working on that we just -- we were far enough behind on our annual goals that we just felt that it was responsible to recalibrate where we thought we were going to be for the year. So we took our ACV growth from 20% down to about 16%. And when we -- and that was really -- that impact was really the Q2 miss that we had, meaning we really didn't change our view of Q3 and Q4. Now Q3 came in pretty much where we thought it was going to be from the beginning of the year. So that was certainly validated that this may have just been a one-quarter disruption. But it did impact our growth enough such that we felt we had to recalibrate. And that -- so that's kind of what happened. The logic of -- in some years, if we were behind at a midyear point, we may not decide to re-guide. We might just say, well, who knows, right? We do larger deals, we might make it up in Q4. But given the economic environment, we felt like that would be riskier to achieve that in 2022 and '23. So hence, the change in guidance.

Okay. And I guess in regards to customer behavior, are you seeing more customers focused on moving to the cloud right now, expanding to the cloud? Or is it also are customers kind of staying on-prem kind of staying with what they know?

Yes. Sorry, I missed that question you asked. So Pega Cloud for the last 4 years or so as hovered around 50% of our net new bookings. So our net new bookings were up 50%, Pega Cloud about 50%, where clients managed it on their own cloud of choice. In 2022, we've now had 3 quarters in '22, where that mix has been about 70%. So Pega Cloud has went from 50% to 70%. That percentage does not include any opportunity we have to move existing clients to Pega Cloud. That is just net new growth. Now some of that could be volume growth with existing applications, but it's also net new use cases. So Pega Cloud is our primary go-to-market selling motion. Our sales teams make more money on Pega Cloud because the order of magnitude of the dollars are bigger for Pega Cloud. And we really see great momentum there. In terms of migrating clients on to Pega Cloud, we've really taken that as a much more kind of selective targeted approach. Some clients will never move. Some clients are just in environments where they'll never be in a public cloud, or they have an application that they are, for whatever reason, don't want to touch, right, because it works well and they don't want to mess with it. So you do have that scenario. But there's still a lot of our clients that have purchased Client Cloud in the years past, bought a new application on Pega Cloud, love Pega Cloud and therefore, our great candidate to actually move their other applications to Pega Cloud. But we haven't made a big push for our sales team to do that. And we've been kind of letting that happen when the client is ready and when we're talking to the client about buying something new that's Pega Cloud kind of introducing that. And the reason why that is, is that we don't want our sales team spending all their time trying to migrate clients because we want them to sell new. We want them to sell new workloads. We know the migration will come with time.

It makes sense. And just while we're on the topic of cloud, some of the questions we always get when we talk about cloud is what's the model underpinning it? And something we've noticed recently is there's more on monetization on a case basis rather than just your prior model. Can you talk a little bit about that? And do you see Pega moving towards that type of consumption approach going forward?

Yes. So the -- it's a great question. So one of the other presenters this morning talked about the importance of the movement between perpetual licensing and some type of subscription because in perpetual licensing, you really sold out all the users, and you just would end up over discounting to basically for the client to buy shelfware, right, to buy the product, say, well, you're giving me such a good deal. I'll just buy all the users now and I'll quite frankly, probably never use them, but you end up with such a tremendous discount. Whereas the SaaS model doesn't happen because you're kind of -- you're almost -- they're subscribing to what they're using. And you end up over time, assuming the same adoption curve, you end up getting more from that because the client doesn't have to buy it all upfront. They can buy it as they get value, and they can get the discounts as they actually scale up. So it's a win-win for the client and for the vendor. So using that example, when you sell users, when you sell a SaaS solution with users, and you're selling out all the users for an application, you have the exact same scenario as perpetual license. You have to sell it all out, you end up over discounting, you don't -- versus if you have a transaction-based licensing model, which is -- which we call a case, which is a unit of measure. When you have a transaction licensing model, the license is -- the customer is licensing for a certain amount of volume. And then as the volume goes up, they pay more when volume goes up. They don't pay for volume that they don't use. They have kind of a minimum commit. And as they grow, they buy more. So we're actually kind of leveraging 2 aspects of the value of SaaS. One is this kind of almost consumption-based curve that moves up, which -- and moving to a recurring versus a onetime. So that's kind of why our case model, we believe, is a much more valuable model. And it associates volume that the customer is using. So it's a very easy thing to explain to the customer. That's your volume, you should only buy your volume. Users are tough because not every user uses a system at the same level of frequency. And over time, it's hard to really get the right price when you have a user model.

It makes a lot of sense. And then is that making it, I guess, right now, given the macro environment when you're approaching customers saying, look, you're going to pay, your value is going to be aligned to what you use? Does that make it a lot easier for these customers to expand? Are you still seeing customers hold back a little bit just given more approvals needed and whatnot.

So we typically -- in the last 2 years, all of our contracts have a scalability clause, and we're modernizing the legacy contracts, where you buy a commit, if you want to use more, you just go ahead and use it. And then there's a true-up period that happens. So you almost get like a temporary free amount of time to use the additional usage. And then there's a true-up. The true-up is an election like I elect to take my minimum commit up or a true-up could be let's have a negotiation. Let's look at the next 3 years, and let's kind of like figure out the right economics for our usage as it scales up. So that's kind of the way that clients -- so clients have very easy kind of adoption or expansion. There's also a really big push to self-service in a lot of the use cases. So clients love the fact that we're saying, "Here's your volume. And by the way, if you have more volume, you have to pay us more because that volume is self-service volume, and you're saving time with your CSRs with human interaction." And believe it or not, self-service actually helps NPS score significantly. And so your clients are actually happier as opposed to getting on the phone and talking to a call center person. And I think the clients that have taken that approach really push things to self-service and said, solve it yourself. But if you need to call, here's a way to get in touch with someone. Consumers like that model better, and then you only pay based on the actual transaction volume. The second part of that is some models are defensive, when the economy is bad, transactions go up, for example, like collection type activities, right? Whereas other models when the economy is good, transactions go down, like loan originations maybe or something like that or maybe adding new cell phone, maybe that's maybe a bad when adding participants to a cell phone plan might change. So there are ways that you can calibrate with the client even around saying, you don't want to pay more when economic times are worse. So we have to kind of -- we think through different models around locking in commitment levels through longer periods of time to create certainty.

That's interesting. And I think we're running on time soon, but I wanted to ask one more question. and switch to profitability and talk about the Rule of 40. You talked about getting there with more of a balanced type of approach. Can you kind of give us a sense of what the time line is or when do you kind of expect cash flows to start to inflect upwards as you kind of come out of this business model transition?

Sure. So when we started the business model transition in 2017, I had originally said it's going to take 5 years. And when we get to the other side of this, we're going to be a Rule of 40 company on kind of year 6, like once you're done with the transition. The transition took more like 5.5 years, which means we're going to end sometime in the middle of next year. And there was one thing that I probably didn't clarify as well when I said that, which is the Rule of 40 would be the first 12 months after you finish the cloud transition. I think maybe there was a presumption that it was in the last year, no it's typically the first year after you're done with the transition. So right now, we're scheduled to kind of finish the transition in the middle to the end of '23. So I've been pegging 2024 as being our Rule of 40 year. How will I get to that Rule of 40. Originally, when I first started this, I thought I'd get there with a 15% growth in the 25% free cash flow. As we started to grow faster, I started to shift that, like, well, maybe we can grow 25% and have 15%. Ironically, we're back to the point where I think we're probably going to be a 15% grower, and we're going to target 25%. So that's kind of 2024, Rule of 40 with probably a mid-teens growth rate and somewhere in the 20-plus percent profitability.

I think that's a great way to sum it up. And I think we're just about out of time. So Ken, thank you so much for joining us today. Really appreciate it.

Thanks a lot.