PegaWorld iNspire 2024: Microjourneys: Pega Best Practice to Transition from Customer Journey to Agile Delivery

Two days worth of conference and who knows how many years of experience among you? How often have you seen the terms digital transformation and customer journey together? Lots, right? Like chocolate and peanut butter. Here's a better question. How often have you seen one of those digital transformations actually implement one of those customer journeys? Or have you more often seen those transformations fizzle long before the journeys they're supposed to implement ever become real? Yeah, well, as you know, at Pega, digital transformation is what we do. And about five years ago, we decided that customer journeys really needed to be core to the way that we implement all of these digital transformations.

But we discovered that focusing simply on customer journeys actually caused trouble for our clients. Not that there's a problem with customer journeys, it's just they have three significant challenges that kept our clients from succeeding with them. So we figured out what those challenges were and we found the solution. And that's what I want to talk to you about today. So let me take you on a journey of my own, from customer journeys to agile delivery with micro journeys. And our path today is we're going to start by making sure everybody's on the same page about what a micro journey is. We're going to talk about how they can help you, going to talk about how you identify them. And most importantly, I'm going to give you some concrete ideas for using micro journeys as you start making your customer journeys real. And before I identify a definition for micro journey, I need to identify a customer journey, which is surprisingly difficult to do.

I was working in Pega's Global Methodology team when micro journeys were born, and one of the biggest challenges we had was agreeing on what a customer journey was. So we settled on Forrester's definition. It's a series of interactions between a customer and an organization that occur as a customer pursues a goal, which sounds pretty good. So why do we need anything else? Well, as I said, it turns out that customer journeys have three big challenges. First, they can be complex. That is, there can be a lot going on in them. Second, they can be complicated. It can take a great deal to implement them.

And you put those two together and you get the biggest challenge of all. It can take a long time to implement them. This is not good. And this is what our clients were running into. So Pega came up with a tool called Micro Journeys. It's the way that we break up end to end customer journeys in a way that allows you to deliver value quickly. They're part of a customer journey, a business transaction that results in an intermediate or final outcome. Now emphasis here on business transaction. Micro journeys are not functional decomposition.

Functional decomposition still has its place. But when we talk about micro journeys We're talking about business process, so bear that in mind as we talk about the rest of this. Now, micro journeys, as many of you know, are part of the three pillars of any Pega application. The first being micro journeys, particularly the outcome of those business transactions and the cases and strategies that implement them. There's the first pillar. Second is the personas who interact with the organization in order to provide customers with value and the channels over which they interact with the organization. The third being the data that's used, either displayed or persisted, and the interfaces that we use to either get that data or store it. And a reminder you can document for your case types. You can document personas, channels, and data in App Studio.

My advice is to do so. It's surprisingly powerful. As you work along, and your devs and your testers sometimes wander a bit from the business value they're providing to the immediate technical challenges they need to meet, it's perfectly understandable. But if you take a moment and put things like personas and channels and data into App Studio, you'll find that your teams stay much more connected to the real reason that we're all there, which is solving business problems. Now, a micro journey typically delivers one outcome. It is possible to deliver more. My advice is not to do it because when you communicate about micro journeys, you communicate about the value that they provide. And if you have a micro journey with multiple outcomes, then it's providing multiple kinds of value and it gets very difficult to communicate about it. So please for the most part, micro journeys have one outcome.

And that outcome is delivered in 60 to 90 days. Now some of you are working in organizations where you think 60 to 90 days. That's an awfully long time. We deliver in 30 to 60. And God love all of you who are in that position. Some of you are not. Some of you are in organizations that has never delivered anything in 90 days. In which case, welcome to the family. That's what micro journeys are about.

It's about delivering value quickly. If you if you're talking about micro journeys and people say, well, yeah, let's talk about micro journeys that we can deliver in 180 days. Maybe you have to for your first few. I have been in organizations where we did exactly that because the organization thought if you can deliver anything in six months, we love you and that's great. Then they get used to six months and you push them to four and to three, and suddenly they're right where they need to be. But it takes a while. Generally, though, think about your micro journeys delivering 60 to 90 calendar days. Calendar days. Don't let anyone fool you into thinking, oh, he really meant work days.

