PM Portfolio › Case 05 › Bank Tracker · Tool Evolution
← Back to portfolio
Case Study 05 · Bank Tracker Evolution · 2026

Bank Tracker Evolution: from Kantata to a leadership live dashboard

A working walkthrough of how the Ripple Treasury Bank Implementation Tracker evolved across five tools in seven months. Each stage shows what was in the artifact, why it stopped working, and what got swapped in next. Read this as documentation for any PM facing a tracker that has outgrown its tool.

Owner · Jeffrey Lu-Shao Span · Sep 2025 — May 2026 Scale · 720 tasks · 48 banks · 23 APIs OKR · 12 Group B banks live by Jun 30

The five-stage path, at a glance

01
The Problem
Master plan
Kantata · 720 tasks
02
The Insight
Bank tracker
Excel · per-bank
03
The Build
Ticket truth
Excel · Jira-anchored
04
The Outcome
Live dashboard
HTML · AI-built
05
The Compounding
Leadership deck
PPTX · 8 slides
01
The Problem · Master plan in Kantata

Kantata Ripple-IMP Project Plan

The implementation kicked off inside Kantata, the standard project management tool used by the Implementation team. 720 tasks across phases, all assigned and tracked in one workspace.

Kantata Ripple-IMP Project Plan table view
Kantata · tasks view · Sep 2025 — Apr 2026

What was in it

  • 720 tasks · 11 phases · milestone and substory hierarchy
  • Standard fields: assignee, start, due, % done, status, dependencies
  • Source export: Kantata Ripple-IMP Project Plan.csv

Why it stopped working

  • Kantata's task hierarchy didn't flex to per-bank tracking. Bank connectivity has its own 5-step pattern (Pre-Enroll → Enroll → Setup → Test → Cutover) for each bank, and Kantata flattened them all into one long list.
  • Client-side stakeholders couldn't see Kantata. External visibility blocked.
  • Status fields too coarse. "In Progress" hid which bank was actually blocked.

The swap-in trigger

When the client requested a weekly bank-by-bank status, the Kantata view couldn't produce it in under an hour of filtering. That was the signal.

Lesson from Stage 1
A master plan is not a status report. The tool that's right for sequencing tasks is rarely the same tool that's right for reporting on them.
02
The Insight · Per-bank Excel rebuild

Ripple Labs Imp Bank Tracker · 2026.xlsx

Rebuilt the tracker in Excel with the bank as the row, not the task. 48 banks across Reporting and Payments, 7 tabs, P1 to P4 priority bands, owner stamps per phase.

Excel Bank Tracker Master tab
Excel · Master tab · 48 banks · 7 tabs

What changed in the model

  • Bank-as-row, not task-as-row. Each bank had a phase, status, connection type, environment.
  • Separate tabs for Reporting, Payments, Acme middleware, Priority, and an Example for new entries.
  • Manual color rules for status (Complete / In Progress / Blocked / Not Started).

Why this still wasn't enough

  • Excel is not digestible for leadership. Too wide to read on a phone, no quick "what's at risk this week" view.
  • Status was self-reported by PM. Engineering and Product worked tickets in Jira, so the Excel was always behind reality.
  • No single chart that answered "How many banks live? How many in flight?" without manual pivots.

The swap-in trigger

A leadership review asked "how many APIs are live right now?" and the PM had to spend 30 minutes reconciling Excel against Jira to answer. Mismatch found. Trust dropped.

Lesson from Stage 2
If two systems hold the same data, the one closer to the work wins. Jira owned the API builds, so the tracker had to bend to Jira, not the other way around.
03
The Build · Jira-anchored ticket truth

Bank_API_Tracker.xlsx · Jira-anchored

Stopped fighting Jira. Pulled live ticket exports into the tracker and built summaries the technical teams could see themselves in. The tracker became a view onto Jira instead of a parallel system.

Bank_API_Tracker Jira export view
Excel · Jira export · 107 tickets · staleness pivots

What changed in the model

  • Ticket-level rows: GTI-3956 and friends, with Status, Days in Status, Assignee, Reporter, Priority, Client.
  • Five summary tabs: by Status, Assignee, Client, API Type, Staleness Bucket.
  • Staleness became its own dimension. ≤ 7 days is healthy, 30+ is a red flag, 60+ is an escalation.

What this fixed

  • PM, Engineering, and Product looking at the same fields. One vocabulary for status.
  • Stale tickets surfaced automatically instead of being noticed in retros.
  • Assignee summary exposed an Unassigned bucket (77%) that nobody had been flagging.

