Update on Product Solutions and Development Teams

Dan

Salander, Hi

everyone. Thanks again for joining us. My name is Dan Salander.

I

will talk about the development team. So for those of you who were here last year, Mike and I talked a little bit about the ways we were seeing different behaviors and different trends across the spectrum of credit risk profiles.

And in that presentation, we kind of alluded to the teams we were forming and maybe sharing more. And here we are a year later. We are actually here to talk, I don't know, exclusively about our teams and kind of socialize to you all the changes we're holding out between our two organizations.

So, to dive into that, our two teams again are the product solutions organization and product development. And where these teams started was really, with Dave's leadership around a year plus ago, we started to take a new look at our approach and the operating model we have against how we deliver solutions, but more importantly, how we intake the means we're hearing from our customers to make sure we really understand those desired outcomes and improve the partnership that we have with all of the

organizations. And after the intake process, the product development team works as kind of an execution team that's focused on how do we take the basic outcomes that we're capturing while solutioning with this customer and turn it into a functional requirement that we work with that purpose of any hearing team to actually work with us to build the desired outcome for our customers.

So, Mike and I are

leading team that essentially form a handshake between those two phases of the work cycle. The first half of intake and kind of solution discovery definition and alignment with you all, and then delivery in close alignment with technology to make sure that that agreed upon solution doesn't just live on the page but comes to life in the coder configurations that we deliver.

Now we did put the word product in front of both of these teams. Could you pause any question? No one. So, we thought we would just really hammer home again the distinction between these two teams. So, my group of product solutions organization is just that.

We're a solutions oriented team. And a number of you in the room may have heard me speak at your QBR or you may have worked with some of the folks on my team. So, we really partner closely with our clients and with the account teams that fix off with our clients day in, day out to make sure that as new outcomes come in, as new functionality is requested, we can really, really accurately define that desired outcome and lay out all the options we have available at Vicer to meet that team.

The product development team on the other side is execution oriented, which means you're less likely to interface with us in like a QBR or even in one setting you're less likely to look at us. We're really embedded in the delivery team and there's a science to this, right?

There's, when you're building the software, like agile software development, bringing the products to market, enhancing the existing products, there's a product owner role that needs to be fulfilled in order to success to make sure that the business outcome is what ends up in the deliverable as it comes out.

So, the product development team builds that role, you're less likely to see us in the daily place, but you definitely see the outcomes and the artifacts that you may come across. And the product development might just have to let it run into the

two

guys.

So,

that's

our team. And I know we hammered and joked about the term product in our teamings, but that's also a really important point, right? When it comes to working with you all, my team and Product Solutions, we really represent the front door to our product ecosystem on the Office platform.

And I kind of like to say, our work always ends in three outcomes. We can either meet the need with something that exists today, we're going to meet the need with something that's on our product roadmap, or we don't have something on our roadmap to meet that need and need to build something new and acute.

And that's where we work to make sure that in doing so, we kind of coincide with our broader product strategy. Because the more strategic we can be, the faster we move, the faster we can deliver the outcomes that our clients can move.

So, when we go back to where my team started, it really stems from this observation that at Vicer, we do our best work when we work really closely with you all. And I think over the years, you can all probably remember anecdotes of times where you got the right people in the room that have the right conversations, and after a swirl or churn or confusion, something clicked and things started to fall into place.

And the question became, knowing that that's an organic phenomenon in our partnerships, how do we operationalize that? How do we create processes that make that not just a nice -to -have, but more of a certainty in how we work with you and how we deliver the outcomes you're looking for?

So, in establishing the team for product solutions, we first established a very diagnostic approach to intake. I think historically, we've had some partnerships where we're used to saying, tell us what you need, tell us what you want us to do, we'll go build it.

We'll just go build it. Right? And I think over the years, we've learned the danger in that, the double -edged to that. Sometimes we build exactly what we're told to build and come to find down the line we've delivered, and it didn't actually solve the problem.

Or we had some miscommunication about what was being asked, why it was being asked, what the context was. So, by being really diagnostic up front, we're trying to give us every advantage to uncover those unknowns up top, at the front of the room.

We do that by collaborating closely with our customers, by having those meaningful conversations, by making that kind of a prerequisite to start the process. And we do that by having a team, and I'm very happy and proud of the team I have in place, that spans both system and industry knowledge.

