Author: Manu

Designers have built the final screen. Leadership has approved them.

The software architect has created the architecture diagram and defined the API contract, which specifies exactly what data the mobile app will request and what the backend will return.

This marks the beginning of Piece 4 of the fintech puzzle, The Solution Build.

You’ve seen how multiple teams use different technologies to build our feature.

So now it’s time to build it and launch it, right?

Not exactly.

Because in enterprise fintech, you’re never building a feature in isolation.

That feature has to pull real relationship manager (RM) data. It has to integrate with backend systems. It has to route calls to the RM. And it has to work seamlessly alongside every other feature inside the mobile app.

That’s why enterprise software isn’t built and released in one shot.

It’s built in stages. Tested in stages. And launched in stages.

Let’s walk through what those stages look like.

Stage 1: Lower Environments

An environment is a separate copy of the software where teams can build and test without impacting real customers. These environments are hosted in the cloud. The cloud is remote servers managed by providers like AWS or Azure.

Think of it as a rehearsal room. You wouldn’t test a new play in front of a live audience. You rehearse first.

In lower environments, each team builds its part independently.

Let’s see what each team does and why they work in separate environments.

Mobile app developers build the screen

The layout. The RM photo placement. The name and title fields. The call and email buttons.

Once the developers build the screen, the testers test it on both iOS and Android.

They check: Does the layout look correct? Does the image load properly? Do the buttons respond?

If something doesn’t match the final design, it goes back to the developers to fix.

They use sample data because at this stage, the backend systems aren’t connected to the app yet. For example, a sample RM photo, a name like “Jane Smith,” and an email address.

At the same time, backend engineers build the microservice

Backend engineers build the microservice that will return RM data following the API contract. They ensure it returns the exact fields the mobile app expects: RM name, title, photo URL, email, and phone number.

Backend engineers also use sample data. The microservice returns sample RM information—a test name, a test photo URL, a test email—so they can verify it works before connecting to real customer data.

Data engineers prepare the pipeline that pulls RM information into the data warehouse. Database engineers ensure the required data fields exist.

Why work in separate environments?

To allow work to be done in parallel.

If all teams worked in one environment, one team would block another. The mobile app team would have to wait until the backend microservices and data pipeline are done.

In lower environments, the mobile app works with sample data only.

When you tap “Call,” it doesn’t route through the actual call routing system. When you tap “Email,” it doesn’t notify the actual backup team.

Stage 2: Higher Environments

Once each team finishes building in their lower environment, the work moves to a shared integration environment.

This is where everything connects.

Now the RM screen calls the actual backend microservice, pulls actual RM data, connects to actual call routing logic, and sends actual emails.

This is where things often break.

The mobile app might expect the backend to return “RM_Photo,” but the backend returns “Manager_Photo.” Or the data pipeline takes 30 seconds to update when the app expects it in 5 seconds.

Small mismatches like these break the feature.

A dedicated testing team handles this stage. Much of the testing is automated.

The automated tests check if the RM photo loads, what happens if the RM has no photo, whether calls route correctly when the RM is unavailable, and if the backup team gets copied on emails. They also test if the feature integrates properly with other features in the app.

When tests fail, the issue goes back to the relevant team to fix, rebuild, and retest. This cycle can repeat multiple times.

Once all the integration tests pass, the feature is ready for pilot testing.

Stage 3: Pre-Launch

Once integration testing is complete, the feature moves to pilot testing.

Real users test the app. They’re called pilot users.

You invite a small group: relationship managers and a few high-net-worth clients who volunteer.

What do they test?

They call their RMs. Send emails. See what happens when the RM is unavailable. They test different scenarios to find issues before launch.

This phase usually lasts a day or two, but it happens 10 to 15 days before the actual launch.

Why the gap?

Because if something breaks, you can stop the feature from going live before one million clients see it.

It’s much easier to delay a release than to roll back a live feature that everyone has already seen.

Stage 4: Launch

Even at launch, your feature doesn’t go to 100% of users immediately.

Enterprise fintech releases roll out in phases.

For example, your RM screen might first go live to 10% of high-net-worth clients. Then 25%. Then 50%. Then 100%.

Why?

Because this is the first time the feature is being used by real clients at scale.

If something unexpected happens at 10% (a spike in errors, performance issues, incorrect routing), you can pause the rollout, fix the issue, and restart.

That’s far safer than rolling out the feature to one million clients all at once.

There’s something else important.

Your RM feature isn’t launching alone.

When clients download the latest version of the app, they’re not just getting your feature. They’re also getting performance improvements, security updates, bug fixes, and other features built by different teams.

All of these changes are released together as one app update.

Why fintech features go through such a rigorous release process

You might be wondering: why all these stages? Why not just build it and launch it?

Because fintech apps deal with real money.

Imagine what happens if a bug miscalculates a client’s account balance. A high-net-worth client logs in and sees $500,000 instead of $5,000,000. They panic. They call their relationship manager. 

The relationship manager escalates to leadership. 

Now you’re explaining to leadership why a client’s reported net worth dropped by millions overnight.

That’s why enterprise fintech companies build in stages, test in stages, and launch in stages.

You’ve seen how this works.

Lower environments where teams build independently. Higher environments where everything connects. Pilot testing where real users validate the feature. And phased rollout where you launch to 10% of high-net-worth clients, then 25%, then 50%, then 100%.

What started as “let’s build and launch” is now a four-stage release process that protects customers’ money, prevents compliance violations, and ensures the feature actually works before one million high-net-worth clients see it.

 

Technology validation answers one question: Can we build this wireframe?

Leadership review answers a different one: Should we build this exactly as it is?

That difference matters.

Because leadership isn’t reviewing APIs or routing logic.

They’re reviewing:

• Does this solution directly address the churn problem we identified?
• Are there any compliance or regulatory risks in this design?
• Does this deserve priority over other features right now?

If you don’t run this meeting properly, your simple feature can quietly turn into something much bigger than you planned.

Here’s how to structure the leadership review so that doesn’t happen.

Who should be on this call?

You’ll have the same group of stakeholders who attended the Product Blueprint Review meeting.

• Business Leadership (leaders from Wealth or HNW Banking)
• Product Leadership (leaders from Product, Design, and Engineering)
• Dependency Teams (Compliance, Marketing, Client Support)

In addition to these groups, you also have your technology stakeholders who attended your last meeting.

Walking through the wireframe

Similar to the last meeting, you ask your designer to walk everyone through the wireframe.

The designer explains both call routing options.

1) Option A: RM call forwarding (best experience)

Calls go directly to the RM when they’re available. When they’re not, calls are routed to an internal support queue. From the client’s point of view, nothing really changes. It’s still one number. One simple flow.

2) Option B: Call-to-message fallback (simpler)

If the RM doesn’t answer, voicemail directs the client to email the RM through the app. That email is automatically copied to an internal support team that can respond if needed.

