Skip to content
Marcus Gonzalez

Advisor Mobile → Unity

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 investment1, and led to the service architecture that became Unity.

Fig. 00 · Redirect

Research changed the investment and the direction.

  1. The committed app

    Chase budgeted ~$5M and projected a $20M return before researching the need.

    committed before discovery

  2. Research into strategy · co-led
    • Salesforce usage analytics
    • 12 field interviews, in person
    • ranked mobile tasks + experience architecture
  3. Product leadership decides

    A new basis for the investment, drawn from the research.

What the decision set in motion
  1. Canceled — ~$5M redirectedProduct leadership canceled the standalone build and redirected ~$5M.
  2. Seeded — UnityThe unifying architecture that became Unity.
  3. ExpandedFollow-on strategy for the next-generation employee experience.
Co-led research and strategy; product leadership made the cancellation and investment decisions.Stop the app · define the strategy · connect the work
A committed ~$5M app feeds the co-led research and strategy, which gives product leadership a new basis for the investment; that decision fans into three outcomes: the standalone app stopped and its budget redirected, the service architecture that became Unity seeded, and a follow-on employee-experience strategy expanded.
Context01

Chase budgeted ~$5M and projected a $20M return2 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.

Fig. 01 · Order of operations

Funding came first, understanding second.

  1. 01

    The precedent

    Salesforce's mobile app reached advisors' phones. Adoption stayed low.

  2. 02

    The commitment

    Funding approved and returns projected before anyone researched the need.

  3. 03

    The ask to design

    Define what to build.

  4. 04

    The need, understood

    Established only once research began, after the money was committed.

The sequence is the point; the need was understood only once research began.Funding first, understanding second
The order of operations drawn as a sequence: a precedent of low adoption, then funding approved and a return projected, then the ask to design, and only at the end, drawn as an open stage, the need finally understood.
Problem02

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.

Fig. 02 · Fork

Two hypotheses, three different investments.

Earlier mobile apps · low adoption

Hypothesis 1 · access

Authentication was cumbersome, and sessions expired quickly.

implies: fix access to the existing app

Hypothesis 2 · relevance

The available mobile capabilities did not match the tasks advisors needed away from their desks.

implies: change which tasks belong on mobile

First decide which problem the investment has to solve.

Access · task choice · standalone appDecide the problem before deciding the build
Low adoption forks into two candidate causes: an access problem, which would imply fixing access to the existing app, and a relevance problem, which would imply changing which tasks belong on mobile. The two meet at one decision the evidence has to settle first: which problem the investment should solve.
Research03

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.

Fig. 03 · Evidence

Research narrowed the investment from an app to specific mobile moments.

Access · where existing tools broke down

Usage data and interviews revealed why existing mobile tools were difficult to use alongside other systems.

  • cumbersome authentication · short sessions
  • no copy and paste between work apps
Need · when mobile action mattered

Field interviews identified the specific tasks advisors needed in the field—not the full desktop toolset.

  • 10-minute open-house setup1
  • 20+ applications per workflow

Prioritize mobile moments, then connect the services behind them.

1

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.

Salesforce usage analytics and 12 field interviews3.Evidence → moments → connected services
Two lanes of evidence converge: behavioral data and interviews showing where existing tools broke down, and field interviews showing when mobile action actually mattered. Together they point to one direction: prioritize the mobile moments, then connect the services behind them.

The mobile need was narrow, but the work behind it was not. Supporting selected tasks meant connecting the systems advisors already used.

Decisions04

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.

Fig. 04 · Framework

Research became a decision framework.

Advisor decision model

When does an advisor need to act away from a desk?

Impact framework
  • structured customer-impact options
  • structured advisor-impact options
  • structured loan-lifecycle options
RankMobile tasks in priority order.
  1. StructureTask-based experience architecture.
  2. StoryboardMobile experience and supporting services.
The framework quantified customer, advisor, and loan-lifecycle impact.Moment → impact → task and service architecture
A pipeline from a mental model of when an advisor needs to act away from a desk, into the impact framework that scored each task on customer, advisor, and loan-lifecycle impact, into the ranking business partners made, and out to the task-based architecture and the vision storyboard.

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 applications4. That gave product leadership a broader direction for the investment. Leadership canceled the app and redirected its ~$5M budget.

Fig. 05 · Fragmentation

From mobile tasks to the service architecture behind them.

20+ applications · selected mobile tasks depend on services across them

Shared services behind the mobile experience1

The unifying architecture the tasks required — the origin of Unity.

1

The storyboard still showed a standalone mobile experience. Its architectural contribution was showing how the services behind each task needed to connect.

Representative field, not a tally; the 20+ figure lives in the running text.Unity's origin
A dense field of application squares, standing for the many systems a single advisor workflow crosses, resolves into one shared-services layer: the unifying architecture the selected mobile tasks required, and the origin of Unity.
Status05

The standalone app stopped, but the strategy continued. Other teams are building Unity, and targeted mobile workflows remain planned within its responsive architecture.

Scope
I co-led the research and strategy with the Home Lending research lead, partnered with product leadership, and conceived the unifying architecture.
In motion
The work expanded into follow-on strategy for the next-generation employee experience, and other teams are building Unity.
Trajectory
Targeted mobile workflows remain planned within Unity. The mobile-responsive architecture will connect those workflows to the shared services behind the systems advisors already use.
Measuring
When mobile workflows ship, the team will measure advisor adoption against the previous tool's low-use baseline.
Evidence and sources

1~$5M — was the budget for the standalone app when product leadership canceled it and redirected the investment.

2$20M return — Chase projected a $20M return, measured as net present value, before research established what advisors needed.

312 field interviews — The team conducted 12 in-person interviews with Home Lending Advisors alongside Salesforce usage analysis.

420+ applications — Advisors mixed and matched more than 20 applications across their workflows.

Contact

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.

marcus@marcusjg.comLinkedIn

Next case →

Agentic Loan Origination

The threadThe 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.