My team is comprised of some folks who were former clients of Fiserv themselves, folks who have been around our technology for many years. We have accumulated decades of experience on the team. But we also have some folks that are earlier in their career, and have a different perspective in terms of the technologies they're used to, or the strengths they bring to the table, to bring that newer perspective to the strategy that we do.

When we marry that formula with product best practices, which is, again, thinking efficiently, trying to use existing functionality to the best of our ability, and documenting, documenting, documenting everything at every turn we can, we stack the cards in our favor to prevent the kind of ambiguity, miscommunication, misunderstandings that can be a part of doing business, but don't have to be the norm when it comes to delivering solutions.

So, to kind of make that real, and illustrate that for you, well, my team's process starts with an intake form. Everyone's favorite. We love forms. I've never heard someone complain about a form in my life, because my brain selectively can't hear it.

But knowing the friction a form can add, this is not a snippet of a more exhaustive, longer form. What's on the screen is our entire intake form. And I would actually draw your attention, does this work? No. I thought we'd be able to wait to point here.

To the second kind of major road here, which is describe the desired outcome for your end user. And it was kind of interesting to see, early in my process, I'd get forms from some customers that would say, my desired outcome is that Fiserv opens a project, add this to a custom shop.

And, you know, we can chuckle at that, but I actually would invite it because it gives my team an opportunity to say, what is the file for? How are you expecting the file to help your business user, your cardholder, your bottom line?

And by drilling into that extra, oh, actual living holder? Between this and the walk -out music, I feel like we're getting a special treat.

That question. And I'm not kidding, that's the only time I'll use this later.

But I really do say, like, this is the moment where the differentiator of why we formed my team and why this process matters is, again, those organic conversations we usually have to work toward and hope for, we try to start with from the jump by having that diagnostic intake conversation.

Get the details that are going to be crucial for us to find and recommending the right solution to move forward with. At the end of my process, the lab routine generates what we call a solution document. And this not only reiterates the information from that intake form to restate the need, restate the desired outcome, but it's an artifact that doesn't just lay out business requirements for either configuration changes or a custom development project, but it should, in its best form, be a story of all the work that took place.

The things we tried, the options we ruled out, the things maybe our customers explored before they even can't gain to us and say, we know these three things won't work, and here's why we want to go down this path.

And that serves a couple purposes. The first is, I kind of like to say the end of my team's process doesn't just kind of a silver clad of solution. It should really be an empowering moment for the customer to make a decision.

Whether that is a t -shirt size to inform whether you do a cost acceptance for a custom project, whether it is like, you have different options and you can decide if you want to solve something with existing functionality or something new, solve something by a change you make within your own shop, your own new leads, which we've seen in the past.

By laying all this out, we not only foster that alignment with the customers, we create an artifact that we can pass downstream to other teams. First and foremost, the product development group. So

let's talk about what that looks like. So today, the product development team uses the solution proposals that the product solutions team creates as an input to our process, which really kicks off when we're in the estimation process today and evaluating OPEC.

We've got a solution that requires a new product that we think needs to be brought to market to support the needs of our clients. The product development team is really focused on how do we take the business outcomes that are defined by the product solutions team that are captured from you and turn them into ways that are a functional requirement.

And, you know, there's a process by the product. And, you know, there's a process by which you can go from your desired outcome and convert it into the kind of language that folks working on our platform and what our deep knowledge of our platform is in.

The Vicer language, the Vicer language, the OPEC language can be complex. There's hundreds of subsystems on this platform. There's this given application surrounding the platform. And to bring those business requirements down is a specialized skill set that we've developed in all major time that I'm trying to use to make a better experience for you guys so that, you know, the how it comes together with our seamless care.

So we closely collaborate with our technology partners in the estimation process, in the delivery process, and beyond, honestly, we do a lot of documentation after the fact that really our outputs are present on that delivery. We have a deep understanding of the products and specifically, like the buying domains that we support today.

And our focus is on speed and precision and delivery, meaning that when product development is involved, we accelerate the production of the HLE by making sure that our engineering partners not just understand specifically the business requirements being submitted, but why those business requirements are being submitted, and functionally how does that translate if it changes our platform.

