We rebuilt the core payment, transaction, and card balance workflows on a top-ranked financial services mobile app. Revenue tripled in twelve months. Customer satisfaction improved 54%.
The lesson had almost nothing to do with what we built. It had everything to do with how we decided what to build — and who made that decision.
The Problem
I joined a product team that was building in a reactive posture. Feature requests came from executives, from competitive analysis, from customer support tickets, from marketing. Everything was a priority. Nothing was sequenced against a clear theory of what would actually move revenue or satisfaction.
The core surfaces — payments, transaction history, card balance — were functional but not optimized. Nobody had done the work of understanding where users were dropping off, what actions they attempted and failed to complete, or which workflows generated the highest volume of support contacts. That data existed. It just wasn't driving decisions.
The risk was compounding. A J.D. Power top-ranked app is a competitive asset — something customers cite when choosing or staying with a financial services provider. Letting core workflows stagnate while building features with uncertain ROI was eroding a hard-won position one sprint at a time.
The Approach
The first thing I did was stop the backlog negotiation and go back to the customer data.
I pulled twelve months of session analytics, support ticket categorization, and App Store review sentiment. I cross-referenced them against the specific surfaces I was responsible for: payments, transactions, card balance. The signal was concentrated. A small number of friction points were generating the overwhelming majority of negative customer feedback — and none of them were on the roadmap.
The most significant: the payment confirmation flow required too many steps for routine transfers, the transaction detail view lacked the information customers needed to recognize charges (generating support contacts), and the card balance display didn't surface the information customers were actually trying to answer ("what can I spend today?" rather than "what is my statement balance?").
These weren't glamorous problems. There was no AI involved. No breakthrough technology. Just a mismatch between what the product surfaced and what customers were actually trying to do — a mismatch that the data made visible once someone went looking for it.
I built the roadmap around closing those gaps. The annual OKR process gave me the framework: I committed to specific improvements in payment completion rate, transaction detail engagement, and contact rate on card balance queries. Those commitments shaped what we built, in what order, and how we measured success.
Execution required close alignment with engineering and design. I spent significant time in technical architecture reviews — not to direct engineering decisions, but to understand the constraints that shaped what was possible in six months versus twelve. A PM who doesn't understand the codebase well enough to have an honest conversation about technical debt isn't actually managing a product. They're managing a list of requests. Understanding what was genuinely hard versus what was merely unfamiliar changed how I sequenced the work.
We shipped in phases, with measurement gates between each. Before moving from phase one to phase two, we needed to see a measurable improvement in the metrics that justified the investment. This meant slower initial progress and much more reliable outcomes — each phase proved its value before we committed to the next.
The Results
- 3x revenue growth within 12 months of the first release
- 54% improvement in customer satisfaction scores
- J.D. Power top ranking maintained through the entire rebuild
- Roadmap methodology adopted as the model for future product delivery across the organization
The Real Lesson
The 3x revenue growth came from fixing things that were already broken, not from building things that were newly exciting. That's almost always where the highest-ROI product work lives — in the gap between what customers are trying to do and what the product currently lets them do easily.
Finding that gap requires using data as a primary input to product decisions, not as a post-hoc validation of decisions already made. It requires a PM who is willing to challenge a backlog built by negotiation rather than evidence. And it requires an organization willing to let the data surface uncomfortable truths about what to prioritize.
The hardest conversation I had on this project wasn't with engineering. It was with stakeholders who had been advocating for specific features — features the data didn't support, features that would have consumed engineering capacity without moving the metrics that determined whether we kept the J.D. Power ranking.
Being willing to have that conversation, and backing it with data specific enough to be credible and humble enough to be honest about uncertainty, is the core skill. The technology is downstream of that. It always is.