You also clarify that this feature will be shown only to the one million high-net-worth clients, not to all banking customers (more than 10 million).

Once the designer walks through the wireframe, you open the floor for questions.

You’re going to get a lot of feedback and questions from this group.

Let me show you what might come up.

Compliance might say:

“We need a pop-up message warning high-net-worth clients not to share confidential information since the backup team will also be copied on emails.”

Imagine getting that feedback after the final designs are complete. You’d be redesigning everything.

This is exactly why you’re reviewing wireframes instead of final designs.

But compliance feedback is just the beginning.

Leadership might ask for more features

Stakeholders will suggest additional features. For example, wealth leadership might want a chat feature in addition to call and email.

This is where you push back.

Keep version one simple. Be ready to push back on requests that make your wireframe more complex.

Because here’s what happens if you don’t.

Someone suggests chat. Then video calls. Then appointment booking. Before you know it, you’re building a full communication platform instead of solving the original problem.

This is how feature creep happens.

So how do you push back without offending leadership?

First, acknowledge the feedback. Then provide data to support your recommendation.

You might say: 

“That’s great feedback. The data currently shows that email and call are the two most used options by our high-net-worth clients to contact their relationship managers. I recommend we first test these two options, get feedback, and then run a survey to see if clients need a chat option. That way we’re taking a data-driven approach.”

Or, the technology team might chime in and push back on this request themselves.

Someone from the technology team might say: 

“We can implement the chat option, but it will take significantly more time. We use a third-party chat platform like Intercom, and integrating that into the mobile app requires custom API work and security reviews. That could add several months to the timeline.”

You’ll also get other questions.

Answer them. If stakeholders have concerns that need deeper discussion, address them separately.

But here’s the question you’ll definitely get:

How soon can we launch this feature?

Here’s what you say: 

“We were waiting for approval on the low-fi wireframe. Now that we have alignment, the next step is for technology to provide timeline estimates. I’ll coordinate with them and share final timelines.”

You need to be the single point of contact.

Because you don’t want leadership to hear different estimates from multiple teams. You coordinate the timelines. You communicate them to leadership.

Meanwhile, you set the next steps with technology.

You ask the software architect to start working on the architecture diagram.

At this point, some technology teams might say they need to run a quick proof of concept before they can estimate timelines. And they might need a week or two max.

Remember, these timelines are estimates. They’re not set in stone.

Technology isn’t the only team with next steps.

What dependency teams need to do

Ask the dependency teams, especially marketing and client support, to share their distribution plan.

How will this feature be distributed? How will it be marketed?

As a product manager, it’s your responsibility to ensure the feature’s success. This includes how it’s distributed, even though marketing typically executes the tactics. You need to be aware of the marketing strategy.

For example, they might promote this feature in bank branches. They might run an online campaign announcing the new feature for high-net-worth clients. They might send targeted emails to relationship managers explaining how to guide clients to use it.

Once you’ve covered technology timelines and dependency team plans, you wrap up.

Wrapping up the meeting and next steps 

You close the meeting by outlining what happens next:

“We’ll share the final designs and timelines after coordinating with the technology teams. Marketing and client support will present their distribution plan in a separate session.”

With alignment secured, your designer turns the wireframe into final designs.

Once complete, you send them to leadership for approval.

At this stage, leadership shouldn’t request major changes because all you’re doing is adding UI and copy to the wireframe.

The UI is already defined in a design system, a library of reusable components, colors, fonts, and spacing rules that keep the app looking consistent. Leadership can’t give feedback on UI elements because they’re standardized across the entire app.

The only feedback should be on the copy. If you get copy feedback, your content writer makes the changes. Then you share the updated design with leadership once again for approval.

That completes Piece 3 of the fintech puzzle, The Solution Design.

You update the Product Blueprint by attaching the approved final designs to The Solution Design section. The blueprint remains your single source of truth, capturing all five pieces of the puzzle and keeping everyone aligned.

You’re ready for Piece 4, The Solution Build.

But there’s something leadership will want to know first. When will this feature go live?

As we saw earlier in this article, you’ll communicate timelines as a part of The Solution Build. And to give leadership accurate timelines, you need to understand how enterprise fintech software actually gets built and released.

Once you understand this, you can communicate realistic timelines to leadership.

You now understand how a mobile app screen gets built.

But before you present that wireframe to leadership, there’s one question you must answer:

Can it actually be built?

Here’s what happens if you skip this step.

You present the wireframe. Leadership loves it. They approve it. You get the green light.

Then you take it to engineering.

And that’s when you discover call routing will take a year to build.

Or the data you need doesn’t exist.

Or three teams have conflicting dependencies.

Now you’re explaining to leadership why something that was approved suddenly can’t launch on time.

This is why you validate the wireframe with technology stakeholders first.

The goal of this call is simple: identify constraints and dependencies.

Let’s look at how to run this meeting.

Who should be on this call?

It’s the same group of technology stakeholders who attended the Product Blueprint Review meeting.

So, you’ll have managers from:

• Mobile app engineering (iOS and Android)
  
• Software architecture
  
• Database engineering
  
• Data engineering
  
• Backend engineering (microservices)
  
• The call center technical team (IVR), since call routing is involved

If anyone wasn’t at the previous meeting, give them enough context separately on a one-on-one call so they’re aligned before attending this session.

You might wonder why managers are involved, and not your core team that will actually build it.

Because your job as a product manager is to protect your core team’s time and help them work more efficiently.

Individual contributors should be building. Managers can represent their teams, surface constraints early, and prevent rework later.

You’ll work closely with your core developers, engineers, and designers after this validation step. We’ll talk more about team structure in an upcoming post.

How to structure the call

Start by setting expectations.

Tell everyone exactly what you’re trying to accomplish:

“We’re going to walk through the low-fi wireframe and identify constraints and dependencies. That’s the goal of this call.”

Simple. Clear.

Now you’re ready to walk through the wireframe. 

Let the designer lead the walkthrough

Don’t walk through the wireframe yourself. Ask your designer to do it.

Why?

Because they’re closer to the design. They understand the interactions. They can explain why elements are placed where they are.

In our case, the designer also walks through both call-routing options.

1) Option A: RM call forwarding (best experience)

Calls go directly to the RM when they’re available. When they’re not, calls are routed to an internal support queue. From the client’s point of view, nothing really changes. It’s still one number. One simple flow.

2) Option B: Call-to-message fallback (simpler)

If the RM doesn’t answer, voicemail directs the client to email the RM through the app. That email is automatically copied to an internal support team that can respond if needed.

You step in only when context is missing.

For example, if they forget to mention that this feature is only for the one million high-net-worth clients (not all ten million banking customers), you clarify that.

Once the walkthrough is complete, open the floor for questions.

Questions fall into two buckets: design questions and business questions.

Design questions sound like this: 

“What happens when the user clicks the call button? Where does it take them?”

The designer answers: 

“It opens the phone’s native dialer. Same for email. It opens the default email app, and the backup team is automatically copied.”

