Pegasystems Inc. (PEGA) Earnings Call Transcript & Summary

All right. Awesome. Well, thanks, everybody, for joining us this afternoon. Day 2 of Citi's Global TMT Conference. I'm Steve Enders, part of the software research team here. And very pleased to have both Alan and Ken with us today from Pega. So I want to thank you both for being here.

Thanks, Steve.

Yes. Good to see you.

Yes. Maybe just to start, I don't even know how long you've been public at this point, but maybe for those who might be a little bit newer to Pega, just -- what should they understand about your business and some of the key initiatives for Pega?

Well, Pega has been in the business of trying to help organizations improve their processes, bring intelligence, automation and now using AI to do that in all new ways. So we really feel like we have an opportunity to really help businesses get closer to their customers and to save money and be more responsive. And I think there's no time like the present.

All right. All that sounds good. I think there's been a big focus over the past couple of days around AI, around the depth of SaaS, as I think people have been putting it, and the impact of vibe coding in the market. How do you see that impacting SaaS in general? And how do you see it kind of impacting the future of Pega?

Well, I think that SaaS is not one thing. There are lots of different species of SaaS products that are out there. And I do think that the changes of AI are going to have a significant impact on some of them. In terms of how it's going to affect Pega, I think it's really all for the good. First of all, this Blueprint capability we've created, which is a way to have a customer interact with a very, very sophisticated AI engine, interact with our intellectual property in a language model structure, interact with the best practices drawn from the web to be able to redesign better than they would have imagined how their business should work is exactly what you would today call a vibe solution. It's not a programming solution. You basically are interacting on your own terms with the software and bang, out of it comes a design that I think would exceed your expectations. We're actually continuing to add vibe-ish features to it so that some of the good things from the vibe software movement like having somebody be able to describe what they want and then have the software go figure out how to do it is exactly what Pega is going to be able to do. But the thing we have over the other vibe approaches is Pega is the combination of this very rigorous AI layer, this Blueprint layer, that helps you rethink your business, coupled with an absolutely proven but state-of-the-art workflow and decisioning engine. And what it means is that we use the AI to create, to define, to refine workflows and those workflows that can be seen, can be touched, can be tuned, can be verified, can be trusted and are easy to navigate. It's really well organized. So that when you want to go back 6 months later, 6 days later, make changes, et cetera, that you know what you're changing, you know what the impact is going to be. In a complicated system that's just lots of generated code and lots of these vibe systems just vomit up code, if it's a small system, it doesn't really matter. You can probably get your head around it. But if it's anything meaningful, anything that we would typically do, there's just no way you want to be looking at dozens or hundreds of code modules and trying to figure out what they do and figure out which one of them you have to change. So I really think that the whole vibe in code mission and approaches are really aimed at a very different class of problems, and we'll probably do just fine for those problems. But I think we can draw on some vibe concepts and use them effectively where it will make sense for ours and where we would never intersect with those really cogeneration players anyway.

I think that makes sense. I think one of the questions that I think we tend to get around Pega sometimes is I think there's the view of like low code. And you get the question of if you have these cogeneration solutions, what does that mean for the adoption of low code from enterprise customers? Like why would they pick to use a platform like Pega if they could try to build it themselves more efficiently? I guess what's your kind of perspective on that?

Well, I know low code became a term used in the industry, and we got tagged with it as well, inevitably, just trying to explain. But I've never thought of us as a low-code platform. I've thought of us as a model-driven platform because when we were originally coming up with the idea for Pega, when I was inventing it, the stimulus for it was CAD/CAM, computer-aided design, computer-aided manufacturing, where people use technology to design cars, piece parts, bottles, whatever they want to do. And they use that to create a model of their objective. And from that model, they will then be able to actually even automate the manufacturing of what they do. So Pega really operates not on low code. You don't see any code in a Pega system ever. What Pega really operates on is a model that describes, hey, here's the work we do. Here are the workflows. Here are the personas. Here's the service levels we have. Here's the objectives. Here's what the customer is trying to do. And then from that model, our workflow and decisioning engines know how to optimize, do machine learning based on what they discover from the work that's being done and try to continuously improve. So I think that there are low-code players out there, but we're certainly not one of them.