So in order to do that, our team has deeply adopted, and we saw the different phases of adoption of the economy. Our product development team has deeply adopted into, especially the user of the car, because what we try to do is, is we will produce a prototype in kind of the process of reading out the product solution scheme.

That prototype can actually be used to work backwards and inform our business requirements. So before we even start documenting users for reuse and acceptance criteria of other artifacts like user journeys, we'll actually try to prototype what needs to be built.

The best way to do that. The best way to do that is to make sure that they understand sentiment and functionality that needs to be delivered is actually showing them the functionality. So this team is very effective in using these tools.

It's made our development process faster. It gives our engineering team oftentimes something to start with rather than just a set of information that needs to be well understood by an engineer. And that acceleration actually shows up in our delivery lifecycle and our estimation process.

So that's an artifact that you'll come to experience. You're not really meeting with the product development team and explaining your needs. What you are going to see is eventually is different artifacts such as users have those testing. So when we go to build new software, what we're doing now is when the software is approaching the phase where we have the opportunity to test it, before our clients are actually in there testing it, or really at the same time as our clients, depending on how fast you guys go, we're actually in there with product owners performing a business lens user acceptance test to make sure that not only are there no defects and bugs, but also that the experience is coherent and consistent directly.

So we're looking at this through a business lens. We understand the business outcome that needs to be achieved. And we're working to make sure that the customer experience, the end user experience actually makes sense. So we're doing that either at the same time as you guys or before you guys are actually accessing the software.

For those of you who like, walk into our website or a lower environment and actually test with us, a product owner, a business user is going to be in there with you guys.

So maybe that's a really compelling story. And one of the basic experiences, less defects, less bugs and honestly, when there's a bug that you may not know it's out there, we're going to catch it before you guys do a result.

So it's going to be really a different experience for

our customers when we're delivering that. And by teasing the future tense, because as we said, these teams are one year into their tenure. And those of you who have worked with my team or who have seen some of these design documents, you're already experiencing this model.

And in some cases, you may be thinking, I've never seen a solutions document before. I just submitted something the other day. I didn't get this back. And that's a result of just our continued expansion and rollout of these frameworks and these functions across our business.

But we have started to see some promising results and the impact on the business. And it comes back to some of the principles that I laid out when it came to forming these teams. The results that there's kind of handshake between product solutions and product development that we're expecting to see increasingly across the business are that improved quality, that speed to market.

And when I say speed to market, I think it's easy to think speed to market meaning how fast are we deploying code, how quickly are we getting dates assigned to projects and seeing things. But I would also call that speed to market in terms of outcomes.

If we get a request for new functionality, and we find an existing path to solve the need and get something happening for that end user, for that business user in a matter of weeks instead of a matter of months, I consider that kind of logging into that speed KPI that we're tracking.

Because at the end of the day, that's what we care about most, whether we're delivering a project. That's why my team is called the product solutions team and not the product projects team. Because our goal is to provide solutions, not just that path to development delivery.

And again, going back to the documentation, my team focuses on the kind of artifacts that product development creates. Our focus is really on better accountability, which translates to better partnership, better communication. We're trying to increase that collaboration and transparency throughout our process.

We have three different specializations in our product management team. There's one specialization in common, working with our customers to understand their needs and solution their problems. And that's the product solution team. There's our product management team, who we work with every day at the time, we've got a great shirt in America and others, who are focused on setting a strategy for our business.

They're making sure that we're ahead of the market in terms of what we live. And then the product development team is the third specialization that we are for, which is the ability to execute. It is the ability to partner with our technology teams to bring products to market quickly with excellence, using the way it's tools, and make sure that the outcomes are where they need to be.

So having those three different specializations in place means that you excel because of your disposition, because of your personality, because of your skill set. If you excel in one of those three dispositions, we grade you as such as a five services.

Your value is in your specialization. And I think that's a really compelling thing. We're not the first people to do something similar to this. And we think that it's driving these outcomes every day. We've got specific examples, but I think we're going to take it through at least one of them today.

And John, do you want to do that? So we do have an example. Late last year, we actually saw five different variations of the same requests come through at once for five different customers. And each customer wanted a slightly different way to monetize account funding transactions.