Business questions sound like this: 

“What happens if a relationship manager’s photo isn’t in the database?”

You answer: 

“In an ideal world, every RM has a photo. But if one doesn’t exist, we show a default icon instead.” The designer can show that fallback icon.

Answer the questions. Then move forward.

Identifying constraints

You’ve explained the wireframe. You’ve answered questions. 

Now it’s time to hear from engineering.

You ask: 

“What constraints do we have? What would prevent us from building this?”

And then you listen.

Here’s what might happen.

The mobile app engineering manager asks:

“Do we have a way to identify high-net-worth clients?”

The architect responds:

“We have a ‘net_worth’ flag in the client database to identify these clients in the database. We’re not sending it to the mobile app today, but that’s not a big effort. We can expose it.”

Mobile team says:

“That works.”

Good. No constraint there.

Then the call routing team speaks up:

“Option A isn’t possible right now. It would take us about a year to build that capability. We can add it to the roadmap, but it’s long-term.”

You ask:

“What about Option B?”

They respond:

“Option B is possible. Private banker calls already go through our system. We just update the voicemail message. That’s a configuration change.”

There’s your constraint.

Option A = long-term investment.
Option B = feasible now.

Once you’ve identified constraints, move to dependencies.

Ask each team: 

“What do you need from other teams before you can start building?”

Yes, everyone depends on the architecture diagram. That’s assumed.

But what else?

• Backend engineers and mobile app developers depend on the API contract. Without it, development can’t begin.
• Mobile app developers might depend on IVR routing codes.
• Backend engineers might depend on data engineers exposing specific fields.

Ask each team to call out their dependencies explicitly. This way, there are no surprises later in the development process.

Once constraints and dependencies are clear, explain the next step.

Tell your stakeholders:

“We’ll now schedule a meeting with leadership to get approval on the low-fi wireframe. I’ll be adding all of you to that call.”

In our case, we identified a blocker. Option A would take a year.

So we present both options:

• Option A: Best experience, long timeline, high investment
• Option B: Feasible, faster, lower effort

Leadership decides which direction to take.

In the next post, we’ll walk through how to run that leadership meeting.

In the previous post, we gave our designers the context they needed to create a low-fidelity wireframe.

Here’s the wireframe they built.

It looks simple, right?

An image of a relationship manager (RM). Their name. Their title. And options to email or call.

But it’s just one screen. And showing this screen to one million high-net-worth clients means a lot has to happen behind the scenes.

Multiple technology teams are involved in making this work.

Before we walk this wireframe with our technology stakeholders, we need to understand who those teams are and what they actually do.

Let’s start with the first team.

Mobile app developers

They are also called client-side or front-end app developers.

They turn the low-fi wireframe into a real screen inside the banking app. For this, they use programming languages such as Swift for iPhones and Kotlin for Android phones.

To build the screen, they need the RM’s image, name, and title. All of that data lives in databases.

A database is a place to store data.

Think of it like an Excel file. Each sheet is a table. Each row is a record. Each column is a field.

In our case, one table may store the relationship manager’s name, another may store their title, and another may store their image.

Database engineers ensure this data is accurate, up to date, and stored consistently.

If a relationship manager leaves and a new one joins, these engineers ensure the records are updated correctly across the databases.

But in large enterprise financial services firms, the data is spread across multiple databases. Some in the cloud and some in databases owned by the bank.

The cloud is a collection of remote servers and services owned by companies like Amazon (AWS) or Microsoft (Azure). Banks rent this computing power and storage instead of running their own servers in-house. This is mainly done to save cost and make it easier to add more storage or computing power as the bank grows.

Most modern fintechs have their entire data on the cloud, but that’s not the case for banks. Some banks are hundreds of years old, so they have their own databases that are managed entirely by the bank.

At this point, we need someone to pull all this data from different places and make it usable for the app.

That’s what data engineers do.

Their job is to combine data from multiple places, organize it in a format that the mobile app developers can use, and most importantly, they have to automate this process so it keeps running without manual work.

Let me explain what “keeps running” means.

In our case, relationship managers join, leave, change titles, or update their photos. When any of this happens, the mobile app needs to show these updates immediately. Data engineers set up automated processes that check for updates every few minutes (or even seconds) and pull the latest data from all the different databases.

This automated setup is what’s called a data pipeline. 

Once the data is stitched together and organized, data engineers store it in what’s called a data warehouse or a clean database. Think of this as a well-organized filing cabinet where all the relationship manager information is kept in one place, ready to be used.

Backend engineers (who we’ll talk about next) then build the microservices and APIs that the mobile app talks to.

So what is an API?

An API is how the mobile app requests data and gets a response.

Think of an API like a waiter at a restaurant.

You (the mobile app) sit at a table and want food (data). You don’t go into the kitchen and cook it yourself. Instead, you tell the waiter what you want. The waiter goes to the kitchen (the data warehouse), gets your food, and brings it back to you in a nice, organized way.

In our feature, the mobile app asks the API, “Give me the relationship manager’s name, title, and image for this client.” The API collects that information and sends it back to the mobile app in a structured format.

These APIs are exposed by microservices.

A microservice contains the actual logic and rules. An API is simply how the mobile app talks to it.

Think of a microservice as a small, specialized department in the bank. The API is the door the app uses to ask for data.

This setup exists mainly for two reasons.

Safety and security

If the mobile app talked directly to the database, anyone who figured out how the app works could potentially access all the data in the database.

In our feature, a hacker could try to request not just their own relationship manager’s information, but information about other clients’ relationship managers, or even client account details.

Microservices act as a security checkpoint. When the mobile app asks for the RM’s information, the microservice first checks: Is this user logged in? Are they allowed to see this specific RM’s information? Only after passing these checks does the microservice retrieve the data and return it to the app.

Scalability

Scalability means handling more users without the system breaking.

Imagine 10,000 clients opening the mobile app at the same time, all requesting their relationship manager’s information.

If the mobile app talked directly to the data warehouse, too many requests would hit it at once and slow it down.

Microservices sit in between and manage this traffic. They can temporarily store frequently requested RM details so they don’t call the data warehouse every single time. This protects the data warehouse from being overloaded.

For our feature, multiple microservices might be involved:

• One microservice for identifying if the logged-in customer is a high-net-worth client
• Another for retrieving the relationship manager’s information from the data warehouse

Backend engineers (also called microservices engineers) might build new microservices or modify existing ones to fetch data from the data warehouse.

They apply checks and rules, like the traffic controls you saw above, before returning data to the mobile app.

Software architects

You might be wondering who decides which databases to use, which microservices to build, and how data flows between teams.

That’s the role of software architects.

They look at everything we’ve discussed so far and tie it together. They decide which databases are needed, which microservices to use, and what APIs the backend engineers need to build.

They also define how the mobile app will consume that data. This definition is called the API contract.

What does an API contract look like?