Steve, I've talked to you in the past about how we -- how the word -- the phrase low code actually means very 2 different things, right? There is low-code platforms, which is platforms that allow you to build relatively modest workflow-type use cases without actually writing -- like dropping in and writing code. And then there's a concept of being scalable, which actually connects to low code, which is our model, and the way we can configure and evolve our model is low code-ish, right? So there's a low code, the concept of how you actually iterate and design, develop and improve and modernize and continue to keep an application healthy and new, and then there's a low-code platform. And I think that people put us in a bucket that I'm not sure they necessarily know the difference between those 2. And as Alan mentioned, we wouldn't consider ourselves an exchange for code. We would actually consider ourselves a model-driven platform that allows a low-code concept, meaning as you evolve, you're not writing code. You're actually configuring in the UI the changes that you want to make.

Okay. That makes sense. Let's talk about Blueprint because I think that's been, I think, a really interesting area that I think has been pretty -- I think definitely has separated you from others in the industry. But can we just talk about kind of where Blueprint is today and kind of where we are in terms of the customer adoption cycle and their use of Blueprint?

Sure. So Blueprint has completely changed our go-to-market model and is continuing to do so. Blueprint is a very sophisticated AI-powered engine for working with a business person or a group of business people, enabling them to collaborate, enabling them to take best practices from Pega, best practices from the Internet and their own intellectual property, mix them all together and from that, establish the model, the model that looks -- well, happily, the model looks exactly like the Pega model that you would have created by hand 3 years ago. So we've been able to leverage the very rich and, I think, well-respected engines that people use to do enormous amounts of automation and enormous amounts of customer service. And we've been able to now completely change the way that both people buy it and the way that people implement with it. And candidly, I think that will greatly simplify adoption of the technology and should be terrific for our business and our customers.

I guess as we think about what that means for the business model, anything that you can share on what it's doing for deal velocity, maybe what it's doing for new ACV, what it's doing for the top line?

I think there's a few aspects to this that come to mind. One, Alan mentioned it, it changes the starting point of how an account executive begins a sales campaign. They don't begin a sales campaign really trying to get the next meeting and the next meeting, and then you can bring a sales engineer and then maybe you can build a demo. And it's changing that all to, we're going to talk about that in the first meeting, right? We're going to really use Blueprint to get into an ideation session really, step 1. Step 2 is it changes the mix of the team that we have in sales because now you're not thinking about all these sequential or serial steps that actually happen around a sales campaign. You're thinking about a team that's really going from discussion, ideation right into build, right, right into that actually getting something that's working. And then you think about how does that change the partner ecosystem on the go-to-market side and how that might create really a kind of a pull from the market where they wouldn't have otherwise had an opportunity to do that. So I think there's a lot of different dimensions around how it changes the model. And what we've seen early on is that we've seen a real -- a lot of excitement with our clients to engage with Blueprint. I've got kind of story and -- quote after quote, story after story from our sales teams around how our clients are really embracing this concept of like, let's not move forward without doing a Blueprint, right? Let's, like, make that part of our software development life cycle, which is amazing. I think it also helps us get to new organizations and to new workflows in a way that we struggled with, quite frankly, in the past because of that upfront time. The last point I would make, which I think is probably the most interesting, is clients are trying to do legacy transformation. We're 10% to 20% of the way through that journey as an industry. 20% is probably very generous. 10% is probably more accurate. And our clients have tons of systems that need to be modernized, and they can only go after a small number at a time. And with Blueprint, we can give them the ability to evaluate, ideate, to maybe move the needle on more of them and faster. And to me, that's the most exciting is we can help our clients move faster on that journey.

Okay. That's great to hear. Maybe that's a good point to kind of then dig into just on what Blueprint can enable, like what you've done recently from a product perspective that can kind of better enable that legacy transformation and kind of really go capture some of those use cases out there.

Well, there's quite a bit. One of the nice sets of features that have come in, in the last 6 weeks has been the ability to upload many different types of documentation that an organization might have access to and use those to grind together and influence the Blueprint. So for example, an organization can upload a procedures manual or upload a user manual or upload a testing document or upload a set of laws and rules or upload the sort of data interfaces to their back-end systems. And what Blueprint will do is it's going to incorporate these as it does the design of the workflows. And so for example, it can actually create the bindings, the connections between what that system will be and the actual back-end customer system or back-end accounting system, which historically, that's exactly the sort of thing that was both arduous and error prone to do. And we've been able to use the power of generative AI, coupled with the structural power of Blueprint to really handle that automation. And it's not just that it's faster and cheaper, but it actually does it better.

That's good to hear. Maybe I'll ask it a little bit differently. Like if you think back to when you were coming into Citi, I think, almost 40 years ago, as customer #1 for Pega, how would you have done that differently based on where Pega is today with the capabilities that you have now?