No I didn't. Down to the, you know, the Global Methodology group. I even checked with them on that. They said, no, it's calendar days, so you can use that as a lever. Don't let anyone tell you otherwise. Now, what do you get at the end of those 60 to 90 calendar days? You don't necessarily get something that is ready for release to a customer. It is fully coded, fully tested, fully production ready. It just might not be big enough.

Maybe what you need to do can't be done in 60 to 90 days. That's why you have micro journeys so you can break it up. Releases routinely wait until a number of micro journeys are ready, until you deliver it to a client or a customer, or even a large testing body. But every micro journey that you build when you say it's done, it's done, done, you don't say, yeah, we did our micro journey in 60 to 90 days, but we're not done testing it yet. No, it doesn't work that way. If you have to scope your micro journeys down more to make sure that they're ready in 60 to 90 days, then go ahead and do that. Now, micro journeys can also be delivered to multiple personas. This is actually fairly common. Think of anything in your, um, in your, uh, like, customer support, your call center that almost always has two personas.

You got a customer and you have a customer service rep. That's fine. Just don't let it get too big. Maybe in the course of that micro journey, you've actually got a manager approval in there too. That's okay. But I have seen people draw up micro journeys that have like six personas. Don't do that again. You're trying to keep things small enough to deliver in 60 to 90 days. And we mustn't laugh at the six persona people because they meant well.

It's just that's how they think. And this is one of the big challenges with micro journeys. You will have to get your organizations to think smaller, because how many of our users are used to being told, hi, we're IT, we're here to help and we won't be back for two years. So whatever you need, you better ask for it right now. So they're used to having to ask for huge things. With micro journeys. They don't have to anymore. They can ask for small things and that's what we try to get them to do. And just as we try to limit the number of personas, theoretically you could have multiple channels.

My advice is have one build whatever it is you need to build on the channel that has the most value. And then once you see all the value there, go ahead and send it to. Let's say that most value is the CSR desktop. Then in subsequent releases, go ahead and send it to a mobile app, to a tablet app, to social media. Pega is really good at that center out. It's for it's for real. But don't try to do everything at once, because for one thing, you're 60 to 90 days is going to go up in smoke and you don't want to do that. You can even have multiple data sources when you're talking about micro journeys, for example. You've got, I don't know, a book inventory system.

Back in the day when people actually sold books, they used to do that in a store and you could hold them and open them. It was crazy, but you could build something that, you know, in 60 to 90 days. I can give you basic book information inside the Pega app because we're going to pilot it at, you know, at one little warehouse. Great. And then in a subsequent release, we go out to say an enterprise system of record or a third party service that gives us book information. So that's another micro journey in another release. So when you can have your micro journeys, one outcome, very few personas, one channel. Don't do anything fancy with the data sources if you don't have to. Because you've got many micro journeys in the future and it's easier to manage them.

We'll talk about planning and controlling the work you do with Micro Journeys in just a moment, but it's easier to control when those micro journeys are small. All right, so that's what a micro journey is. How can they help you? In other words, why are you here? Why does any of this matter for good reasons. First, it speeds your implementation. If your clients are used to seeing delivery every nine months, they're going to be seeing delivery every 2 to 3. That helps. A of course, you're learning every time you release something and they get used to seeing new things.

You keep the momentum going. You keep the excitement going. You keep the funding going up. Did I say that? Yeah, I did, because it helps. So not only do you increase your speed, it clarifies your scope. Remember when you think micro journeys, what have I been talking about so far? It's got one outcome. It's got very few personas.

It's got one channel that keeps things very controlled and it's very visible. If you're organizing things by micro journeys and you're reporting on your progress by micro journeys, everybody knows what's in that micro journey. So as soon as somebody tries to slip a second outcome in, as people tend to do, or somebody says, yeah, this is good, let's do two channels instead of one, it's very apparent. And you can either say, yeah, we're going to do that, or you can say, no, that comes later, but it's very visible. You also reduce risk, particularly the risk of building the wrong thing, which is the worst use of it. Dollars ever. And you know that you're building the right thing. Because guess what happens when you say to the business this month, this Sprint, we're going to be working on this outcome for these personas over that channel. The business is going to say, great, these are the four people that you need.