An API contract is written in JSON. It defines exactly what data the mobile app will receive.

Here’s an example for our feature:

{

  “relationshipManager”: {

    “name”: “Jane”,

    “title”: “Senior Relationship Manager”,

    “imageUrl”: “https://bank.com/images/rm/Jane-mitchell.jpg”,

    “email”: “[email protected]”,

    “phone”: “+1-555-0123”,

    “availability”: “available”

  }

}

This contract tells mobile app developers exactly which fields (name, title, imageUrl, etc.) they’ll receive and how that data will be structured.

The contract stays stable even when things change behind the scenes. Today, the RM’s name might come from one database. Tomorrow, it might come from three different systems stitched together. As long as the API returns the same fields, the mobile app doesn’t break.

Database engineers, data engineers, backend engineers, and mobile app developers all rely on the architecture diagram built by software architects to understand what they need to build and how their work fits together.

Without this diagram, teams can’t confidently start their work because dependencies and responsibilities are unclear.

How it all comes together

What started as a simple low-fi wireframe turns out to be anything but simple.

An image. A name. A title. An email and call option.

Behind that one screen sits a chain of decisions, systems, and teams working together.

Database engineers keep the underlying data accurate. Data engineers pull that data together and keep it fresh. Backend engineers build microservices and APIs to control how that data flows. Software architects define the blueprint that holds everything together. Mobile app developers turn all of that into a screen the client can tap.

When you understand this flow, walking a wireframe with technology stakeholders becomes very different. You’re no longer just talking about screens. You’re talking about data sources, contracts, dependencies, and sequencing.

And that’s exactly where the next step begins.

In the next post, we’ll walk through how to run a technical feasibility review using this wireframe and this understanding to turn design intent into something that can actually be built.

You’ve got leadership buy-in on your Product Blueprint.

With that alignment in place, you’re ready to move into the third piece of the puzzle. This is where The Solution Design begins.

The focus now shifts from understanding the problem to designing a solution that teams can align on.

The most effective way to start this phase is with low-fidelity wireframes.

In this post, I’ll walk through what low-fi wireframes are, why they matter, and how to create them with your design team.

What is a low-fidelity wireframe?

A low-fidelity wireframe (often called a low-fi wireframe) is a rough sketch of a website or app interface.

It’s a simplified version of the final product that focuses on functionality rather than visual design.

Low-fi wireframes include only the basic design elements: boxes for images, lines for text, and simple shapes for buttons.

Here’s an example of a low-fi wireframe:

You wouldn’t build a house without blueprints, right? Low-fi wireframes are your blueprints.

Why do low-fi wireframes matter? 

Low-fi wireframes help you communicate your solution clearly before investing in final designs.

They help in three ways.

1) Communicating with engineering

 Wireframes help you understand technical feasibility early.

Before leadership sees final designs, you want to know whether the solution is even possible to build. Engineers can spot technical constraints quickly when reviewing wireframes.

2) Communicating with leadership

Wireframes make alignment easier.

Before leadership sees final designs, you need to know if the solution can be built. Engineers spot technical constraints quickly when reviewing wireframes.

3) Communicating with designers

Wireframes make it easier to iterate.

They’re quick to edit, which allows you to test ideas and change direction before committing to final designs.

Understand your app’s structure and user flows

Before working with designers on wireframes, you need to understand how your app is structured and how users navigate it.

You need to know where the feature you’re building will appear and how it affects existing flows.

We’re building a feature that allows private banking clients to contact their relationship managers. Most of their banking interactions happen through their relationship managers, so the feature needs to be visible as soon as clients open the app.

Based on the data, HNW clients primarily use the mobile app over desktop. So we’re building this feature for mobile first.

On mobile, that means putting the feature on the main screen where it’s immediately visible. You get there by mapping the core flows and understanding where clients start their journeys.

Without a clear understanding of your app’s structure and flows, it’s hard to know where a feature fits.

Before you start wireframing, map out the critical flows of your product.

Ask yourself:

• Where is the entry point for this feature?
• How does it fit into existing screens?
• Does it replace something, or add to what’s already there?

Don’t worry about technical implementation at this stage. Your goal is to understand which screens and flows need to include the feature.

How to design low-fi wireframes with your design team

Step 1: Provide context with the Product Blueprint

Walk your designers through the Product Blueprint.

This gives them full context. They understand who they’re designing for and which customer problems the solution needs to address.

Step 2: Set expectations on fidelity

Tell them this is a low-fi wireframe. It doesn’t need to be detailed.

Step 3: Explain where the feature lives in the app

Show designers where the entry point for the feature will be.

In our case, clients want to contact their relationship manager as soon as they open the app. That places the feature on the main screen, not three levels deep.

Be specific. Show them the existing flow and explain how the feature fits into it.

Step 4: Translate problems into design requirements

Once you’ve shared the blueprint and explained the context, break the problems down into design requirements.

Here are the two most critical problems:

• Unable to reach the relationship manager when they’re away
• No visible or empowered backup ownership

We identified three problems earlier, but these two matter most. They prevent clients from reaching their relationship manager when it matters, which directly drives churn.

Trying to solve everything at once leads to feature creep. It’s better to focus on the core problems first, before adding options that complicate the experience.

With that prioritization in place, we can translate each problem into design requirements.

Problem 1: Unable to reach the relationship manager when they’re away

The wireframe should include:

• A clear option to call or email the relationship manager directly from the app
• An indicator showing whether the relationship manager is available or away
• A photo of the relationship manager so clients know who they’re contacting

Once the problem is translated into design speak, move on to the next one.

Problem 2: No visible or empowered backup ownership

Relationship managers in private banking are supported by an internal support team. This team takes work off the RM’s plate by triaging requests, preparing documentation, and managing follow-ups, so the RM can stay focused on client relationships and advisory work.

From the client’s perspective, this support should remain invisible.

High-net-worth clients expect a single owner for their financial relationship. Exposing internal support teams introduces multiple points of contact and breaks that sense of ownership.

That principle should guide the design.

Clients are already calling and emailing their relationship managers. The app needs to support both options and ensure client requests don’t stall when the RM is unavailable.

For email, messages sent through the app should copy the internal support team, so client requests don’t stall when the RM is away.

Calls need a similar fallback. There are two practical options.

1) Option A: RM call forwarding (best experience)

Calls go directly to the RM when they’re available. When they’re not, calls are routed to an internal support queue.

From the client’s point of view, nothing really changes. It’s still one number and one simple flow.

2) Option B: Call-to-message fallback (simpler)

If the RM doesn’t answer, voicemail directs the client to email the RM through the app. That email is automatically copied to an internal support team that can respond if needed.

In both cases, the client continues to contact the RM. The internal support team remains invisible. 

From problems to wireframes

You’ve walked your designers through the Product Blueprint. You’ve set expectations that the wireframes can be simple. You’ve shown where the feature fits in the app and broken the problems down into clear design requirements.

Now designers can start wireframing.

