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 De Freitas and Amber Brustowski 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 Jamison 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, or 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.
Thinking about the operating model more broadly, it is not only about agile.
It's not only about 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 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 learned 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 Nerdist and actually had an infusion of capital, we thought that our client experiences needed almost we needed to break with scape velocity.
We had a lot of efforts that were partial in nature or they were going against this very brittle tech stack, and we're banging our heads against the wall a little bit.
So we thought we needed to have that scape velocity.
Part of that was because we're getting dated.
We did not have that velocity that we wanted to be to stay competitive.
So we 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 experiences, is actually the delivery of our mission.
And I don't want to be dramatic, but if you believe that we're here to make investors more successful, we're 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 derive, and pump those insights through the experience.
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 off of this financial terms of access.
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, that 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 granolaai 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 being 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 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 an 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 trying to differentiate and your ultimate business strategy.
Yeah.
And Melissa.
Just to add to that, we also use internally an OKR framework that helps us align that digital transformation, or even any digital work, to those business goals.
So it flows more top-down.
What we're trying to accomplish as a business and then how do we get those objectives translated and key results and the problems to solve get handed to the teams.
And they are aligned to those.
So I'm a big believer in empowerment.
But empowerment without alignment is chaos.
So this framework help us align those teams to the right objectives.
And then, on a periodic basis, we do a lot of quarterly reviews of roadmaps and really discuss with the teams what the roadmap four quarters out look like.
What are the types of outcomes they're driving, what types of results, what type of outputs they're driving they're achieving to achieve those outcomes.
So it is a constant, like every quarter we have.
Obviously, the teams are themselves doing ceremonies that are more bi-weekly or even monthly.
And then we as a leadership team go all the way up to my boss of.
This is how the portfolio is performing.
I think those processes help us constantly make sure that there is alignment and we're optimizing capital allocation towards the most important goals.
So Marco and Amber highlighted something that often gets lost when companies talk about digital transformation.
The real transformation isn't just the technology.
It's the people, the culture, and the operating model that supports better decisions.
They also talked about connecting product work directly to mission.
At Vanguard.
Modernizing the client experience isn't just about improving interfaces or adding new features.
It's about helping investors make better long-term decisions and ultimately become more successful investors.
That kind of clarity around outcomes becomes especially important when you're operating at massive scale.
Next we'll hear from Jamison Troutman, who shares how large organizations can move away from funding projects and instead fund product capacity, giving teams the stability and ownership they need to continuously deliver outcomes.
Here's Jameson.
How do you kind of encourage that culture or encourage people to have judgment in your product team but also to trust that judgment and listen to it when you go forward?
It is an ongoing push and pull that we have with our business partners, with our leadership team.
What we try to do is I break it down.
We try to focus on three primary things.
First, let's make sure we not lose sight of the customer and what the customer is telling us.
So we try to really make sure we put the customer at the center.
It's great that everyone will have an opinion and a view about on what they think the right answer is, but it's important to make sure we know what the customer's perspective.
And so we really try to focus a lot on that upfront discovery, a lot on that customer research, and that can be quick.
It doesn't have to take months to do.
It can be done in an hour or a day, but making sure we don't lose sight of the customer.
I think the second equally is important making sure that we don't lose sight of what is the business unlock that we're trying to achieve.
Are we driving revenue?
Are we reducing complaints?
Are we trying to take expense out of the system?
What's the OKR?
What's the key results that we're trying to accomplish by delivering whatever this is?
And there may be a primary and a secondary, but you want to make sure you're clear on what those are and really being focused on making sure that you don't lose sight of that goal amongst stakeholders, complexities of prioritization and scope.
The third piece is to balance speed and complexity of the build with unlocking those first two things right.
And that's sometimes the harder part, which is where I find a lot of the odds starts to come in and the judgment we try to empower our product managers to have.
I can unlock this two sprints earlier, but it might not get these three things.
Or do I wait to get those three things and then unlock it two sprints later?
Or that may be an easier decision because it's only two sprints.
What if it's two quarters?
I can unlock this now, or I can wait till the end of the year. to get you the other five things.
And so that's an ongoing kind of challenge.
And why I push my product teams is to be very transparent in those conversations with our key stakeholders and with our finance partners, with our executive team, so that everyone knows what we're thinking, what we're looking through and why we have a point of view.
But to own that point of view, feel empowered to own that point of view and be able to defend it.
If someone says to you, why do you think that's the right decision?
I would make a different decision.
You should be able to be comfortable having that point of view and defending it.
And then I think, the last thing I would just add is it's always amazing when we get the chance to build products that actually make an impact in the market, in the lives of our customers and help them grow their business.
But we also build a lot of products, then internally, help us do a better job of servicing those clients, right.
They support our bankers who are out every day meeting with clients, or they support our servicing representatives who are taking the phone call from a client.
And so we also try to balance the external customer with the internal customer.
And that sometimes means you have to make different decisions, right?
Because we maybe unlock the value of the external customer quickly, but it might create a really, really awful experience for a banker who's trying to service that customer.
And we have to decide if that's really worth it or if we need to take a different path.
I'm curious, how do you think about this innovation and these new features, these new products?
How are you kind of managing for that?
And as a business too, at scale.
I know you've led a big part of the agile transformation to get people to think more in products.
How do you think about budgeting for that too?
And managing like that portfolio of products across it?
Because I see that as a huge issue and a huge blocker for people or for large organizations that are trying to move to a product mindset of how do we actually make sure that we fund innovation correctly, we're thinking about the portfolio correctly and we're not stuck in this project mindset.
Yeah.
And it is a challenge and we've been on this product transformation for a number of years now.
And I did have a fortunate opportunity to lead that for a number of years for us at Chase.
And it was a massive transformation in scale across all of our Chase franchise, not just small business across our entire Chase franchise, whether it's the consumer banking franchise or the credit card franchise or home lending organization, et cetera.
And we stood up a product architecture.
We played structure and teams around that.
To your question.
One of the biggest items we spent a lot of time on is how do we think about the allocation of capacity or, said differently, the budget associated with these organizations in this ecosystem?
And what we tried to do as a first order principle was move away from this idea that going to identify a thing we want to go do budget 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 I 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 that, 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 in the portfolio.
So it's not a static decision.
But at the same time, we don't want to 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 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 upfront, 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 a 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 after you do it.
So it's a matter of where do you want the pain to happen.
Do you want it to happen up front, when you align on your key results that you're going to 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 up front, 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 to the communication part that you need to 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 that 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 for 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 feel like they can have those hard conversations with the general manager if they have to.
Where 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 going to prioritize?
What's that look like?
Yeah, that is the currency of how we build product.
So thank you for asking that, right?
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 a firm.
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 bigger level things on a quarterly basis, or is it more?
We just go week to week.
How do you keep that thread of the big things going?
Yeah, so we hold those two things constant.
We have a vision at an yearly level, at a quarterly level, but we execute on a daily, weekly.
So those two things are very much ingrained into everyone's zeitgeist.
It's 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're 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 a compliance department or a legal department that the product managers see as roadblocks, where it's 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 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.
I guess 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 components, 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're playing it together, the different instruments, and we're trying to improv, But at the same time we know what the set list looks like.
We know what the constraints are.
And legal and compliance are embedded deep into the product process, with each of the product managers having a contact.
They can reach out at any time and understand and brainstorm on potential options and solutions.
So I can say confidently it holds across a host of different functions because, as I said, we're together trying to get to this mission.
And so everyone has that right end state in their mind and working backwards from there.
So legal and compliance, very, very, very strong partnership with the product team.
One thing you've been talking about too, which I thought might be good to dive into, is how much data that you actually look at a firm.
What do you feel like are the key pieces of data that help make your product management team the most effective?
Where are you getting the sources?
What are you looking at?
What's the heartbeat of the pulse on how you're doing?
I mean, that is, in some ways, one of our biggest trends is the, not just the amount of data, but the fidelity by which we can look at different cuts and different parts of the stack.
And I would break them into three parts of the puzzle.
So one of the key business metrics, these would be how much transactional volume we're seeing.
What are the number of transactions that we're seeing?
How much is the average cart floor that we're seeing, et cetera.
So these are the business centric metrics.
And these are all interrelated.
The second would be the product-centric metrics.
So what are the leading indicators of customer engagement?
How many customers are starting an application?
How many customers are visiting the app?
How many customers are activating based off the flows that we are sending them?
So those will be the product-centric metrics.
And the third one would be the quality slash engineering metrics, right?
What is our uptime?
What is our latency that we are seeing on checkout?
What are the different facets by which we are scaling up during peak season, et cetera?
And those three buckets that I described business, product and quality slash engineering are the heartbeat by which we know we measure how things are progressing on a daily basis.
So we have daily dashboards that get refreshed, then we have weekly synchronous meetings that we look at and then, of course, on a quarterly basis we have the more aggregated view.
But those three essentially help the product manager understand are the products working as expected?
Are there any outages?
How are the new products that we have launched performing?
And keep a very good 360 view of the situation as things happen.
So we get almost real-time data on all these things that I mentioned.
That's awesome.
Who on your team is responsible for making sure all those streams are coming in and setting up those dashboards?
Product managers actually do a bunch of this.
We have an amazing analytics team that also help out and then engineers themselves as well.
But product managers are expected to not just create, but monitor and be very data informed.
And so that is like a core part of many of our product managers' daily lives is to be very metrics oriented.
That's it for today.
I hope you got something useful from these clips, whether you're thinking about scaling product teams, modernizing legacy systems or building stronger product organizations.
If you want to hear the full conversations, check out episodes 213, 232, and 196.
And if you want to level up your product skills or grow your career, head over to Product Institute.
One last thing before we go, I want to recommend a tool I use every day called Granola.
It's an AI-powered notepad for meetings that helps capture notes and decisions automatically.
You can get three months free on any paid plan at granola.ai slash product institute.
Thank you so much for listening to the Product Thinking Podcast.
Make sure you like and subscribe so you never miss an episode.
We'll see you next time.