Well, it's interesting because in some ways, the way we would have done it 40 years ago is the way that we were doing it 3 years ago. We had a team, and I really did this with Citi. So I'll tell you, pretty typical. We had a team who were sort of experts or known as "design thinkers". They are the ones who kind of look at a business problem, trying to figure out, hey, what's a whole better way to do this? And they used really sophisticated tools -- back in the '80s, we used real sophisticated tools like whiteboards and Post-it notes. And I hate to say that those are still very much the tools that are used today. People will sit in front of a whiteboard and a Post-it note. Maybe -- with a Post-it note. Maybe they'll have a Mural computer system to also type into and draw pictures. But it's remarkably primitive, remarkably sort of hand-cranked. With Blueprint, it's completely different. You put your insight, you put your objectives, you put your -- to use your term, vibe into it. And literally in 2 or 3 minutes, you are challenged with, what about this? Does this describe the type of work you want to do? And it's not like when you put in 100 words, you get 200 words back. The system goes out and it will give you the fleshed-out version of all the different aspects of the work that this particular application needs. So if it's a system to onboard customers, it will have information about the different things that happen during onboarding. It will tell you kind of what the stages and steps are. It will propose some of the standards that you might want to follow. It will explain who are the people, the personas who are going to be involved in the onboarding. All of these will come even without you having put anything in. And so the ideation that happens is that a whole another level of candidly, quality, but it still enables collaboration because you can put changes in, you can say, no, no, I want this to be different. And the engines will keep firing and keep taking your differences and your recommendations in, but reconciling them with what's there to create something that's better than the sum of the parts and allows multiple parties to even come in and collaborate at the same time.

If you think, Steve, I mean, what Alan mentioned 3 years ago, certainly in the '80s, like there's a lot of rich content that companies have, clients have, prospects have around documenting how things should be done. Process manuals -- there's actually even visuals like taking a picture, running a video to be -- and because of the power GenAI and Blueprint, you can ingest that information in. And that information can kind of really quickly tell you exactly what's happening or at least give you a framework of starting what it believes is happening, and then you have the ability to clean that up and tweak that and put your personal touches, as Alan mentioned, collaborate with other business owners to make sure, is this right? Are we doing -- and I think that, that -- just thinking about the value of that -- because most legacy transformation, you're coming from a system that is not easy to intelligently say, here's what it needs to look like in a new modern platform. And so getting things like visual screen videos, process manuals, documentation, even BPNN kind of documentation if it happens, getting information from how the application functions even is just -- is incredibly helpful to construct what it is that you need when you're modernizing versus the whiteboard and Post-it notes.

Yes. And for example, at PegaWorld, and this is on our PegaWorld website, Kerim Akgonul, our Head of Product, did an amazing demonstration in which he found an IBM mainframe 3270 screen. Those green screens, which I hate to say it, there are a lot that exist in the backs of -- back offices in many organizations. And it didn't even have documentation. So they attached a screen recording device to it. They had a woman go through for 15 minutes how she uses it and just talk about what she was doing and then fed that into Blueprint. And what came out was just mind-blowing in terms of taking the concepts, taking the ideas of this credit card processing system and instead of just like replicating them, actually enhancing them and making it accessible and easier to use and easier to understand. And the ability to use AI to rethink the current technical landscape, to even be able to take input from more than one application and combine them is exactly what the promise of this technology was and what got us so excited when we saw it a couple of years ago.

Yes. No, that's great to hear. I mean I think Blueprint has been pretty exciting. Where are we at maybe from utilizing Blueprint, taking that into creating a production application with Pega and utilizing that Blueprint on the Pega platform?

Yes. So the way it works is Blueprint operates -- it's available once again for free. It's on pega.com, and it enables the collaboration, et cetera, for any Pega customer prospect, anybody who wants to use it. If you decide you want to operationalize the Blueprint, you then need to export it and download it either to a Pega Cloud system or to your own on-prem system, if you're one of our on-prem customers. And at that point, it becomes able to be hooked into your real operational infrastructure. We had on the main stage at PegaWorld in June -- Vodafone stood up, and they talked about how they had done in a couple of months something that would have taken them a year before. And they just -- it's also on video, too. And they were waxing poetic about how great it was. The guy stood up and said, we have a new motto. No sprint without a Blueprint. And so they're using this as a standard way to ideate and think about lots of the technical work they're doing. Because let's face it, banks, insurance companies, health care organizations, governments, they run on workflows. And so being able to have an engine that can really facilitate and automate that, I think, is very broad applicability.

