The loan book scaled fast, recovery didn't keep up

Borrowers who wanted to pay couldn't

The authentication flow had a 15% error rate. Only 25% of overdue payments resolved without human contact. Borrowers who intended to pay were blocked before reaching the payment screen. The loan book was growing fast, home equity, auto equity, payroll deduction, but recovery could not keep pace.

Agents worked across fragmented tools and handled 20 cases per day. The pressure to hire more was intense, but hiring was not solving the root cause. More agents meant more cost without changing the recovery rate per case. The gap between origination speed and recovery capacity had become a financial problem.

The operation needed product infrastructure that did not exist. No diagnostic tools, no unified borrower view, no way to measure where in the journey borrowers were dropping off.

Making recovery scale through product, not hiring

The first decision was where to start. Four product surfaces needed building: borrower self-service, the agent CRM, the orchestration platform, and the financial control layer. Over nearly five years, starting as a product analyst, growing into the Senior PM, the thread across all of it was the same: every improvement had to reduce the cost of recovery per case.

Most borrowers weren't unwilling to pay, they were unable to

When we mapped the customer journey, we found that most overdue borrowers were not unwilling to pay. They were unable to. The app made it hard to find payment options or negotiate terms without calling an agent. We redesigned the payment flow: clear balances, one-tap options, automated negotiation for eligible accounts.

The bet was that self-service would outperform agent scaling. The risk: if borrowers did not trust automated negotiation, resolution rates could drop before recovering.

Build where differentiation matters, buy where it doesn't

The collections team had no unified view of a borrower. I led development of a purpose-built CRM that consolidated case history, contact attempts, payment status, and negotiation records. I started with no-code MVPs to validate workflows before formal engineering investment.

As the loan book scaled further, manual prioritization of which borrowers to contact became untenable. I led procurement of an orchestration platform that automated contact sequencing based on risk scoring, payment history, and channel effectiveness.

A deliberate build-vs-buy decision. Contact sequencing is a commodity problem with mature vendors. The CRM needed to reflect our specific loan products. We built where differentiation mattered, bought where it did not.

From payment promise to confirmed receipt, in real time

Negotiated payments needed tracking from agreement through settlement. Manual reconciliation introduced delays and errors at scale. We automated the pipeline from payment promise to confirmed receipt, giving the finance team visibility into recovered amounts in real time.

Recovery became as scalable as origination

The self-service channels that were barely functional became the primary resolution path. Recovery rates improved without adding agents. The operation went from headcount-dependent to product-driven.

The loan book continued to grow. Collections capacity scaled with it. The gap that triggered the original crisis was closed: recovery infrastructure became as scalable as the origination pipeline.

No buffer between the feature and the financial result

In collections, every product improvement translates directly into recovered capital. There is no buffer between the feature and the financial result. That directness taught me to frame every product decision in P&L terms, a habit that carried into every role after.

The no-code MVPs were not a shortcut. They were how we discovered what the production system actually needed to do. Without those iterations, we would have built confidently for a workflow that did not exist.