The wireframes will focus on the two problems driving churn—showing how clients can contact their relationship manager when it matters, while keeping the internal support team invisible.

Once the wireframes are ready, share them with engineering managers and architects. They’ll confirm whether the proposed flows can be built and identify any technical constraints. This review happens before the wireframes go to leadership.

---

Next Article: How a Fintech App Screen Actually Gets Built

At this stage, you’ve documented your Product Blueprint.

You’ve clarified the target audience and the problem. You’ve seen that retired business owners account for 70% of the churn. You’ve prioritized the key issues faced by this audience.

The hard part comes next.

Most product work doesn’t fail because the problem is wrong. It fails because leadership never fully aligns on the problem.

That gap shows up later as new objections to the problem or requests to move in a different direction. When that happens, weeks of design and development work get thrown away.

This erodes trust. Designers and developers lose confidence when their work gets scrapped because of late-stage misalignment.

So how do you avoid that?

By getting leadership aligned on the problems you’re trying to solve before you move on to design.

That alignment happens in the Product Blueprint review meeting.

What’s a Product Blueprint review?

It’s a meeting where leadership reviews your Product Blueprint.

All you’re trying to do is get a green light on the prioritized problems. Once you have that, you can confidently move to the design phase.

By getting a green light early, you prevent misalignment later.

But here’s the thing.

Without structure, these meetings drift. 

Discussions drift into solutions before validating the problem. Leaders question assumptions you thought were settled. Engineering jumps into technical debates too early.

So you need to set expectations upfront and run a focused meeting.

Before that, let’s start with who should be in the room.

Who should be in the Product Blueprint review?

In fintech and financial services companies, I’ve seen the same team set up show up again and again. Especially in domains like wealth, payments, and lending.

Three groups need to be in the room: Business, Product, and Dependency teams.

• Business brings domain knowledge. They also fund the entire project. 
• Product brings the product management lens. They lead everything from discovery to design to development. The group includes product, engineering, and design leadership.
• Dependency teams like marketing and compliance need context early. Without it, they often deprioritize projects.

Let’s break down each one.

Business leadership

This group represents the business line where the problem lives.

In a high-net-worth context, this might include the VP of Wealth or the VP of HNW Banking. Along with leaders who represent relationship managers.

These leaders understand how clients generate value for the business. They’re accountable for revenue and retention and decide whether a problem is worth solving.

Their role in the meeting is to validate whether the problem is real, significant, and aligned with business priorities.

Product leadership

This group applies a product management approach to solve the business problem in a structured way. 

Their responsibility isn’t just to build products. It’s to turn business problems into clear products that drive results.

Leaders from product, design, and engineering should be represented here. Typical roles include AVP of Product, AVP of Design, and AVP of Engineering.

Engineering managers and the architect are also invited to listen in. They’re informed in advance that this isn’t a technical discussion and that the goal is to provide context. A separate session will be scheduled later to discuss technical implementation.

Dependency teams

Dependency teams vary by organization. Marketing and compliance are common examples, but the exact mix depends on how your company operates. 

In our case (a B2C bank), we included marketing and compliance. In a B2B setup, you might also involve sales and customer support. 

The key is to identify the teams that support product delivery.

Here’s what happens when you don’t bring them in early.

These teams often deprioritize initiatives when they don’t understand the value being created. From their perspective, multiple initiatives compete for their limited capacity. And projects that affect fewer users are easy to push aside.

This is where context changes everything.

Let’s say your bank has 10 million retail customers. A feature for 1 million high-net-worth clients may sound small in comparison but the revenue impact is significantly higher.

When dependency teams understand that context early, they prioritize your feature.

Marketing needs this context to plan promotion across digital channels and physical branches. Compliance needs it to engage early and assess regulatory risk with a clear view of business impact.

Bringing these teams in early builds shared understanding and reduces the risk of late-stage pushback or deprioritization.

Now that you know who should be in the room, let’s talk about how to structure the meeting.

How to structure the meeting

Without a clear structure, this meeting will quickly drift away from your goal and slide into long hypothetical discussions that don’t lead to decisions.

You need to keep the audience engaged and encourage interaction, while preventing the conversation from getting derailed. That starts with setting expectations upfront.

Start with objectives and rules of engagement

Share an agenda of what you will cover and set expectations of what you need from them.

Meeting Objectives

1. Walk through the Product Blueprint (target audience and problem)
2. Get a green light on the prioritized problems 
3. Answer questions from leadership 

Rules of Engagement

• Respect the order of the material and avoid jumping ahead
• There will be time for questions and feedback at the end of the presentation
• Leaders should focus feedback on their areas of expertise to keep the discussion productive
• For engineering stakeholders, this meeting provides context only. A separate session will be scheduled for technical discussions
• When giving feedback, clarify whether it is a blocker, a comment, or a suggestion

I usually set expectations with engineering stakeholders before the meeting to avoid drifting into technical discussions. 

This structure keeps the conversation moving, directs feedback to where it’s most useful, and still leaves room for leadership to raise important concerns.

Deep dive into the Product Blueprint

The next step is to deep dive into the Product Blueprint, get buy-in, and align on next steps.

We covered how to build this document in the previous post. In this meeting, you walk through it section by section.

The business problem

Start with the high-level context. Call out the 10% quarter-over-quarter churn and the 100,000 clients leaving.

The Target Audience

Explain who is churning, how you segmented clients and why retired business owners account for 70% of the churn. 

The Customer Problem

Walk through Dave’s journey. Show how retired business owners became snowbirds, how their banking behavior changed, and how they struggled to reach their relationship managers. 

This is where you should spend the most time. That’s because leadership is often far removed from customers’ day-to-day realities and your job is to bridge that gap.

The prioritized problems  

Present the three key issues you identified:

• Unable to reach the relationship manager when they’re away
• No visible or empowered backup ownership
• Clients not identified as high-net-worth when calling from US numbers

Next steps after the Product Blueprint meeting

Once you’ve walked through the blueprint and answered questions, there are two possible outcomes.

If leadership is aligned and you receive a green light, you can move forward with confidence. The next steps are to wireframe solutions using low-fidelity mockups and then present those wireframes to the same group in a follow-up meeting.

If there are open questions or action items, take them away and follow up with the relevant stakeholders. Once those are resolved, you can proceed.

With a clear approval in place, the next two steps are:

• Create low-fidelity mockups
  Simple wireframes that explore solutions to the problems you’ve identified.
• Technical feasibility review
  After the mockups are ready, set up a session with engineering managers and architects to identify technical constraints before presenting them to leadership.
  

The Product Blueprint review meeting is where clarity turns into alignment. 

By the end of the meeting, everyone understands who the product is for, which problems matter most, and why they deserve attention now.

With a green light in place, the path forward is clear. 

You can begin designing low-fidelity mockups to explore solutions and then work with engineering to understand the technical constraints involved.

In the next post, I’ll walk through how to create low-fidelity mockups that bring your solution to life.

