Episode 264: Product at Scale Inside the World’s Largest Financial Institutions

Creating great products isn't just about features or roadmaps. It's about how organizations think, decide, and operate around products. Product thinking explores the systems, leadership, and culture behind successful product organizations. We're bringing together insights from multiple product leaders, pulled from past conversations, to explore one shared topic, offering different perspectives and lessons from real-world experience. I'm Melissa Perry, and you're listening to the Product Thinking Podcast by Product Institute. Today, we're exploring what it takes to build great products inside some of the largest financial institutions in the world. Product leaders at companies like Vanguard, Chase, and Affirm aren't just shipping features. They're navigating legacy systems, massive scale, and complex regulatory environments while still trying to modernize how their organizations build products. We'll start with Marco DeFreitas and Amber Brzustowski from Vanguard, who share lessons from their digital transformation and why modernizing client experience is central to delivering the company's mission of helping investors succeed. Then we'll hear from Jameson Troutman, Head of Product for Small Business at Chase. He explains how large organizations can move away from funding projects and instead fund product capacity so teams can continuously deliver outcomes. And we'll wrap up with Vishal Kapoor, Senior VP of Product Management at Affirm, who shares how fintech teams integrate compliance and legal directly into product development rather than treating them as blockers. To kick things off, here's Marco and Amber. A few lessons from digital transformations for me, like one of them, the first one is we call it digital transformation, but my first lesson is that it's not about digital. It's not about technology. It's actually about the people. It is about the culture that you're building. That is really the transformation. Obviously, you want to transform the technology. Obviously, a lot of those are really enabled by a deep transformation of our tech stack, but in the end of the day, it is about the people. It is about the talent that you have, the expertise, and the culture that you are building with those people. The second lesson was those transformation efforts, they tend to be multi-year, multi-million or multi-hundred million dollar efforts. So having a very clear sense of what are the goals that we have for the transformation, what is the vision for this? Now, more of the tangible outcomes that we're trying to drive. It is important because you're going to have to always go back to those. Sometimes people can get a little disappointed with the pace. You're going to make mistakes along the way or things may take a little longer. One, you have to have them very clear, but then have to always go back to them. For us, it was transform the CX, build resilient platforms and products, and then drive agility for the organization. We always came back, all the OKRs, like a lot of our metrics came back to those. And then maybe a couple more was in the end of the day, a transformation is also a systemic change. So thinking about the operating model more broadly, it is not only about agile. It's not only about having, but bringing in a little bit more experimentation. It is all of that. It is actually bringing more DevSecOps. It is an end-to-end transformation. So thinking about it systemically and thinking about an operating model is critically important. And then the last one was delivering some wins and communicating along the way is critical. Setting the right level of expectations because, again, any multi-year effort, you have to have sort of set clear goals and have to communicate, be very transparent of the things that are going well and the things that are not going well. And to me, if I were to piece together from different experiences, those four things are what makes transformations successful or areas that I personally learn hard lessons along the way. But I think those are key ingredients for success in any transformation. So a core part of your digital transformation is about client modernization. What does that actually mean for Vanguard and why is it so crucial at this stage? So for us, when we look back when we really started in earnest and actually had an infusion of capital, we thought that our client experiences needed, almost we needed to break with escape velocity. We had a lot of efforts that were partial in nature or they were going against this very brittle tech stack and we were banging our heads against the wall a little bit. So we thought what we needed to have that escape velocity. And part of that was because we're getting dated. We did not have that velocity that we wanted to be to stay competitive. So definitely, like for us, at the core of the modernization effort was like, we need to modernize our client experience and get to that more contemporary experience. But also for us, linking back to our mission, in the end of the day, we wanted that experience to work harder for investors in making them better investors. At the core, like the modernization of our client experience is actually the delivery of our mission. And I don't want to be dramatic, but if you believe that we were here to make investors more successful, we were here to make better investors, a lot of that has to happen through the experience. A lot of that has to happen through the data that we have about our clients, so the insights that we can drive and pump those insights through the experience. So that's why client experience was so core. It was, yeah, we were falling behind, number one. And second, we thought that could be the differentiator for us when we actually bring that, basically the ability to nudge clients the right way, the insights, help clients make more educated decisions about investing and avoid bad decisions. In the long term, that has a significant potential for value creation for our clients. And we thought we needed to do that. We already do that through our funds. We believe our funds deliver alpha, the financial terms of excess. We are very low cost and they beat the benchmarks more often than not. We do that through our advice. So we have an advice offer. We believe we also generate access returns through portfolio construction, through just behavioral coaching. And then we thought we need to now deliver that alpha through the experience. So developing the right default experiences that help clients to kind of cut through the clutter of financial services lingo and experiences, and then foster better behaviors of investing. And we needed that modernization so we could really continue to deliver our mission through the experience as well. And so a lot of the work we have been doing has been kind of like, all right, let's get the foundation right. Let's get the experience layer to be best in class. And then on top of that, let's now deliver best or quality guidance to clients through nudges or through better experiences. And that's what we're calling CX Alpha. We can talk more about that, but that's a collection of nudges that really make them better investors, more successful investors in the long run. I don't recommend tools unless I actually use them. So when I tell you granola has become a daily essential for me and most of my team, that means something. We're all in a lot of meetings. Granola is an AI notepad that quietly enhances your notes in the background. No bots joining your call, no awkward recordings, just cleaner thinking after every meeting. It's the rare tool that gives you time back instead of asking for more of it. You can try it yourself with three months free on any paid plan at granola.ai slash product institute. With all of these different modernization and transformation techniques that you're doing, how are you making sure that this transformation part really aligns with the broader goals of Vanguard and also with your customer needs? I could start there. I mean that to me, ensuring that the business strategy aligns with product strategy is all about setting the right incentives, goals, and problems to be solved at the product team level. We've talked a lot about our strategy and both of our businesses is to win against the competition by helping investors become better investors just by being clients of Vanguard and creating experiences that drive that. That requires the product teams to obsess about that as the problem. So if you look across and Marco mentioned, we're organized by product team. We try to run a fully stacked agile product operating model. We succeed in some ways. We're still working on evolving to complete maturity there. But each of the product teams, if you look at my retirement business, they're measured on outcomes. So whether it's helping the participant take the next best positive action within their journey, making sure that the participants are getting through the journeys with speed and agility, each product team has a goal that's aligned on driving an outcome and getting that participant to take the positive action. To me, that is key, is driving that alignment from the business strategy down to the problems that could be solved and then empowering the product teams to come up with the solutions themselves, not be prescriptive about the features. The example I gave with, I call it our new, our financial wellness experience. The product teams, we said the challenge was getting, removing financial barriers that are getting in the way of getting someone to a save in a retirement plan. And that's all we told them that they needed to do. And they designed that experience themselves. And by empowering them to really swim upstream and obsess about the problem and not being prescriptive around features and what does this need to look like, outcomes follow that. The survey I told you that starts the experience that asks about how someone's feeling about their finances gets to almost 80% completion rate. And that's a ridiculous completion rate. If you compare that to other tools that exist in the retirement industry, typically we see like a 10 to 20% completion rate with digital tooling. But I attribute that to the fact the team got super smart and really got to know their clients and what was getting in the way and their mindset as they were approaching things like planning for retirement. And then they designed the digital products around those problems and the client need. So to me, that's how it has to all flow together to make sure that the teams are operating in a way that really lines up to how you're for it and then deliver it. And when we flipped it to, and the mindset we really focused entirely on was how do we want to distribute the capacity that we have across the organization, whether that's product management capacity or design capacity or data capacity or technology capacity, how do we distribute that across that product architecture so that we can then empower the teams that have accountability for that capacity to then prioritize what they think is most important, organize that work, do the discovery, and then deliver against that roadmap? And we have mechanisms in place to portfolio manage that ecosystem. So it's not an accountability without oversight, right? So our product teams are accountable for demonstrating how they're using their capacity, what they're delivering, what it's returning for the business, how it's addressing customer problems, but we're also trying to balance that with that empowerment, right? And giving them the ability to being closest to the customer and closest to the problem to make decisions around what is the next best thing to pick up in their backlog. And so when it comes to budgeting, very specifically, we try to think about budgeting in terms of capacity, right? It's funding the capacity needed to deliver against an area or a domain or a set of capabilities. The thing specifically in that that gets delivered is a function of prioritization within that capacity. And again, to my point earlier, we do have mechanisms to rebalance that capacity across the portfolio when needed. Maybe we need to rebalance a little bit more, really go after a specific problem or a specific opportunity. And that allows us to manage that at the portfolio. So it's not a static decision, but at the same time, we don't wanna be in a world where we're constantly swinging budget around every month or every quarter because that impacts speed, it impacts your subject matter expertise and your quickness to deliver, and it takes some of the value of letting delivery happen closer to the customer and pulls it away a little bit, which risks potentially not fully addressing that customer problem. Getting that strategy alignment up front, I think empowers everybody to feel like they own this problem together. I always joke with my product teams that there is no right place for an idea to surface. Anyone should be empowered to create ideas, to generate opportunities, but it needs to be aligned with the strategy. And we all need to agree, this is where we're moving, now let's create all the opportunities and ways we might move in that direction. And that should be a team sport, right? So idea generation, idea creation shouldn't come from one person or two people. It shouldn't come from product only or the general manager only, et cetera. To me, the first step in success in that ecosystem is to have open communication and dialogue with your business partner. So that to me is table stakes. And where I found it not working, there may be other reasons why it doesn't work, but one of the core reasons I've always found it not working is because there's not good communication, there's not good clarity, there's not good connectivity between the product team and the business stakeholder, the general manager or whoever is the key person on the business side trying to drive the strategy forward. So that to me is the first, most important thing. I think the second thing, and this is where I go back to the very beginning when we talked about prioritization, getting alignment on that prioritization, as hard as that may be, unlocks a ton of speed of feedback. So it's a matter of where do you want the pain to happen? Do you want it to happen upfront when you align on your key results that you're gonna try to drive, your outcomes you're trying to achieve, and what are the tactics at a high level that you think are the most effective to achieve that? If you spend the time doing that upfront, it's not meant to be a static thing. You can revisit it and keep it evergreen and ongoing. Investing time in that process then lets the team feel more empowered to just go, right? And the decisions then that bubble up during that tend to be smaller. They're still hard to make. Am I building this feature or not building this feature? That's still an important decision back to the communication part that you talk to your partner about. But that's a very different decision than am I building this thing at all? And so a lot of times where I also see things fall down is where there is a belief of alignment on prioritization, but in reality, they haven't invested the time in actually ensuring that there is alignment on priority. And so the issues that surface appear maybe in other ways or for other reasons, but they do go back to, I don't agree with what you're building. And so as long as you can get that upfront as well, I think that unlocks a lot of speed and capabilities for the team. And then the last thing I would say is, we really try to empower product teams to think like an owner, right? They should think end-to-end. They should understand the P&L. They should believe that they have accountability with their business partner to deliver that outcome. So we also try to really encourage them not to think about this as being someone passing the baton or throwing their hat over the wall to them. We're both in this together and we both have an accountability to achieve this together. And so that kind of empowered mindset hopefully drives the product team to feel like they can have those hard conversations with the general manager if they have to. Or the vice versa, the general manager can have the hard conversations with the product manager because they're in it together. Jameson walked us through one of the biggest shifts large organizations need to make when moving to a product operating model, changing how work gets funded. Instead of budgeting for individual initiatives, the focus shifts to allocating capacity to product teams and empowering them to prioritize the most important problems within their domain. That shift creates more ownership, better decision-making, and ultimately faster learning. But in financial services, there's another factor that shapes how products get built, regulation. Next, we'll hear from Vishal Kapoor who explains how teams at Affirm work closely with legal and compliance from the start of product development, treating them as partners in building responsible and scalable financial products. So here's how he approaches that at Affirm. When you're looking at that problem space too, do you go through any cadences at Affirm where you say, hey, these are the problems we're gonna prioritize? What's that look like? Yeah, that is the currency of how we build product. So thank you for asking that. So we have a weekly cadence of reviews where the teams across the different surface areas brings their key problems into that forum for feedback and for building alignment, for getting to a decision. And those decisions could range from, is this the right problem to solve? Is this the right sequence by which we should solve it? Is this the right dependency chain that we should be going after? Are these the right partnerships that we should be exploring, et cetera, et cetera, et cetera. And so these forums are regularly constructed on a weekly basis for feedback and alignment and information sharing. And that is the currency of how products get developed at Affirm. And that feedback loops are generally, I would say, more frequent than the products themselves because some of the decisions that we make is like not the right time or not the right sequence. So that is like the decision-making part of the entire process. Are you thinking about prioritizing like bigger level things on a quarterly basis or is it more, we just go week to week and like how do you keep that thread of the big things going? Yeah, so we hold those two things constant. We have a vision at a yearly level, at a quarterly level, but we execute on a daily, weekly. So those two things are very much ingrained into everyone's, you know, zeitgeist is like, okay, where are we heading? That's the North star. And then we work backwards from that into what are we doing in terms of the next step to get there and the step after that. And how do we measure that we are getting closer to the destination? What are the different metrics? We are very quantitative of fintech. So we have key metrics for every single thing in the portfolio. And so we set those goals ahead of time. We also set directional guidance on how we want to get there. But then it is the weekly rhythm that we are talking about that then discusses and decides what are the next few steps to get to that end goal? Are we taking experiments? Are we taking some known problems into the roadmap? Are we taking some bigger bets? So all of that portfolio allocation happens at a quarterly level, and then we execute and we measure against that look back and look forward at these rhythms that I'm describing. In many large organizations, there is like a compliance department or a legal department that the product managers see as roadblocks where they're like, you can't do that, you can't try this, you can't do that. How do you navigate working with the legal side and the compliance side in your area? I just heard you say like we take it as inputs. What's that working relationship look like and what should it look like to be able to keep building great innovative products? Yeah, and this is another very key strength of a firm is that all our departments are joined towards delivering against this mission that I mentioned. So we actually see compliance and legal as very, very important part of the product development process. In fact, we lean on them to get the subject matter expertise and then partner hand in hand and understanding where can we go? What should we be aware of? And what are the different inputs that we should be thinking about ahead of time so that we don't go five weeks in developing a thing and then realize, oh my goodness, I should have known this beforehand, right? And so it is a lot like jazz. We are playing it together, the different instruments, and we're trying to improv. But at the same time, we know what the setlist looks like. We know what the constraints are and legal and compliance are embedded deep