And those four people are going to say, this is what the business needs. And you say, great. Oh, and how about we do this thing too? They'll say, that sounds wonderful, but it's not what we need, not what we need to do this. Don't spend our money that way. So they're they're watching you because micro journeys are so focused. And finally, it increases the business value of what you're delivering. Because if you plan the way we propose that you plan with micro journeys, you're going to be lined up not just with the business immediate tactical need, but you're going to be lined up with your organization's strategic vision as well. So they're going to see value being delivered in the order they expect it in the order they're looking at to explain to their people Why?

Money is being spent well. Great. We know what micro journeys are. We know they're a good thing. How do we find them? Primarily in two ways. And the best way for me to show you is to give you an example. Here's our friend Amy. Amy's thinking about joining the CSC Automotive Club because she wants to be able to repair her car she ever needs to cool.

Triple C has done work with its customer journey and decided that it's got fundamentally three stages applying for membership, obtaining roadside assistance, and renewing membership. There are other activities underneath it, but those are the big three. And as a BA, I'm talking to the business. I'm talking with my LSA. You do always have your BA and your LSA like arm in arm when they're talking to the business, I hope. Right. Those two people That's like I was a bass player in a former life. That's bass player and drummer relationship. They don't separate.

You have those two people together all the time and life will be much better, trust me. So the business looked at it, talked to the LSA and said, you know, we think we can do roadside assistance, at least the happy path in 60 to 90 days. It's relatively straightforward. It happens to be for SEC. Great. There will almost surely be stages in your customer journey that can be done in 60 to 90 days, in which case grab those things as micro journeys. It's perfect. But what if you can't? What if, say, roadside assistance was too difficult to do in 60 to 90 days?

Now what do you do? One really good thing to do is to look at the dimensions that define your customer journey to begin with. The outcomes, the personas, the channels, the data, and start breaking that journey down in combinations of those dimensions so that you end up with things that are small enough to implement in 60 to 90 days. So this is our journey still, Amy. She still wants to join the club because she still wants to make sure she can repair her car. We have our three outcomes. Those three stages, our personas. We've got a repair technician because that's who's really doing the work. We've got a CSR because somebody is coordinating this.

We started out with a customer until an SVP in the room said, you know, we'd like to have premier customers so we can do upsell. We don't know what that means yet, but please put it on the list. So we did. Turned out later it was very helpful. Channels. All right. So we got a CSR which means we have a call center desktop. It said, you know, we need to think about mobile devices. We can't be the only auto club that doesn't have an app.

So app makes the channel list. And we decided we were going to give the repair people a tablet app so they could immediately record that the work was done and all of that. And then we've got three data sources. We've got triplex system of record, we've got a service provider database and a repair estimation service that's going to make itself known in a little bit. So those are all the dimensions. And we start breaking things down. For example, if we take the happy path to obtain roadside assistance and all the personas and the call center desktop and those first two data sources, that comes out to a micro journey. In fact, it's the same micro journey we identified just before. So you can find the same the same micro journeys two ways sometimes.

All right. So that's good. What else do we have? What if we want a potential customer to apply for membership with the mobile app? Because wouldn't that be a great use of a mobile app? So that's the happy path through apply for membership. It's the standard customer because there's nothing unique about this as far as personas go. It's the mobile app channel, duh. And it's hitting Triple C's system of record.

Cool. Another combination. Another micro journey. A third is, hey, somebody figured out how we can have premium customers and get upsell. We'll allow them to use that same mobile app, but they and only they can compare the cost of repair options. So we're in the obtained roadside assistance stage. But now this is one of those subtasks. It's only premier customers. We don't need a CSR to help.