By this point, you’ve done the hard work.

You’ve identified who is churning.

You’ve interviewed clients.

You’ve synthesized those interviews and prioritized the problems.

Before you move on to the next piece of the five-part puzzle, there’s one critical step left.

You need to communicate the problems you’ve prioritized to leadership and get buy-in.

To do that, you need to document your learnings in a single place.

That document is what I call the Product Blueprint.

What’s a Product Blueprint?

A Product Blueprint captures all five pieces of the fintech puzzle:

• The Target Audience
• The Customer Problem
• The Solution Design
• The Solution Build
• The Launch and Iteration

It’s a living document because you update it as you move through each piece of the puzzle.

At this stage, you’ve completed The Target Audience and The Customer Problem pieces. The Product Blueprint should reflect that work.

Write the Product Blueprint as a narrative

It’s important to write the Product Blueprint as a story, not as a set of bullets or a dry document.

A narrative forces you to connect the audience, the problem, and the decisions you’ve made. When those connections are weak or missing, gaps become obvious.

Writing your work this way makes it easier to see how the pieces fit together and where they break down.

With that in mind, let’s start building our Product Blueprint.

Start with the business problem

Before you get into each piece of the puzzle, start with a high-level overview of the business problem.

There is always someone in your meetings who doesn’t fully understand the context of the feature you’re working on. Set that context first, then go deeper into each part of your fintech puzzle.

Here’s how you do that:

Churn in the high-net-worth business has increased by 10% quarter over quarter. This means 100,000 clients left in just 90 days out of one million HNW clients.

Once you’ve set the context, move on to the target audience.

The Target Audience

Retired business owners make up 45% of the client base, yet they account for 70% of churn.

The next highest churn comes from passive heirs.

Together, retired business owners and passive heirs make up 70% of the client base.

Most retired business owners fall into the high-net-worth ($500K–$5M) or very high-net-worth ($5M–$50M) segments.

When communicating with business leadership, describe these segments in terms of net worth and wealth. Speak the language they use to get alignment.

Now let’s look at the customer problem..

The Customer Problem 

To understand why these clients churned, you interviewed churned retired business owners, passive heirs, and active clients from both segments.

In total, you interviewed 32 clients, six from each segment.

A clear pattern emerged.

Many retired business owners who churned had become snowbirds over the past year. They were spending extended time in the United States and building a second life there.

That shift changed their banking needs.

They needed to move large sums of money across borders more often. These transactions required approval from their relationship managers. When the manager was unavailable, transactions stalled.

Passive heirs didn’t face the same urgency. Their financial needs were more predictable and less time-sensitive, so they were comfortable waiting when their relationship manager was unavailable. 

While they noticed the absence at times, it did not block critical transactions or trigger immediate churn the way it did for retired business owners.

To make this real, capture the experience through a single customer story.

Here is the journey Dave, a retired business owner, went through.

All you’re doing here is turning interview insights into a customer story.

You’re focusing on the key segment: retired business owners.

If you’re working on a more complex feature with multiple segments, include one journey per segment. 

You won’t see a customer journey for passive heirs because they’re not the key segment churning. Remember, retired business owners account for 70% of the churn, while passive heirs make up a much smaller portion.

Why stories work

Stories make you imagine that you are going through the journey yourself. This builds empathy for the hero of your story – your customer.

People empathize more easily with a single, identifiable person than with large abstract groups. That’s also why stories with vivid characters are remembered better than statistics and data.

Now that you know why stories work, let’s look at how many steps to include.

How many steps should the story have?

When you communicate, your audience can hold only 7±2 items in working memory. Miller’s law confirms this.

This is why you should limit the story to six steps.

The journey map should capture the key moments where customers struggle.  You don’t need to describe every step in detail in the Product Blueprint.

Once the journey is clear, list the prioritized problems.

Based on the interviews, three problems surfaced repeatedly:

1. Unable to reach the relationship manager when they’re away
2. No visible or empowered backup ownership
3. Clients not identified as high-net-worth when calling from US numbers

Remember what you started with?

You identified who is churning.

You interviewed clients.

You synthesized those interviews and prioritized the problems.

Now all of it lives in one place.

The Product Blueprint captures your target audience and the problems they face. It’s not just a deck. It’s your thinking tool. Your guide. Your way to align leadership before moving forward.

In the next post, you’ll learn how to present this blueprint to leadership and get approval to move ahead.

 

Have you ever watched a chef prepare before the kitchen opens?

They don’t cook each dish as orders come in. That would be chaos.

Instead, they do mise en place. Ingredients are chopped. Spices are measured. Everything is laid out before service begins.

Client interviews work the same way.

By now, you’ve debriefed interviews across four groups:

• Churned retired business owners
• Active retired business owners
• Churned passive heirs
• Active passive heirs

In total, that’s roughly 32 interview debriefs if you ran six to eight interviews per segment.

Each debrief is valuable.

But on its own, it’s like an ingredient on the counter.

Nothing useful happens until you organize them. You need to group what you heard, compare it across segments, and look for patterns. Only then can you see which problems are driving churn.

At this point, it’s tempting to jump straight to identifying the problem that caused clients to churn.

That’s risky.

Here’s why.

Risk 1: You focus on a small set of memorable answers

Some issues stand out because clients describe them with emotion and detail.

For example, if a few churned clients spent a lot of time explaining how they weren’t identified as high-net-worth clients when calling from US numbers. As a result, they were routed into regular queues, asked repeated security questions, and treated like regular clients.

That experience is frustrating. 

It sticks in your mind.

But on its own, it doesn’t explain churn.

It’s easy to mistake a vivid story for the root problem.

Risk 2: You prioritize problems that affect only a narrow group  

Some problems show up strongly in a small pocket of the audience but barely appear in others.

For example, younger active passive heirs wanted regular investment news from their relationship managers to feel confident before making decisions. Other segments didn’t raise this at all. 

If you don’t compare problems across segments, you risk prioritizing issues that only affect a small slice of clients.

Risk 3: You miss deeper patterns entirely

The biggest risk is missing patterns that only emerge when interviews are viewed together.

One such pattern emerged around Canada–US banking.

From the client’s perspective, the request was simple. They were moving money between two accounts within the same bank. They had one relationship and expected the bank to handle the complexity behind the scenes.

Inside the bank, things worked differently. The Canadian and US businesses operated as separate regulated entities. The Canadian relationship manager held the full client context. Cross-border transfers triggered additional approvals on the US side.

That split created a gap.

When the relationship manager was unavailable, no one else had the context or authority to approve the transaction.

From the client’s point of view, this fragmentation was invisible but costly. They experienced one bank, yet progress depended on a single person being available in one country.

This pattern only became visible when interviews were examined together.

More importantly, the pattern revealed something deeper. 

Some problems aren’t surface-level service issues. They stem from how the business operates and how responsibility is divided across teams and borders. 

