InDebted
Overview
At InDebted, $117M sat in active payment plans. Very few were completed. Customers were committing, then failing, then re-entering collections. The numbers kept growing. The outcomes didn't.
Position
Product designer and part-time PM
My role
Research, design, planning and support delivery
Year
2025
Markets
Impact summary
Increased payment plan conversion by 83% after rebuilding the payment flow
Drove 30% revenue uplift in month one of launch across six regulated markets
Recovered $352K in 3 months by introducing self-service failed payment recovery
My role
Senior Product Designer & Acting PM
I joined InDebted at Series B, when the product was growing fast but the experience hadn't caught up. Over 3.5 years I led the payments experience, built a design system across six markets, and mentored a designer through a period of rapid growth. Toward the end of my time there I stepped into an acting PM role, partnering with the Engineering Manager to make the case for one of the biggest investments in the payments experience since the product launched.
The problem
$117M locked in plans. Only 9% completing.
Post Series B, payment plans were the largest revenue driver and the weakest link. The real brief wasn't to redesign the flow, it was to make people feel safe enough to engage with a debt they'd been avoiding, while meeting regulatory requirements across AU, NZ, CA, US, UK and UAE.
The gap was hiding in plain sight
Anyone with domain knowledge in the business was genuinely surprised by the completion numbers. Payment plan set-up rates were not just low. They were below what anyone considered acceptable for a product at this stage of maturity. The pattern had been built for an early-stage Australian client base. The world InDebted was now operating in, global expansion, multiple regulated markets, a much broader customer demographic, had moved well past it. The foundation needed to change, not just the surface.
Amplitude data showing the drop off on the payment plan
Building the business case
Before any design work could begin, I needed to create alignment across the business on why this investment was worth making. I ran structured cross-functional workshops bringing together Compliance, Client Success, Marketing and Customer Support. Each team held a different piece of the problem. Compliance understood what was legally possible across markets. Client Success knew what creditors were asking for. Customer Support was sitting on the richest signal of all: exactly what customers were struggling with, in their own words, every day.
The workshops surfaced a shared conclusion. The existing payment plan solution had been designed for a version of InDebted that no longer existed. To compete globally and retain creditor confidence, the product had to adapt fast, with compliance and scalability as the leading constraints, not afterthoughts.
Research
What the data and people said
Before touching the design, I needed to understand where the real friction was concentrated. I partnered with a Product Manager and went straight to the customer support data. The hypothesis was simple: if customers kept calling about the same things, those were the things the product hadn't solved.
Step #1 - Support ticket analysis
The support team used 19 tags to categorise every inbound request. We ranked them by contact volume and agent handling time. Four categories stood out immediately.
Category
Volume
Signal
Payment plan amendments
5.9 to 6.8% of all CS contacts (6,000+ in one quarter)
Customers needed to change payment method or adjust frequency to match income
Plan details and visibility
2.7% of contacts, high handling time
Customers calling to ask their balance, payment method, and schedule. Information they should see themselves.
Early settlement
Low volume, high handling time
No in-product path to pay off early. Every case required manual CS involvement.
Failed payment recovery
Below 0.5% of contacts
Volume was low but the business upside was disproportionate. No self-service retry meant every failure became a cancellation or a call.
The CS data told us where the friction was. The interviews told us why it existed.
Fifteen interviews across Australia and the US surfaced the behavioural mismatch underneath the numbers. The product had been designed around debt duration. The people using it thought about money in terms of weekly life: rent, groceries, what was left after bills. The plan creation flow asked them to commit to a number without any way to pressure-test it against how they actually managed their finances.
Three things came through consistently across participants:
"There were so many steps. I kept losing my place and starting again."
Cognitive overload · AU participant
"I just want to know what I have to pay each week. I don't want to think about the total."
Budget-first mentality · AU participant
"I need to feel like I'm in control of this. Like it's my plan, not theirs."
Control and agency · US participant
Design analysis
Where the data and the design met
Cross-referencing the ticket analysis with a direct review of the existing product made the problem concrete. Two areas were immediately clear.
Payment plan set up
The existing setup flow used progressive disclosure: one question per screen, navigate forward, navigate back. The pattern might work for complex onboarding flows. It did not match how people think about money. Customers had to move back and forth between screens to understand how changing one variable affected another. The free-text amount field gave them no feedback on when the plan would end or whether the amount they'd entered was realistic. The result was a setup experience that felt like guesswork.
Payment plan management
Once a customer was in a plan, they had almost no ability to manage it themselves. Any amendment, whether changing a payment date, updating a card, or settling early, required contacting support. The product treated plan management as an exception to be handled manually, not a capability to be designed. The CS volume confirmed what the design already showed: customers were not being given the tools to stay on plan.
Planning and delivering
Planning and delivery · Influencing without authority
With the research done, I had to switch into PM mode. Not to design features, but to sequence investment in a way leadership, engineering and commercial teams could all commit to.
Two workstreams. Different effort profiles. One clear order.
Payment plan creation
Problem
customers who never set up a plan generated zero revenue
Effort
high back-end investment, redesigning the payment calculation logic from duration-based to affordability-first
Impact
top-of-funnel, every percentage point of conversion directly lifted revenue
Priority
start here, everything downstream depends on it
Payment plan self-serviceability
Phase 1: Payment plan creation
From multi-step friction to one moment of commitment
The rebuilt flow collapsed plan creation into a single screen, budget-first framing, compliance baked in, no unnecessary decisions. The result felt less like a debt product and more like something you could actually manage.
Metric
Before
After
Change
Conversion rate
14.1%
25.8%
Avg. recovery time
175 days
58 days
-67%
Max recovery time
478 days
-93%
Avg. instalment
$66.35
$72.40
+9%
Phase 2: Post-setup management
Four features. One principle: give customers control.
Plan visibility
Customers were calling to ask questions the product should have answered. We shipped a plan detail view: schedule, remaining balance, linked payment method. Support contacts for plan enquiries dropped immediately.
Early settlement
No in-product path existed for early payoff. We launched a single-action MVP in New Zealand. In the first five days, 169 accounts settled in full with zero support tickets.
$352k
Recovered in 3 months
82%
Retry success rate
9.3k
Retry attempts
169
Plans settled in 5 days
The infrastructure underneath
One system. Six markets.
RTL support, currency formatting, regional disclosure copy, WCAG compliance — built once, deployed everywhere. The design system is what made market expansion a configuration, not a redesign. Building it in year one paid back across every initiative that followed.
What I'd do differently
Three honest things
01
I'd have tested the architecture earlier, not the surface
The structural hypothesis should have been testable in a prototype before we shipped. We could have reached the insight faster with a lower-fidelity test.
02
I'd have made the PM transition explicit sooner.
For months before the formal title, I was already carrying product ownership in practice. Making that explicit earlier would have given me more mandate to make structural calls faster.
I'd have used AI prototyping to compress alignment time.
With tools like Figma Make and Claude, I'd build functional prototypes faster today, getting higher-fidelity artefacts in front of decision-makers in hours, not days.
Business impact