And it's certainly not something for the standard customer. They're going to be using the same mobile app And they need all of those data sources. So it's another micro journey. It's another combination. And you can use a list like this to just keep working through the thing that's really going to drive it is outcomes, because that's what that's how the business thinks and that's what we're delivering. That's where the value is. But as you start to think about that, that's when you can use a list like this to say, well, yeah, we can apply for membership through the CSR first, and someday we'll be able to do it through a mobile app. Keep these dimensions in mind and you'll be able to work through all those combinations. Okay, that's the basics.

Micro journeys are business transactions that are part of a customer journey. They can help you go faster. They can help you stay focused. They can help you deliver value more quickly. You can identify them either by finding a stage that's small enough that you can do in 60 to 90 1690 calendar days. Or you can look through combinations of the dimensions that define the customer journey, end to end, and build your micro journeys that way. Now this is what I promised you. This is the this is the concrete stuff. This is how micro journeys can help you plan, organize and communicate.

And what I'm about to tell you now is the reason I think that micro journeys are the most powerful concept in Pega express our method for delivering value. I don't think anything comes close because what else in Pega express does all of this? Planning with Micro Journeys starts with identifying micro journeys. That is the hard part. The rest of this is relatively easy. Identifying micro Journeys is no walk in the park for a big organization and a, you know, a big business need. But. Since everything's in business speak. And since you're doing it with the business in the room with your IT.

In the room with your LSA, with your LBA, ideally with your experience designer. Working through this provides a phenomenal foundation for all the rest of your work. So you get those journeys, micro journeys rather identified. Now two things need to happen right after that, or even as it's happening. First, the business needs to determine relative business value of all of those. Now, you know the business is not going to come up with anything that has no value. They're already filtering that, which is fine, but not everything has the same business value. So the business is the one that determines that it does not. We also need a course implementation estimate for one thing, because that helps the business figure out priority, right?

You know how it goes. Hey, that would be great. It's going to take nine months. Yeah, that would be okay. Or you can give me that in two weeks. Do it. That's first you know. So get that course implementation estimate. And it's really course because you've got a title for this micro journey.

Maybe you've got two sentences about it. So nobody is going to be able to do an estimate that you can actually hang your hat on, but you need something. My advice? Have your delivery resources estimate in sprints. No more, um, you know, no more accuracy than that and even that. You're making a lot of assumptions, but doing it in sprints will help you when you plan. We'll get there. So now you've got micro journeys with relative business value and an idea of how much it's going to cost to implement them. Use that to produce a prioritized list, and I'll show you a method in a second that will help.

Once you have a prioritized list, you take those micro journeys and create a micro journey roadmap. When are we going to do these? In what order? When do we need resources? And you can begin a micro journey based story map. And if you guys have not used story maps before, oh, you're missing out. Powerful powerful communication tool. Very easy to do in concept at least. So I'll get to that in a second too.

Now to prioritize your micro journeys. Easiest way to do it is to work with a matrix like this, where you've got one axis that is business value and the other axes. Ease of implementation. Upper right hand corner is your first priority. That's the stuff that's relatively easy to do with relatively high business value. So valuable. Easy to do. Why wouldn't you do those first? Second, you go to the upper left, which is harder to do, but still high business value.

So you get the stuff on the upper right. Then under that in the priority list is the stuff on the upper left. Then you get the stuff on the lower right. This is the stuff that has lower business value. Again, nothing on this list has no business value, but it has lower value. Yet it's easy to implement. And this is still on the list because this is great for when teams have a little extra time and they they don't have enough time to grab on to something big, but they still want to keep delivering value. So these little things here in number three can be very handy. Number four, the stuff with low value that's hard to build never gets built.

I mean why would you? But one, two and three. One of the nice things about breaking it up this way, you know, when you're prioritizing a list, you're force ranking. And that's easy to do when you've got seven micro journeys. What if you have 87? You don't want to sit there without a clue. So all you have to do when you force rank is you just work through one quadrant at a time, and it really turns out to be much easier. My advice if you don't have your own way of prioritizing a bunch of things. My advice is to do it this way.