This is based on some visa guidance that we just announced. So we're in that kind of classic situation where you have five different cooks coming into the kitchen saying, I want it this way, I want it this way, I want it this way.

And rather than teams going, opening five projects, competing with each other, buying for who goes first and which is the right way, and well, we built it one way, and to build it for the other one, we have to undo this or that.

And so we're going to see that because our teams were in place, those requests first came through my team. We were able to spot the trend, see the opportunity to kind of synthesize all five needs into one proposed solution, and then work very closely with Mike's team to make sure that we understood and could vet and articulate what that strategic solution could be.

So not just need to provide clients who come to us with this, but open up for our opportunities for our customers.

Product development worked with the product solutions team and some of our customers to find out who on the office or where they can logically sit to meet every customer's set of requirements without having to manage five different requests for customization of our platform that would have had to, you know, schedule at a rate that may not work for our customers.

So we found something really good here. This is called our transaction classification service. The purpose of this process that we're bringing to market with an MVP in October, specifically for Visa portfolios, allows you to change a transaction after authorization from merchandise to cash accounts.

Now, the way this works is based on new guidance that's been given by the networks on web and an account funding transaction, we've actually set up a self -service capability that's tied to our pricing system in office that are part of the pricing system that doesn't require any implementation to set up.

So you set it up yourself, it's immediately accessible. It's fully self -service meaning that you have the ability to A, B, test it with different portfolios, perform a change in terms to adjust it, and it follows our standard change in terms process on the platform.

And it allows you to basically, you know, there's a revenue opportunity here for our issuers, and it manages the beginning of your card. So if you have cardholders that are maxing out their card by Bitcoin, and that's a behavior that you want to curb, or you want to price that risk into your, you know, risk -based pricing letter, you have that capability.

If you see that your cardholders are using their cards to fund their peer -to -peer accounts, or they're funding multiple peer -to -peer accounts, there are different ways to apply these, this ability to switch more than vice to cash, depending on what behaviors you see from your cardholders.

So it's, it's one of our first kind of forays of a true risk -based pricing. Um, it's, it, like I said, it's fully, you can implement it to yourself. The first iteration is coming out in October for a piece of portfolios.

In Q1 and Q2, we're going to be scaling this to master card in American Express. And we're exploring options in the future on how do we take this construct that's like fully sub -service, and make it so that you can apply to other use cases outside of what the network is giving specific guidance on, such as account funding transactions, etc.

So, um, there's a boulder link for this product. We're going to take you guys seriously at some point. You'll probably see this under QBR, so you're welcome to request it, see more detail. But this is how we chose to introduce transaction classification services.

This was kind of a construct that we developed between five solutions and product developments, just listing to

our customers and our network. So that's the two -fold reason we introduced it in this way today. One, we think it's exciting, wanted to talk about it. But also, we think it's a good example of the proof of these models at work and the opportunities that, um, our teams come unlock for, for PICER and most importantly for our customers.

So if there's a call to action today, it is first and foremost, uh, look to engage with my team. Uh, you may already have engaged with my team. Either in a client 360 ticket or through your account team.

Uh, but if you haven't, maybe you will in the future. And what you do, my subsequent ask is, uh, encourage your teams, whoever your requesters are, to keep that user outcome in mind. Um, that, that really tends to be the diamond we, we seek in that intake process is to get to that true context, that true need, uh, past the prescription we see usually in the face -to -face.

When you use the

requirements, we've got the how, if you get it, right? If you put that business outcome, let myself and Ben figure out, you know, there's been our product development and product solutions team. We'll get some how, and we'll get a bunch of different options, as part of Dan's process to, uh, show you that, like, solution documentation.

And I think you're gonna find some really fun way to get what your needs are and differentiate different products on the platform. So,

um,

really get the most out of your dollar when you're, uh, what's customized.

Okay.

So, before we go on break, any questions for Mike and I about our teams? Yes.

So, I appreciate this structure is gonna be moving forward. Are you guys also handling the text for, if these products or if these are not working on current

product challenges with this thing? Yes.

So, if, if, if you ever, I mean, if you have a specific challenge of, uh, I think the product solutions team would come in and say, I have, I mean, what do you mean?

Yeah, I would say.