Maybe that's a good example to maybe go off of. Like for that Vodafone example you're talking about of them using Blueprint for that application, like if they were to do that in a more traditional method or in the past, how long would it have taken them to get that released? If they were using a kind of, I guess, more like code approach versus using Pega, just what would that look like from -- how would it be different?

So if I recall, I mean, they're a pretty sophisticated group and have all the right tools and great engineers. What I recall they described was that something that would have taken them a year was done in less than 2 months into production. And the thing about that is speed is great. Cost reduction is great. The quality is really what was exceptional here.

And what might get lost in that is the quality point is that lives with you forever. And so when you think about that application continuing to modernize or taking on -- when Pega actually releases new capabilities and you move to a new version, that becomes simpler, right, which is also an overhead that our clients have as well. So we're really thinking about like, let's get this done fast, best practice, quality and also the kind of the future proofing of the application. And that's where like variability -- variability for just sake of variability is not helpful. Variability for unique business value is different. And we want to really try to help our clients get the best practice approach to how to execute a workflow.

Okay. That makes sense. Maybe shifting gears a little bit, talk about the go-to-market side a little bit more. I think for one, it seems like there has been more of a focus on driving new logos, driving to find new customers, new opportunities. I guess what is -- what does Blueprint enable that allows you to maybe lean into that motion again? And then how do you kind of think about the opportunity with partners to also kind of augment that approach?

So I would tell you that Blueprint has massively simplified the ability to onboard sellers and get them to a point of competence and confidence. We used to historically have multi-month onboarding for sellers. We would run them through as much as 5 or 6 months of education, training and practice before we would put them into the field. And we knew that was arduous, but we wanted to make sure that they were really well equipped to do a good job. We're now in a position where after 2 weeks, we expect the seller to be able to go and have an interaction with the customer. And it's working, and it's working well. I think we're also -- now that we've created these what we call partner Blueprints, where for several of our really leading partners, we've created a branded version of Blueprint that has, for example, Cognizant or Ernst & Young memorialized right on the face of the Blueprint and allows those companies, those partners, to put their intellectual property into our language model database in a completely private way. We can't even see it. But if one of those employees works with one of their customers, if they would start selling and pitching their work based on their expertise using Blueprint and this Blueprint capability as a collaboration and ideation facility, then they'll be able to take full advantage of what Blueprint can do but, I think, leverage it with their own capabilities. And one of the important things that we need to try to do between now and the end of the year is begin to educate those partners so that they can feel comfortable and hopefully be really motivated to go and bring their own stories to customers and be able to hopefully win their own business outside of what we would have thought of as our traditional Pega practices. These would be legacy transformation projects, SAP replacement projects, other types of projects where there's a significant role for what Pega can do. But historically, to train somebody to be able to sell one of those things has been, frankly, probably just too hard to really contemplate a broad distribution. I think we have a chance to start getting new logos through that. And we've told our partners, historically, we were reticent about adopting more than a very narrow group of customers and target customers. We grew up on large sophisticated businesses. We've now told our partners that if it's one of their customers, we want them to bring Pega to that customer. And that obviously opens up lots of logos and also potentially even different sized organizations as well.

One additional thing to add on there is, in the past, when we went after new logos without Blueprint, we didn't just need to hire an account executive and then ramp them in that delay. We also had to hire all of the other positions to actually help that account exec on those new logos. And with Blueprint, as we mentioned earlier, the account executive is the one delivering the Blueprint. And so it does actually shrink the number of seller helpers that exist across that and actually helps us -- hiring and finding talent and assigning to the org, et cetera, are all things that take time. So minimizing the amount of touch points and the amount of people and then the speed of the account executive and productivity, that's a big factor, too.

Okay. That makes sense. I do want to talk a little bit about maybe how that translates to the top line again and what that means for ACV growth. I mean, I think you've had a few quarters now of kind of accelerating top line. Just how much of that is kind of driven by what's going on with Blueprint? How do you kind of think about the customer demand at this point for taking on these kind of solutions, just kind of given the uncertainty that's out there? And maybe we can start from there, and we'll dig in a bit.

