Designers have built the final screen, and leadership has approved it. The software architect created the architecture diagram and defined the API contract. The contract defines what data the mobile app can request and what the backend must return.
This marks the beginning of Piece 4 of the fintech puzzle: The Solution Build.
At this stage, you share feature delivery timelines with leadership and begin building the mobile app screen.
But before development starts, you must define how you will measure success. In other words, you must define your metrics.
It’s pretty simple because you’ve done most of the heavy lifting during the first three pieces of the fintech puzzle. All you have to do now is turn that work into metrics.
Here’s what you know from the Product Blueprint
Churn in the high-net-worth division increased by 10% quarter over quarter. In a Canadian bank serving 1 million HNW clients, that means roughly 100,000 clients leaving within 90 days.
Seventy percent of that churn came from retired business owners.
Many had recently become Canadian snowbirds, spending winters in the US in places like Florida or Arizona. They were building a second life, setting up a second home, and managing large cross-border expenses. That required moving significant funds between Canada and the US.
Large transfers required approval from a relationship manager (RM) due to bank limits and cross-border regulations.
When the RM was unavailable, no backup relationship manager was officially assigned. The support team lacked the authority to approve the transfer and told the client to wait. The client did not wait and moved the money through another bank.
To address this problem, you designed a solution.

Primary metric: Did clients successfully reach their RM?
The core outcome high-net-worth clients want is access to their relationship manager when they need help. This was especially critical for traveling retired business owners who needed to transfer funds.
Your first metric measures whether clients achieved that outcome:
% of HNW clients who successfully reached their RM through the app
“Successfully reached” means the client sent an email or initiated a call through the app.
If 150,000 out of 1,000,000 clients contacted their RM this month, the contact rate is 15%.
This metric tells you whether clients can reach their RM when they need help.
Response metric: Did clients receive timely help?
Reaching the RM is not enough. Clients need timely responses from the RM or the backup team.
Leadership defines response expectations in Service Level Agreements (SLAs). For example, emails must be answered within 2 hours and calls must be returned within 10 minutes.
So you measure:
% of initiated contacts responded to within the SLA
If clients initiated 10,000 contacts and the bank responded to 8,200 within the SLA window, the response rate is 82%.
Track escalations
From your interviews, you know what happens when RMs are unreachable. Clients contact the general support line because they don’t know who the backup relationship manager is.
So you track:
% of clients who called general support because they could not reach their RM
A high escalation rate signals friction in the workflow, even if the primary contact metric looks strong.
Churn and its early indicator
Churn is the ultimate business metric, but it is also a lagging indicator. By the time churn appears in your reports, the client has already left the bank.
This happens because high-net-worth clients rarely close their accounts immediately. They typically move their assets gradually before making the final decision to leave. As a result, churn data alone does not tell you early enough whether your feature is working.
To detect changes sooner, you track an early indicator of churn.
In high-net-worth banking, the most reliable early signal is net asset outflow. When clients begin losing trust in the bank, they usually start by transferring part of their assets elsewhere. They may move funds to another institution while keeping their account open for some time.
For that reason, you closely monitor the percentage change in net asset outflow per client.
% change in net asset outflow per client
This metric measures how much money clients move out of the bank relative to their historical baseline. For example, if a client typically keeps $2 million with the bank and transfers out $500,000, that represents a 25% asset outflow.
When asset outflows begin to decrease after a feature launch, it suggests that fewer clients are starting the process of leaving the bank. In other words, trust is stabilizing.
Alongside this early signal, you still track churn itself.
% churn
This measures the percentage of clients who actually close their accounts during a given period. For example, if 100 out of 1,000,000 clients close their accounts in a month, the churn rate is 0.01%.
Because churn reflects the final stage of client departure, it takes longer to change.
When asset outflows decline first, and churn later decreases, it provides strong evidence that the feature is addressing the root cause of the problem.
Apply segmentation and travel filters
You track all the metrics above for all high-net-worth clients, and then do the same for retired business owners and passive heirs. These two segments represent nearly 70% of your client base.
Within each segment, you apply a travel filter. So you end up with these views:
- All high-net-worth clients
- retired business owners (domestic)
- retired business owners (traveling)
- passive heirs (domestic)
- passive heirs (traveling)
If 90% of all HNW clients reach their RM but only 62% of traveling retired business owners do, the core problem remains unsolved for the key segment driving churn.
Where does the data come from?
In most banks, the data required for these metrics lives across multiple systems.
The primary contact metric comes from mobile app event tracking. The response metric comes from the CRM system that relationship managers use to manage client requests. Asset outflow data comes from the bank’s transaction systems.
To combine these sources, you collaborate with technology and analytics stakeholders. The technology team integrates the data into a centralized data warehouse, while the analytics team builds dashboards that present all metrics in one place. This allows leadership to monitor the feature’s performance without relying on multiple reports.
Before presenting the metrics framework to leadership, confirm how each metric will be captured. Some metrics may already exist in current systems, while others may require additional work to collect or integrate the data.
For example, the mobile app may need new event tracking to capture when a client taps the call or email button. The CRM system may need additional tags to record whether a request was escalated to general support. Travel indicators may require capturing login IP locations or cross-border transaction flags.
Each of these changes requires coordination with engineering and analytics teams. If new tracking or integrations are required, that work must be scoped and added to the development plan before delivery timelines are communicated to leadership.
Leadership review
Once you validate the metrics with technology, walk leadership through the full measurement plan. Present it the same way you presented the Product Blueprint and the wireframes.
Explain what each metric measures, why it matters, how it will be tracked and answer any questions they have.
Only after you secure their buy-in should you move to the next step of the solution build: estimating delivery timelines.
From Product Blueprint to measurable metrics
The core problem was simple. Clients couldn’t reliably reach their RM. So you measured the percentage of HNW clients who successfully contacted their RM through the app.
But reaching out isn’t enough. If no one responds, the problem still exists. So you measured the percentage of contacts that responded within the SLA.
When clients can’t reach their RM, they escalate to general support. So you tracked the percentage of clients calling general support because they couldn’t reach their RM.
And since clients move assets before they formally churn, you monitored asset outflow as an early indicator and tracked churn rates to see if fewer clients were leaving the bank.
That’s how metrics are defined. Not by brainstorming metrics, but by translating the Product Blueprint into measurable outcomes that tie directly to the customer problem and the business impact.