We would still say open a ticket worth of the product consulting teams. Open and take if you're seeing, like, a live break in production. My team's domain tends to be net new functionality, uh, new outcomes for customers. If there's a desired outcome that you're not seeing, we have kind of existing teams that, that should kind of start that conversation.

But when that conversation becomes, oh, you're looking for something new, there have been times where customers have come to us. There's actually, I won't name names, but there have been times where a customer comes to us and says, I got 60 days for a regular program issue.

This isn't working the way I expect it. And, you know, what my team does is, and again, coming back to this principle of the solution document laying out all possible solutions is to say, here are the eight things you could try on the opposite system.

Maybe they're introduced slow. And in that particular example, the best solution was actually for the customer to make a change in their own GUI based on how they've voted against the system. So, I think when you need that extra layer of, uh, kind of investigation and solution definition, that's the right time to come to my team once you've stopped by what I'll call first responders for those scenarios.

Okay. I have to call on some more questions. Okay. One day I'm a part of the issue, too. Thank you for the work you've done with TV and Brandon. Great. Thank you. And Mike, I've appreciated the meeting about that.

I don't think you're answering a little bit. I don't know if I'm going to go to the last time. You don't know if I'm going to go to the mic somehow.

You talked about in your one slide about how you've had some more apps.

Yeah.

When, uh, or do you, when a client has a problem to solve, really understand that problem and look at what do other clients do for that instance, and have they just run the right to development?

Yeah, I mean, absolutely. That's, that's usually one of the first questions, and I think that's where I'm really blessed to have a deep bench of folks who have been clients themselves, or have been around long enough to know some of those best practices.

Um, I think there's an interesting moment we're having to, and again, I'll caveat this with my team's a year old, so I think in the, in the cycles we're in for development and conversations, things still feel pretty young.

But we're starting to see a point where we'll actually get the comment, oh, no one's asked us about that before. Or, oh, no one's ever, no one's ever said that's a problem. And I think this is where there's a beauty of my team sitting in the product organization, because we have the privilege of taking that position to say, well, just because no one else has had a problem, like, does that mean there's not a problem, right?

And can we actually take a look, not just from a customer demand and customer input standpoint, but from a product value standpoint, and say, would this be valuable? Is it worth doing? I think it's twofold. It is, yes, what precedent is there, how do other customers handle it, but, and I'll look at some of our more tenured customers, just because you find a way to make something work, doesn't mean you're happy with the way it's working.

And I think that kind of dialogue and that feedback loop is also a function of my team. We kind of, as an organization, kind of reserve the space to have those more thoughtful strategic conversations that are almost divorced from, is it a problem or not in front of the clients?

That's tier one. We have to make that right. But we're starting to get into those opportunities to say, can we proactively make these things better, even without our customers' promptings to do so?

We're also very careful to protect our issuers' differentiation from one another. So we're very conscious on, like, if we get competitive, we keep it very fair play. We're not saying, here's everybody else on that problem. We're saying, here's what your options are that could work on the system's back.

First, thank you. You know, like, this is exactly what your clients need, this kind of client -focused solution to what you're doing. This is what we need. So thank you.

And maybe next year we'll have, like, a third musketeer up here, where you have a product support side, much like the first comment. You know, we need for your support teams to support us the way your teams are supporting us.

It's really important that your support teams put in this much effort on products and understand what the product does so that when we do have problems, we're not spending as much time teaching the PISER support teams on what the product does.

You know, so we would love to see your philosophy in that area as well.

Yeah, thank you for that. I think that's great feedback. And what you just articulated, I mean, that's the North Star at the end of the day. And I think going back to the AI tools that I'll say for my team's part, the ability to more quickly get to the granularity of the facts in our own documentation, our own training materials.

Again, I talk about these solution documents. They don't just go, like, fly up into the sun. They live in a knowledge base my team's building over time. The principle of writing down those options eliminated is so that if we can place those in an environment that's queriable by a large language model, we can actually say, hey, we think we want to try this, this, and that language model could go, actually, you tried that in 2026 with client ADC that didn't work very well.

Right, so I think the more we can get the tool sets helping, the more we buy our kind of frontline support teams that time to bring those principles of tell me what you're experiencing, tell me what your desired outcome is to bear.