Now, once you've got that prioritized list, remember you've got your micro journeys in order top to bottom and an idea of how many sprints it's going to take to do each one. Now you find out when do you want to do releases? Specifically, how many sprints do you have until you want to put the first release out? Then you start at the top and you count down micro journeys until adding one more micro journey exceeds your capacity for that release. Now you know how big the first release is, and you can do the same for the second and the third and so on. Now this example is ridiculously simple. It just so happens that we wanted three sprints for the first release, and two for the second, and two for the third. And lo and behold, these three micro journeys in order were exactly that many sprints. How remarkable.

Obviously you can have. In fact, you will have releases with multiple micro journeys and that's just fine. What you don't want is a micro journey that takes multiple releases to implement, because it's really hard to talk about it. I mean, if you're talking about a micro journey in the first of its two releases, all you can say every week is not done yet. You say that 8 or 9 times and I don't want to be you. So just if you find a micro journey that can't fit in a release, break it up. Just please do. It'll be okay. Now story maps.

Story maps are a very easy concept. It's just a matrix with your micro journeys across the top left to right in priority order and your sprints on the left edge and all those cells. That's where you put your user stories as you identify them, and you have a gross idea of where you think you're going to be implementing them. Now this all changes over time. That micro journey roadmap changes over time. But you've got to start somewhere. And this, as I mentioned, is a profoundly powerful communication tool with the business because the business always wants to know, when are we going to talk about this, premium customer comparing repair cost estimates. Because I've got to get Jenny involved. She's the one who thought of this, but she's busy with something like this.

You can say, well, it looks right now like we're going to start talking about it in Sprint, or we're going to start building it in Sprint four, which means we'll be talking about it in Sprint three, which means, oh, probably, we probably need her starting the week of April 15th. Great. Now the business knows. And if somebody is curious about when am I going to see that first mobile app? I'm so excited. They just look on this. You don't have to look for them. They can see this. They can say, you know, all those stories look like they're all in that.

Sprint's three and four. So when's the end of sprint four again? Oh, that's when I'm going to see that. So this is very powerful. And that red line just by the way that's dependencies. You have to be aware of that so that you're doing the right thing at the right time. And that's all a story map is. Again, if you're not using it, my advice is to use it now. There are whole books on story maps.

You can get very, very sophisticated in what you do with a story map. Personally, I think the law of diminishing returns comes in if you get just what's here. Just the concepts that I laid out for my money, you have 80% of the value of story maps. And I mean, it took me, what, five minutes to tell you about it. Please think about using it saved my life more than once. All right, so that's how we plan with micro journeys. Now, once we've got that nice micro journey roadmap, guess what order we elaborate stuff in? Duh. You elaborate it in that order, and you build it in that order.

You're just elaborating a little sooner, but you don't have to get into arm wrestling contests anymore. And people can look deep into the micro journey roadmap. Say you're building a Pega thing, and you have your IT partners who have to build you an interface into a system of record. I'm sure that's never happened to anyone. There's never been any schedule problems with trying to get that done on time, you know? So yeah, it's a joke. You can laugh. I come from a dev, you know, a dev background. I didn't join the the dark side until about 10 or 15 years ago.

So I lived that build interface stuff too. But that's really helpful to an IT organization. If they can look at that roadmap and have it have a decent idea of when you're going to need that interface. So you plan both your elaboration, your implementation with those micro journeys. It's also a great way to structure out of Sprint testing. Okay, so just clarification in Sprint testing means meeting acceptance criteria in user stories, period. That's what it means. But there's lots of other testing. There's performance.

There's security intrusion. There's load, there's accessibility, all of that stuff. My advice is to organize that by the dimensions of the micro journey outcomes, personas, channels. Because if you're doing performance testing by outcomes and personas and channels, the testing you do is going to do a much better job of reflecting real life than if you do all of your testing by I'm going to test that screen, and then I'm going to test this one, and then I'm going to test this one. Now sometimes you need to there are screens that you know are going to be a performance problem, so you start testing them right away. Great. But if you also get folks to think about testing like user acceptance testing, how do I organize user acceptance testing? Users don't know they're not testers, but if they gave you a list of micro journeys because it came from them, you just look back at them and say those micro journeys, the outcomes that you want and the personas and channels that are involved, those are your scenarios. They're like, cool, I have a box.