So I would say it's hard. Because Blueprint is so embedded in our selling process, it's hard to break apart or parse out the pieces of like how many deals were impacted by Blueprint or not. But I would say Blueprint is everywhere. It's part of who we are. And I think it has helped us speed up -- get more pipeline, speed up the sales campaigns, et cetera. So that's one -- that's a fact. The interesting kind of dimension of how Blueprint might actually help us in the future is really around attacking the new markets, attacking new verticals, attacking new logos, et cetera. So I think the key in terms of that translation of like, what has Blueprint done so far? Well, it's everywhere. It's part of how we engage with our clients, and we have tremendous success in terms of what we've seen for the first 6 months. The last point I'd make on the market. The market went from really humming to March, some uncertainty to Liberation Day to -- April and May were a little questionable. So the quarter finished pretty strong in Q2. And I would say if you look at where we are now, I think the markets held up really well. I mean the consumer, consumer credit, interest rates, like even inflation, I think that maybe to many of our surprises, it's actually held up through the year. And I think we're seeing some good activity. The last point on that, legacy transformation used to be a here and there discussion. And now it's everywhere. That's all clients talk about, cloud, AI, security and transformation. That's like -- those are the themes.

I guess maybe how are the use cases that you're maybe seeing today different than maybe how it was a couple of years ago, maybe pre-Blueprint?

Alan, do you want to give some thoughts on...

Yes. I think we're seeing a couple of interesting differences. One, we're seeing existing customers who have, in some cases, created almost a set of sandboxes, looking to do this to go wipe out some of the legacy applications they have that they really wish they didn't. Almost every large company has many more applications in various levels of decay than they would want. So we have customers who are basically going and literally knocking off hundreds of applications and moving them through Blueprint to Pega Cloud in some cases, in a couple of weeks. And that both -- well, gets rid of the possible risky dangerous applications. But they're also getting more value out of some of them, and they're also able to make that happen. So I would describe those as sort of just an ongoing stream of quick wins that can be pointed to. But we're seeing organizations using Blueprint to take -- one of the big meetings I was in, an organization had issued an RFP that we have responded to and won and implemented. And the salesperson came in and in the course of the meeting when I was there, he actually fed that 3-year-old RFP into Blueprint. And they sat for 5, 10 minutes while it ate it and chopped it up. And it was big. And then they looked at it and the customer said, my God, I wish we had that. And when that happens, all of a sudden, people get a completely different view. I mean being able to move people from a RFP way of thinking through paper and the old traditional procurement processes to actually -- I've got organizations that are using Blueprint to define those RFP requirements. I'm perfectly happy -- by the way, if somebody wants to use Blueprint and send it to my competitors as well as me, that's fine. I think it's probably going to turn out for me more -- to be good more often than not. But it's a really good way to design and define how you want your business to operate. I think it's changing everything from the very simple and quick to the strategic and things that would have gone as multiyear RFP. So it's almost hard for me to calibrate how large this has the potential of being. But I think it's really a great application of AI.

That makes sense. I only have a couple of minutes left. I do want to ask on the model again. Just -- I think you grew 14% this past quarter in ACV. I think that's been kind of above what you were targeting for the year. Just what should we be kind of keeping into mind for the back part of the year to kind of bridge that gap? Or is there opportunity for us to kind of see growth above that level?

Because we don't have a model that is like a same-store sales model where it's that consistent quarter-to-quarter, year-to-year, there are variabilities in the year. So 2 variabilities I would point to in the back half of the year. Last year in Q3 was probably our strongest Q3 maybe ever. It was a very strong -- a very difficult compare in Q3, and we actually have an easier compare in Q4. So I would just say the linearity of our business enterprise is not straight line. So just keep that in mind. I would also say that because of where we are at the halfway point -- and I'm talking in constant currency, everything I say is in constant currency. Where I look at where we are at the midway point of the year, certainly, it sets us up to meet or exceed the targets that we have for the year, both in ACV and in free cash flow, which are our 2 big measures, as you know, Steve. So I would say just really the dynamic in the back half of the year is just remember, Q3, tough compare, Q4, a little bit easier compare, really well positioned at the midway point.

And then on the cash flow side, I know there's the new tax bill that came out in the past couple of months. How should we think about the impact that maybe that has on the model for this year and kind of next year?

Yes. We're going to get some benefit of increased cash flow over what we originally modeled for the year because of the -- specifically the Section 174, which allows -- which minimizes the requirement to capitalize R&D, and which then means we have a more -- a higher in-year deductibility. That will help us kind of probably in the tune of $20-or-so million for the year.

Okay. All right. I think we're at time here. But Alan, Ken, I want to thank you so much again for being here. And I want to thank everybody in the room for being here as well. So thanks again.

Thanks, Steve.

Thank you. Thanks, Steve.