You know, I think that's an ongoing process to get to that, you know, definition of good, that level of quality we aspire to. But I would say, too, for my team, it's not just that I, you know, with this mindset that with Mike with the handoff got established in product.

It's also how do we scale the impact of those principles? How do we scale the framework? Even if it's not my, you know, half a dozen folks that I love and I'm very happy to be leading, like, that's a primary resource.

The framework is not, like, the framework can scale, the principles can scale. And that's something we're going to continue to explore and implement as our organization evolves and comes together.

Every time my team builds a new product or a new feature, we actually produce a document that's specifically designed for our language model to read it, understand it, and make it accessible to our services and support folks that are up front lines.

Okay. That's... You've got a hundred of them. I'm really good. Yeah, I know what you'll do.

Why is it going? Any other questions?

Great. All right. One more. Is the flow of these team information the output of yours going into the office transformation at all, or is this

basically

the

relations? As we work through transforming the platform of Mike's over the thousand eight years, it unlocks new capabilities that the product development team is kind of focused on, like, when we get through different ways of transformation, new capabilities will be unlocked.

And we're going to have to gradually pursue the image capabilities as soon as those unlock occur. So if you think about that, it's like, you know, we've got a phase of transformation coming up. There's going to be new capabilities that we want to prioritize and deliver after that transformation occurs, and the product development team is deeply embedded there.

It's also an informed summary of the product development initiatives that are coming out of our product solution team. So it's kind of a

good

sign. And it's,

um, I don't know. I would say it comes back to having a knowledge base, right? To Mike's point, we're, we're, we're, I hope you've all heard about transformation in some depth from, from Mike or about others by now.

We talk a lot about the ways it's not going to impact your business. Because that's the notion of why, right? You have to keep your business as moving and flowing as expected in the area. But kind of to the spirit of the question, and Mike's point, we are going to unlock new capabilities.

And something that I'm excited about is my team's work, we, we shifted our work in the past year being system -based. So we keep behind the curtain, we do everything in JIRA. We keep those documents in the central repository.

And the purpose of that is, I could go back, buy recent code, and say, when did a customer decline a project because it was too costly? Because in our prior state, it would have been how it went in thousands of hours.

Is it worth revisiting that value, knowing what transformation may unlock? Is it worth revisiting that from a customer standpoint, from a roadmap standpoint? So these are questions that are organically going to come up. I think our focus right now is laying a foundation so that we're strategically prepared to address those questions and be thought leaders when we get to that point consistently.

I

think Mike's got a question. No, I just wanted to make one point. That it's not just that I'm not going

to

use the capabilities to your point, but if we do office transformation on that topic, it takes time, right? And if we're going by domain, by domain, anything that we're building in the core office platform today and the next release will be part of office transformation.

So it's like tech debt, but there's no other way to deal with it, but that's like Google. And interestingly enough, like the UFDA I agent producing global code and Java at the same time. So it's hard to do.

So Mike over there knows I'm quite passionate about office transformation. And one of the things we've been talking about is that as an issuer, it's going to be important for us to know in advance what capabilities and functionality it will be unlocking.

And you recommend to us, hey, if you want to leverage in the future, consider doing this now so that we don't have to do another three or four year project internally to prepare for that. So I just feel that's important for FISER to recognize that give us as issuers feedback and recommendations so we can consider that because we are excited about this transformation.

Yeah, we'll see some of these webinars, some of these unlocks in like future webinars as we get further into the process and as we start to launch different environments that are transforming. Those two things will be made fully aware to you.

You're really getting on your even form like these might be opportunities to talk through what are those unlocks and when are they coming.

And I

mean,

actually, we're right with it. Yeah, and I know as part of transformation, we've talked about having folks specifically focused on that journey by journey analysis. And to your point, we know that a lot of our customers have internal systems, internal configurations, internal dependencies that we're kind of, for lack of a better term, blind to day to day.

So making sure that those dependencies, that nuance is brought into those journey mapping exercise, I think, will begin to accomplish what you're describing, right? When we go to map that journey, we'll bring the input of what that journey may look like in a transformed state.

And if we hit into one of those dependencies, we'll inherently have to capture that, prepare for that as we're doing those journey activities.

There's no questions about the transaction navigation.

will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will will