I can put this stuff in and you can do the same thing with change management. When you talk about training an application, you don't need to wait until the application is nearly built, until you can start building training. You can start doing it as soon as the first micro journey is nearly built. And when you develop training, you can develop training. Not by this screen and that screen and that screen. You can develop training. By today we're all going to be customer service reps. And we're going to learn how to do these five things, these five outcomes over that one channel. That's how you organize it, which means that the people who are getting the training have conceptual boxes to put it in.

Same with communicating. If you're putting out a news release, wouldn't it be nice to say these are the people who are going to get the value and this is the value they're going to get. So even though even those folks, the folks who aren't touching a bit of code can focus on outcomes, personas and channels, which means they're focusing on micro journeys. Now, you can also, and perhaps most importantly, communicate with micro journeys. And by communicate I mean weekly status reports and release notes. The driest written content in it. Describe them in terms of outcomes, personas, and business value. Because you're expressing all of that in terms that everybody already understands. For example, instead of in your weekly status report saying we are implementing a service based interface to the repair system of record, sorry.

Instead of saying that, you can say in a weekly status report, we're providing customers with the ability to view the repair history for all of their vehicles. You're going to wake everybody up as soon as they start reading that, because it isn't going to look like any weekly status report they've ever seen. And you can do the same thing with release notes. Instead of that boring stuff on the left that nobody reads, you may write release notes that people actually want to read because they'll say in this release, CSRs can improve service through visibility into a customer's relationship with the company across business units and marketing can make better decisions through the reduction of duplicate customer creation. This is exactly you're communicating the same stuff, but you're doing it in a way that makes sense to everybody. So where have we been? In summary, customer journeys can be complex, complicated, and difficult to deliver quickly. Micro journeys are your salvation. They break those journeys into value delivering pieces, speed, delivery, clarify scope, reduce risk, increase business value and let you plan, organize and communicate more effectively.

Which is why I say that micro journeys are the most powerful concept in Pega express. So you can learn more about them by going out to Pega Academy got one example there, but dig a little bit and you'll find more. There's some stuff out in Pega community. You can also contact me. My Pega address is on the next slide if you just want to chat about micro journeys. If you're trying them and you're having trouble or you're trying something, you found something that works really well and you want to share it. Great. I'm here, you know, and that's very cool. But you do actually have me.

Me right here. So we got two mikes. If you have a question, come on up. Okay. Well. Oh. My, my my guy's going to be really mad. Matthew's not going to let me forget it because we're recording this. So if you don't walk up to a mic, then the rest of the world will not hear you.

See, all you have to do is invoke Matthew and stuff happens. So, um. How do you, um, I guess, envision or suggest that we work in a highly regulated environment? Uh, from a federal banking standpoint, and I'm sure others in the room might as well. But we're delivering a B2B application. So I've got users who work for large financial institutions, and they've got API's that build off of my data and all this kind of stuff. How do you build a customer communication into this process in such a way that the customer is told far enough in advance to what's happening and when it's happening, so that they can make adjustments in their own, uh, processes or procedures systems, you know, whatever. And obviously there's no perfect cadence to doing that. But, you know, we actually are on a three week release cycle and we maintain that, you know, year over year.

Our our challenge more and more is becoming at what point do we know enough about what we're going to deliver to be able to give you not three weeks notice, right? Certainly not one day notice, but three months notice. That type of thing. So. Mhm. Well I, I empathize with the whole regulated thing. Um I'm not allowed to say where I'm assigned right now, but it has to do with uh revenue collection. A lot of revenue collection. Nobody usually people laugh about that on April 14th or 15th, depending on the year.

Okay. You got it now. Yeah. So that's that's our problem too. How how do you do this in a regulated environment and communicate I think, The rate, the regulated side of things, I think actually argues for micro journeys because as you're walking through customer journeys, all those regulation points show up, whether it's, you know, congressional oversight or, you know, legislative mandate. As you as you walk through those customer journeys, those are going to come up right away. So they're going to be baked into the micro journeys. Now, as far as communication goes, I think, you know, unless unless there's something I haven't considered yet, I think that what I've talked about here is pretty much what you need, because let's say you've got a customer that has, you know, you're delivering a specific outcome. I don't know, I don't even I don't even know what it would be.