Understanding those problems takes time. It requires conversations with senior relationship managers, operations teams, and compliance partners. This is not something to rush.

Because of these risks, you need to step back and look across all 32 interview debriefs and all four segments.

Here’s how to do that in three steps.

Step 1: Group problems within each client segment

Start by reviewing interview debriefs one segment at a time. For each segment, list the problems clients mentioned. Name each problem clearly and specifically.

Avoid vague labels like “communication issues.”

Instead, use language such as: “Clients can’t identify a backup relationship manager when the primary is unavailable.”

As you review the debriefs, note which problems appear repeatedly.

If five churned clients and seven active clients mention the same issue, that’s twelve mentions of the same problem. That frequency matters.

Group similar problems together, even when clients use different words. 

One client might say: “I didn’t know who to call when my manager was on vacation.” 

Another might say: “There’s no backup system when my relationship manager is away.” 

That’s the same problem.

To make this concrete, here are three example issues that appeared repeatedly in churned retired business owner interviews. This is not an exhaustive list. These are included only to illustrate the process.

• Unable to reach the relationship manager when they were away from work
  
• No visible backup when the manager was unavailable
• Clients not identified as high-net-worth when calling from US numbers

Step 2: Map problems across client segments

Create a simple matrix. 

List problems on one axis and client segments on the other. Mark where each problem appears.

Problem–Segment Matrix (example)

This matrix reveals critical patterns.

Some problems affect everyone. Invisible backup coverage appeared across all four segments.

Other problems are segment-specific. The phone recognition issue appeared only among retired business owners. 

Why?

Because they travel frequently, call from US numbers, and manage cross-border transactions. 

Passive heirs didn’t face this problem. Their transactions are simpler and more predictable.

You only see this by mapping problems across segments.

Step 3: Prioritize problems based on client outcomes

Now look at the matrix and ask a different question.

What are clients actually trying to do?

Across every segment, one outcome stands out: clients want to reach their relationship manager.

Sometimes to approve a transaction. 

Sometimes to resolve uncertainty. 

Sometimes just for reassurance.

Everything else depends on that. 

When the relationship manager was unavailable, authority disappeared. Context was lost. Progress stalled.

Relationship managers understand a client’s whole financial picture: assets, liabilities, family dynamics, estate plans and risk tolerance.

If clients can’t reach their manager or don’t know who to reach when the manager is unavailable, the core promise of private banking collapses.

You only know this by understanding the domain.

Without it, it’s easy to prioritize the wrong fixes. You might improve call routing or add a fancy in-app feature. Neither solves the real issue.

That’s why regulated domains require product managers with a deep understanding of the domain. You can’t prioritize problems correctly without it.  

Using the matrix and the outcomes clients were trying to achieve, the priorities become clear.

1) Unable to reach the relationship manager when they’re away

This blocks the primary action clients need to take.

2) No visible or empowered backup ownership

Backup coverage existed, but clients couldn’t see it. No one had clear authority to act.

3) Not identified as high-net-worth when calling from US numbers

This issue affects retired business owners most and is closely tied to the first two problems. If clients can easily contact their relationship manager or a backup with decision-making power, the issue mostly disappears. That’s why it comes third. 

Some of these problems may be solved together. But solutions come later, in the design phase.

For now, the goal is simple.

You need clarity on what to solve first, what to solve next, and what can wait.

At the start of this article, we compared interview debriefs to a kitchen before service.

All the ingredients were there. Nothing was usable yet.

You had 32 debriefs across four segments.

But stopping there would have been dangerous.

Without comparison…

You risk chasing memorable stories.

You risk prioritizing narrow issues.

You risk missing deeper patterns.

So you stepped back.

You grouped problems within each segment.

You mapped them across segments.

You prioritized them based on real client outcomes.

Now the picture is clear.

You know which problems matter most and which can wait.

The next step is to capture that clarity in one place—so it doesn’t live only in your head or your notes.

That’s where the Product Blueprint comes in.

You’ve interviewed churned retired business owners, passive heirs and active clients from both segments.

You now have hours of recordings and pages of notes.

The next step is to turn those conversations into insights.

This article shows you how to make sense of individual interviews. How to break down each conversation, extract what matters, and decide whether to keep going or stop.

Let’s start with what to do right after each interview.

Transcribe and review each interview

After each interview, transcribe the recording using ChatGPT or any transcription tool.

Print the transcript.

Then read it with a pen in hand. Highlight key moments and mark anything that stands out. 

Why paper? 

Because screens make you skim but paper forces you to slow down and think.

As you read, you’re trying to answer five questions:

1. What outcome was the client trying to achieve?
2. Why were they trying to achieve it?
3. Why couldn’t they achieve it?
4. What challenges did they face along the way?
5. What alternatives did they do instead?

These questions help you uncover the core problem. The actual breakdown in the client’s experience.

Let’s apply them to the retired business owner interview.

Example: Debriefing the retired business owner interview

1) What outcome was the client trying to achieve?

The client needed to transfer large sums of money from Canada to the US on a regular basis.

2) Why were they trying to achieve it?

 They had became a snowbird. They were spending winters in the US, setting up a second home, buying a car and managing major cross-border expenses.

3) Why couldn’t they achieve it?

 Their relationship manager was unavailable. Large transfers required the manager’s approval due to transaction limits and cross-border rules. Without that approval, the transaction couldn’t proceed.

4) What challenges did they face?

The client called the general support line from a US number. The system didn’t recognize them as high-net-worth and routed them into the regular queue.

After multiple security checks, they reached the high-net-worth support team. But that team couldn’t approve the transfer either. Only the relationship manager had the authority.

There was no documented backup relationship manager. No one owned the client’s context in the manager’s absence.

5) What did they do instead?

The client used another bank to transfer the funds.

This is how you debrief each interview. 

Evaluate the interview process itself

Before you schedule the next interview, pause and ask one question:

Should you keep going with the same questions, adjust them, or stop interviewing altogether?

There are three valid options.

Option 1: Don’t change anything

This is common early on, when you’re still learning how a segment thinks.

If the first few retired business owners give very different accounts of how they handle transactions, keep the script as is. You need more interviews to find the common thread.

Don’t tweak the questions yet. You don’t have enough data to see patterns.

Option 2: Adjust your questions

This happens when you start hearing the same answer again and again for a particular question.

A question has done its job. It’s no longer revealing anything new.

For example, if every retired business owner describes the baseline relationship in the same way:

“The relationship manager was always available.”

At that point, you don’t need to keep asking about the baseline. Update the script and spend more time on what changed and why the relationship broke down.

Make this adjustment only after the same answer repeats across several interviews.

Option 3: Stop interviewing

Sometimes you reach saturation.

You hear the same core problem from four or five clients in a row. The story doesn’t change. The challenges stay the same.

For example, you might hear the same story from four retired business owners. They can’t reach their relationship manager. There’s no visible backup. Transactions stall. At that point, interviews five and six are unlikely to reveal anything different.