What it still couldn't do

  • Still an Excel file. Leadership won't open Excel on a phone mid-meeting.
  • Static snapshot. The export date in the title became part of the filename: Jira export 2026-04-29.
  • No clear "the OKR is X, we are at Y" view at the top.
Lesson from Stage 3
The data was finally right. The format was still wrong. A spreadsheet is good for analysts. Leadership needs a dashboard.
04
The Outcome · AI-built live dashboard

2026-05-01 Ripple Bank Tracker v3 · live HTML

Took the Excel as input, asked Claude to build a single-page HTML dashboard with an OKR banner, escalation banner, and a Tracker-vs-Jira gap panel. Deployed via Google Apps Script with a go/ short link so anyone at Ripple could open it.

HTML Bank Tracker Dashboard v3
HTML · single-page dashboard · deployed via Google Apps Script · go/ short link

What's in the dashboard

  • OKR banner pinned to the top: Q2 target of 12 Group B banks live by June 30, with current progress.
  • Active escalation banner: BMO Harris, 17 days stuck, with owner and last action.
  • Tracker-vs-Jira reconciliation panel: surfaces every mismatch between the bank tracker and the Jira ticket state. The dashboard exposes the gap instead of hiding it.
  • Filters by status, priority, group, environment. Mobile-friendly card layout for leadership phones.
AI competency · how this got built
Excel → Claude → working HTML in one working session
Fed Claude the Excel data and a list of leadership questions the dashboard had to answer. Iterated on the layout in conversation, refined the escalation banner copy, added the reconciliation panel. Then deployed the static HTML through Google Apps Script as a web app, mapped it to a go/ short link for internal sharing. Result: a working artifact in a day, no eng cycles, no BI tool stand-up.

Why this finally worked for leadership

  • Single URL. No file to open. Opens cleanly on a phone in a meeting.
  • One scan answers the three questions leadership always asks: Are we on track for the OKR? What's escalated? Where is the data inconsistent?
  • The Tracker-vs-Jira panel forces alignment between PM, Engineering, and Product before the next leadership review, not after.
Lesson from Stage 4
AI didn't replace the thinking. It collapsed the build cost so that a working dashboard was no longer a quarter of engineering's sprint. A PM can now ship the artifact.
05
The Compounding · Leadership deck

RipplePrime API Status Escalation · 2026-05-05

Dashboards answer questions. They don't tell stories. For the leadership escalation review, I wrapped the dashboard data in a deck: industry context, connector status, ongoing support challenges, next steps, and a clearer build process going forward.

Ripple Prime API Status Escalation deck overview
PowerPoint · 8 slides · presented to leadership · 2026-05-05

What the deck did that the dashboard couldn't

  • Set industry context first. Bank API maturity is uneven even at Tier-1s. Leadership needs that frame before they hear about a delay.
  • Named the three structural pain points across the board: inconsistent coverage gaps, per-call pricing variance, sandbox-vs-PROD parity.
  • Walked through the BMO 3-legged OAuth issue with Issue → Customer Impact → Path Forward structure.
  • Introduced the new 7-phase, 3-gate build process so leadership saw the system fix, not just the symptom.

What stays in the dashboard, what goes in the deck

  • Dashboard: live state, escalations open right now, OKR progress, owner per ticket.
  • Deck: the story of why we're here, the structural issues, the path forward. Used in monthly leadership reviews and account escalations.

Outcome

  • Leadership had a single 8-slide narrative they could re-share without rebuilding context.
  • The Go/No-Go gates introduced in the deck are now part of the build process for every new bank API.
Lesson from Stage 5
A live dashboard and a static deck are complements, not substitutes. The dashboard says what's true today. The deck says why it matters and what we're doing about it.

What this case shows about how I work

The Bank Tracker didn't fail five times. It outgrew the tool five times. Each swap-in came from a clear trigger: a question the current tool couldn't answer fast enough. Reading the trigger is the PM skill. Building the next version, increasingly, is the AI skill.

Tool selection

Match the tool to the audience and the cadence. Kantata for sequencing, Excel for analysis, Jira for source of truth, HTML for leadership, PPT for narrative.

AI as a force multiplier

Excel-to-HTML used to mean engineering tickets. With Claude in the loop, the PM ships the artifact in a working session and keeps owning the data model.

Bias toward exposing gaps

The Tracker-vs-Jira panel was the highest-leverage feature. It surfaces where the team is out of sync instead of letting that surface in a review.