I would guess, but I'd guess wrong. But they need this. They need this piece of paper that's going to be that's going to be mailed to them. Yeah. But we know that that outcome is in this micro journey. And right now it's scheduled here. So, you know, I understand that you don't want to tell people when you have no idea and you don't want to wait until you know exactly. But that's going to happen with your micro journey roadmap, no matter what. It starts out as an educated guess and firms up.

So maybe there's something that I mean, experiment, but you might say, you know, we're only going to guess, well, two releases out and let's say, well, you're releasing every every three weeks. So maybe, maybe, you know, five releases out. So 15, 15 weeks and you see how well that works for you and for them because, you know, if they're your customers. We're talking about customer journeys. What's really important is them. All the stuff that any of us do inside our enterprises is for them. You know, what we do with the IRS is for taxpayers and preparers and oversight. You know, we're not doing it for for ourselves. So I think.

It's, you know, experimentation is important. And understanding that running an experiment that shows that wasn't a good idea is still a successful experiment, because it showed you something that didn't work. But I would personally, I would rather experiment and fail well, rather experiment and find out something that didn't work than sit around and worry and not do anything. Because I don't want to fail. And I don't know if that answer helps at all, but maybe if it didn't, it will help someone else. But does that make sense? Yeah. I mean. Thank you.

I guess to your point, because we are on a three week cycle. What what we've done, it seems to be working better is, for instance, let's say we're going to change what's allowed in a particular data field. And you, as my customer, are going to need to change your API to accommodate for that. In times past, we would wait to tell you what the code number is and what it means and so forth. What we've tried to do of late is we've tried to communicate to our customers. We're going to be introducing a new code in field 67. It will have something to do with this type of delinquency. We haven't picked the codes yet, but you need to begin thinking about what you'll need to do on your side to accept one or more new codes in this field within the next whatever period of time, and that seems to have helped in some respects. But in others there is this constant idea of, well, when can you tell me the code?

Because I need to start this and that and so forth. So you're right, the experimentation part of that and the give and take is, is part of that process for sure. Yeah. I mean, generally if, if I had if I was your customer, I would send you a nice basket of fruit every Christmas for doing that. Maybe experiment number two is right now you're telling them we're going to change something in field 67. Maybe an experiment is and this is our guess about when we're going to tell you the value, you know. And maybe that works. Maybe it doesn't. But it seems like it might address a problem.

I got time for one more question. Okay. Oh, there it is. I'll have a question. Um, after your presentation, it's clear to me how to use micro journeys in context of a process where you can break down a process into smaller pieces and use micro journeys to speed things up and make it easier. But my customer is embarking on a transformation to use CDH decisioning instead of their own old campaign based approach. So would in that case. In case of Pega CDH implementation for marketing decisioning with a concept of micro journey help in any way? Sure.

It sure does. That's why when when I had that little slide about what are the three pillars and under micro journeys I had case types and strategies because I initially just had case types. And then my CDH buddy said no, you got to put strategies in there because that's the that's the analog, but it's still micro journeys. You still have an outcome that you're dealing with. So you still break. You know, the idea of a journey is different with CDH, you know, so the outcomes are different, but it's still what are the outcomes? What outcomes can we provide in 60 to 90 days? It still works. We did it.

Where did we do it? I just forgot where we did it. But we just did like six months ago. I mean, we've been doing it a lot. But the project I was on did it. That's this is actually where I learned that I had to think about about strategies too. But yeah, it works for CDH definitely does. Anyway, thank you all. That's that's my Pega email address.

And I'm pretty sure these slides are going to be available. So if you don't feel like pulling out your phone I don't think you have to. Um, thank you all for coming. Have have a nice reception, travel home safely and when you get home, if you're not trying micro journeys yet, please do. Thanks again.