Product leadership canceled the ~$5M app after research changed the answer.
Chase funded an advisor mobile app before understanding the need. The research I co-led identified which work belonged on mobile, gave product leadership a new basis for the investment, and led to the service architecture that became Unity.
Research changed the investment and the direction.
Chase budgeted ~$5M and projected a $20M return before researching the need.
A new basis for the investment, drawn from the research.
- Product leadership canceled the standalone build and redirected ~$5M.
- The unifying architecture that became Unity.
- Follow-on strategy for the next-generation employee experience.
Chase budgeted ~$5M and projected a $20M return before research established what advisors needed.
Home Lending Advisors sell mortgages directly to customers. Chase asked design to define what the funded app should be.
Funding came first, understanding second.
- 01
Salesforce's mobile app reached advisors' phones. Adoption stayed low.
- 02
Funding approved and returns projected before anyone researched the need.
- 03
Define what to build.
- 04
Established only once research began, after the money was committed.
Earlier mobile apps had low adoption, yet Chase was ready to begin designing another without a clear direction. Moving forward would commit the investment before the team understood what advisors needed on the go.
We advocated for research before design began because two explanations fit the low adoption. Access was one: authentication was cumbersome, sessions expired quickly, and advisors could not copy and paste between work apps. Relevance was the other: the available mobile tasks did not match the work advisors needed in the field, and completing that work often required several systems. Each explanation pointed to a different investment, so we had to determine which problem to solve before deciding what to build.
Two hypotheses, three different investments.
Authentication was cumbersome, and sessions expired quickly.
The available mobile capabilities did not match the tasks advisors needed away from their desks.
First decide which problem the investment has to solve.
Research gave the investment a direction: support the moments when advisors needed to act away from a desk, and connect the systems behind that work.
Research narrowed the investment from an app to specific mobile moments.
Usage data and interviews revealed why existing mobile tools were difficult to use alongside other systems.
Field interviews identified the specific tasks advisors needed in the field—not the full desktop toolset.
Prioritize mobile moments, then connect the services behind them.
At an open house, an advisor spent 10 minutes connecting a laptop, personal hotspot, and VPN. The immediate need was access to a specific task, not the full desktop toolset on a phone.
The mobile need was narrow, but the work behind it was not. Supporting selected tasks meant connecting the systems advisors already used.
I built a framework to rank mobile tasks by impact, then created a storyboard that showed the services behind them and defined the architecture that became Unity.
Quantify what deserves mobile access
I mapped the moments advisors needed to act outside normal work settings, then created a framework that let business partners assess each task's impact on the customer, the advisor, and the loan lifecycle. They used the results to rank which moments justified mobile investment.
Connect the experience to the services behind it
The rankings set priorities but did not show what each task required. I turned the highest-value moments into a task architecture and storyboard that connected the mobile experience to its supporting services.
Research became a decision framework.
When does an advisor need to act away from a desk?
- structured customer-impact options
- structured advisor-impact options
- structured loan-lifecycle options
- Task-based experience architecture.
- Mobile experience and supporting services.
Show what the app could not solve alone
The storyboard still depicted a standalone mobile experience, but its service map exposed a larger dependency: the selected tasks crossed more than 20 applications. That gave product leadership a broader direction for the investment. Leadership canceled the app and redirected its ~$5M budget.
From mobile tasks to the service architecture behind them.
The unifying architecture the tasks required — the origin of Unity.
The storyboard still showed a standalone mobile experience. Its architectural contribution was showing how the services behind each task needed to connect.
The standalone app stopped and the strategy continued: product leadership redirected the ~$5M, other teams are building Unity, and targeted mobile workflows remain planned inside its responsive architecture, connected to the services advisors already use.
What I would do differently: bring the field evidence to product leadership as a decision, not a finding. The research was clear months before the cancellation; framing it as the choice between a $5M app and a $20M projection would have shortened the path from what we learned to what changed.
How do you decide what a product should be before you've spent the budget proving it? If that question is on your desk, let's talk.
Agentic Loan OriginationThe same commitment to evidence before architecture shaped the flagship. The agentic origination rebuild began with 46 observed hours of loan work before its screens took shape.