ROLE
Research Principal
TIMELINE
4-month pilot → 3-year engagement
My agency had already designed and shipped a redesigned mobile app for the Subprime CC Co, a credit card issuer serving customers who are building or rebuilding credit. It was a good app, grounded in competitive research and internal stakeholder knowledge. What it had never had was a single direct conversation with the people using it.
The Subprime CC Co's research function, like much of the organization, was siloed: individual teams held their own fragmented knowledge, gathered inconsistently, with no shared source of truth about the customer. I was brought in to run something the organization hadn't tried before, a Continuous Discovery pilot, embedding live customer research directly into the team's ongoing delivery cycle instead of treating research as a separate, upfront phase.
The pitch was simple: prove that talking to customers continuously, not just once, makes better products, and make the research cheap enough in time and disruption that the delivery team would want to keep doing it. What follows is how that pilot became the evidence base for a three-year mandate to centralize research across the organization.
Continuous Discovery only works if it's solving problems the organization actually has, not just the ones a research team assumes it has. So before recruiting a single customer, I ran a series of stakeholder workshops across three groups inside the business, each holding a different slice of the customer relationship:
These workshops surfaced two things I needed before writing a single research question: what each part of the business already assumed to be true about the customer, and what they most urgently wanted to know but couldn't answer themselves. Comparing notes across the three groups made the gaps visible, Care held a very different mental model of the cardholder than Finance did, and neither had a shared, current picture of who the customer actually was in 2023, four years after the last formal research had been done.
That gap analysis became the seed of the entire sprint plan. It's also what let me walk into the first customer interview already knowing which assumptions were shared across the business and worth testing first, rather than starting from a blank page.
The first round of interviews focused on how customers actually learn about credit, where their knowledge came from, what they believed about managing it well, and what they wanted for their financial future. It was foundational, generative research: four customers, three hours of conversation, well over 200 discrete data points.
Family, it turned out, was usually the first source of credit education — but the advice didn't always take. One customer described being warned off a specific card by a cousin, and using it anyway. Another had absorbed no formal guidance at all and had since made a point of teaching her own children what she'd had to learn the hardway, through experience.
What struck me more than any single quote was the shape of decline across all four conversations: nobody arrived at a subprime credit position through one bad decision. It was always a chain, job loss, a medical bill, a divorce, an aging parent's care, compounding over months or years. That reframed the whole engagement. Design and messaging built around a single "moment of failure" would miss most of what these customers were actually navigating.
This sprint also surfaced something the app's design hadn't accounted for: a persistent, almost daily vigilance. Customers checked their balance far more often than any "typical" banking behavior model would predict, not out of confusion, but out of hard-won caution.
With foundational beliefs mapped, the second sprint moved to the app itself, pairing interviews with a live walkthrough to understand what customers actually did, and why. The sentiment was, encouragingly, strongly positive. Every participant volunteered, unprompted, that this was one of their preferred banking apps to use, simpler and less cluttered than competitors they'd used before.
But the same sprint surfaced the most consequential insight of the entire pilot: customers who had successfully rebuilt their credit through the card were quietly souring on it. One had kept a card open for over a decade with a credit limit barely above a few hundred dollars, no rewards, no perks, purely because closing it felt riskier to their credit score than the ongoing fee felt costly. Several described the arrangement in similar terms: grateful for the second chance the product had given them, resentful that graduating out of that need didn't seem to change anything about the relationship.
This sprint also caught a real, quantifiable product bug hiding behind what looked like a UX complaint: customers with two cards found that switching to view their second card, then navigating to make a payment, silently defaulted the payment flow back to the first card. It wasn't a hypothetical risk, a customer described being hit with a late fee from exactly this pattern, without realizing what had happened until the notice arrived.
The third sprint shifted focus to navigation and mental models, using card sorting alongside interviews to understand how customers organized and named the things they needed to do. The gap between the existing information architecture and how customers actually thought was immediate and consistent.
"Card Controls," a section customers needed most urgently in a fraud or loss scenario, wasn't where people looked for it. Several reasoned their way toward "Security" or "Services" instead, a completely different mental model than the one the navigation had been built around. One customer, asked what "Card Controls" meant to her, guessed it had something to do with parental permissions rather than anything to do with locking a lost card.
This sprint also caught something the app's design had actually gotten right, but was hiding: customers with multiple cards wanted one combined view of everything they owed, not a per-card switcher. The existing homescreen assumed a single-card mental model that didn't match a meaningful share of the customer base.
Sprint four moved into usability testing on a proposed profile redesign and a new "Quick Actions" concept for the home screen. The standout finding was almost accidental: half the participants had never noticed that a card-lock feature already existed in the app. Once surfaced prominently, every single participant reacted positively, one frequent traveler described using it reflexively, locking her card again immediately after every purchase out ofongoing fraud anxiety.
This sprint also caught a tone problem that had been sitting in plain sight. A status message using the phrase "cease and desist", standard legal boilerplate to the team that wrote it, was read by a customer as a sign she had done something seriously wrong, prompting her to look up the phrase out of genuine alarm. It was a small piece of copy with an outsized emotional cost for a customer base already primed to expect bad news.
Even color wasn't neutral. Without being asked directly about it, customers described the app's calmer blue and green palette as soothing, and contrasted it, unprompted, with a competitor's bold purple interface, which one customer said felt like it was "screaming" at her.
The final sprint stress-tested the highest-stakes flow in the app: reporting a card lost, stolen, or fraudulently used. Overall sentiment toward the flow was positive, it saved people from waiting on hold. But the testing surfaced a pattern that mattered more than any individual screen: customers, already anxious, kept getting asked to re-enter information they'd already provided, or were told partway through an in-app flow that they'd need to call in anyway.
Smaller frictions compounded the same problem. A form built to capture when and where a card was lost didn't adjust for someone reporting fraud on a card they still physically had, several customers stalled, confused about what to enter for a card that was never actually lost. A location picker that cycled through all fifty states before reaching "Foreign Country" slowed down exactly the customers most likely to be traveling when the problem occurred.
Across the sprint, the clearest throughline was that customers wanted to understand the status of their own situation at every step. Vague system messaging, the kind that read as ominous rather than informative, consistently outperformed nothing in causing anxiety, worse than a plainly worded explanation would have.
Customer interviews
Minutes of conversation
Sprints
Insight themes
Recommendations delivered
Across the pilot, findings translated into 19 concrete additions to the design and development backlog spanning items already moving into design, active user testing, and further discovery. They directly informed:
The backlog additions mattered. But the more consequential outcome was what the pilot proved about how the Subprime CC Co could operate. Five sprints of embedded, continuous research, starting with the business itself, then moving to customers, demonstrated, sprint over sprint, that direct input could run alongside active delivery without slowing it down, and that doing so produced sharper, better-defended product decisions than internal assumption ever had.
That evidence became the case for something bigger than one product team's backlog. The Subprime CC Co extended the engagement into a three-year contract with a mandate well beyond the mobile app: centralize research across the organization. Instead of each business unit independently gathering fragmented, siloed customer knowledge, the goal became a shared research hub, a single source of truth that any team could draw from, rather than every arm of the organization re-learning the same lessons in isolation.