That’s your signal to stop.

At this point, the work shifts from interviewing to synthesis.

What comes next

You’ve debriefed each interview and decided whether to keep going, adjust, or stop.

Now you have a stack of debriefs. One for each interview.

The next step is to step back and look for patterns across all of them.

That’s Part 2.

In the next article, you’ll learn how to find common problems across interviews, separate symptoms from root causes, and decide which problems actually deserve attention.

For now, focus on doing the basics well.

Debrief each interview carefully.

Answer the five questions.

Evaluate your process.

Get this right and everything that follows becomes much easier.

 

Have you ever been to a good therapy session?

If you have, you know the therapist doesn’t start by asking about your deep childhood traumas. 

That would be insane.  

Instead, they build trust first. They talk about the weather. Maybe ask about your day.

Then they work to understand your context. What’s happening in your life. What’s changed recently. What patterns are emerging.

Only after this groundwork do they dive into your problems.

Why?

Because without trust, people give surface-level answers. 

Without context, problems get misdiagnosed. 

Without safety, people hold back their real issues.

Client interviews work the same way.

Build trust first. 

Understand the context next. 

Then create space for deep sharing where clients can open up without feeling judged.

This structure helps you understand the problem that caused clients to leave in their own words. 

You’ll use this approach when interviewing the right clients: churned retired business owners, passive heirs, and the same segments among active clients.

In this article, I’ll walk through an interview with a churned retired business owner. The same principles apply to the other segments.

Before getting into the interview, it helps to answer one simple question.

Do you need an interview script?

Yes. You need a script.

You should have two core scripts: one for churned clients and one for current clients. The script for current clients should then be tailored to each persona.

That said, don’t treat the script like a checklist. The goal isn’t to get through questions. It’s to understand the problem in the client’s own words.

The script also serves a practical purpose. It can be reviewed by compliance to ensure you don’t ask questions that create legal risk.

With that in place, the interview itself takes about 45 minutes and is divided into three phases.

Let’s walk through each one.

Phase 1: Building trust (5-10 minutes)

This phase is about establishing rapport.

Start with a few minutes of small talk. Ask about their day or weekend plans. Keep it light.

Remember, churned clients expect a sales pitch. Many are frustrated before the call even begins. Address that upfront.

What to say: 

“Thanks for the time. I know you’ve moved your accounts, and I’m not trying to win you back. I’m a Product Manager. My only job is to understand where we failed you so we can improve how we serve clients in similar situations. You have the perspective we need.”

Next, ask for permission to record the interview. Be clear that the recording is for internal research only.

What to say: 

“I’d like to record the interview to focus on listening instead of taking notes. The recording is for the internal product research only and won’t be shared with sales or marketing. Is that OK?”

Phase 2: Understanding the client’s context (10 minutes)

In therapy, this is where the conversation starts broad.

The therapist asks about routines, recent changes, and what life looked like before things shifted.

Do the same here.

Start by establishing the baseline. Ask the client to recall a time when things were working well.

What to say: 

“Think back a few months when things were smooth. Walk me through a typical week working with us.”

What you’ll hear: 

The relationship manager was always available and acted as a trusted owner of the client’s entire financial life. They had a deep understanding of the client’s assets, liabilities, family context, and long-term goals.

Next, identify the shift.

What to say: 

“What changed? When did the experience start to feel different?”

What you’ll hear: 

Interactions with the relationship manager became more frequent. When the manager was away, the client couldn’t reach anyone. They didn’t know who the backup was or whether one existed.

This wasn’t an issue before as transactions were infrequent and predictable. Waiting a few days felt fine.

Now it didn’t.

One critical rule here: don’t correct the client.

If they say, “The bank has no backup for my relationship manager,” and you know a backup team exists, don’t challenge them. 

Focus on the client’s reality – even if it’s incorrect. 

This is how you uncover the real issue: not that a backup didn’t exist, but that it was invisible to the client.

Now narrow in on why they were trying to contact their manager more frequently.

What to say: 

“Tell me more about why you needed to reach your relationship manager more often.”

What you’ll hear: 

Last year, the client became a snowbird.  They started spending winters in the US. That shift changed everything.

Before, banking was simple. Transactions were infrequent and predictable.

Now they were building a second life. Setting up a second home. Buying a US car. Handling major expenses across the border. This meant moving a lot of money between Canada and the US regularly.

But there was a catch.

Large transfers required relationship-manager approval due to bank limits and cross-border regulations.

Suddenly, reaching the manager wasn’t a convenience. 

It was critical.

The snowbird insight is key. When insights like this emerge, follow the thread. Set the script aside and explore it fully. This is often where the most valuable discoveries surface.

Phase 3: Deep sharing (25-30 minutes)

In a therapy session, this is when the client feels safe to discuss specific moments where the relationship broke down.

This phase uncovers the core problem that caused churn.  

Spend 25-30 minutes here, as this is where the most valuable insights come from.

Dig deeper into their challenges with higher transactions.

What to say: 

“When you realized your relationship manager was away, how did you handle that large transaction from Canada to the US? Walk me through it.”

What you’ll hear: 

The client called the general support line.

Usually, this is straightforward. When they call from their Canadian number, the system recognizes them instantly. They get fast-tracked to the high-net-worth team with zero wait time.

But this time, they were calling from a US number. The system didn’t recognize them. It treated them like a regular client.

General support line agents had to ask multiple security questions to validate their status before routing them to the high-net-worth support team.

What to say: 

“What happened next? Did the high-net-worth support team assist you with the transactions?”

What you’ll hear:

The support team couldn’t approve the transfer.

Due to cross-border compliance rules, only the relationship manager could approve high-value transactions. They were the only person with full visibility into the client’s risk profile and history.

The support team looked for the manager’s backup. But no formal backup was on file for this client.

Since the manager was away, the authority to sign off couldn’t be transferred to anyone else.

The client was told to wait for the manager to return to work.

Eventually, the case was escalated to senior management. But that added more reviews and more delay.

What to say: 

“I’m sorry to hear this. Since you couldn’t wait, how did you move your funds?”

What you’ll hear: 

The client used another bank with operations in both Canada and the US. 

What this interview revealed

Earlier, you learned that retired business owners value ownership.

They want one person who carries their financial context and takes responsibility over time.

This interview shows what happens when that ownership disappears.

When the relationship manager was unavailable, trust eroded. Backup existed, but the client couldn’t see it. Support teams were helpful, but lacked authority.

The issue wasn’t transaction limits.

It wasn’t a missing process.

It was the loss of personal accountability.

These clients don’t just need access. They need someone who carries their context and can act when it matters.

When continuity broke, the relationship collapsed.

And with it, the bank lost advisory fees, referrals, family relationships, and years of future value.

---

Next Article: How to Extract Insights from Client Interviews (Part 1) – Making Sense of Each Interview

Previous Article: How To Identify Which Clients Are Churning (The Target Audience)