A note before you read: I'm a Scrum Master, not a titled Product Owner. What follows is my own product thinking, applied to a domain I know well from sitting close to subscription billing systems in my day-to-day work. It's built on general, publicly known patterns in subscription billing, not on any employer's proprietary data. I'm sharing it because I think the best way to show you can do a job is to actually do a piece of it.
The problem
Picture a mid-market B2B SaaS company with around 15,000 paying accounts on monthly and annual plans. Revenue is leaking, not because customers are choosing to leave, but because their payments are simply failing: expired cards, insufficient funds, banks declining transactions for no visible reason. This is involuntary churn, and it's a different beast from voluntary churn. Customers aren't unhappy. They just fell through a crack in the payment flow. Which means it's fixable through better product design, not through discounts or retention calls.
I've spent years adjacent to this problem, facilitating delivery on Zuora Billing and Zuora Revenue workstreams as a Scrum Master. I've watched dunning configuration, collections workflows, and payment-retry logic get built, without ever owning the decisions about what to prioritize or why. This case study is me stepping into the seat next to the one I usually sit in: framing the problem, making the calls, defining what ships.
Who actually feels this
Two personas drive the priorities here:
The Billing Ops Lead. She's watching failed-payment volume climb every month, manually chasing down accounts, and has no visibility into which failures are recoverable versus dead ends. She needs the system to do the triage for her.
The end customer. He doesn't know his card expired last week. He finds out when his account gets suspended mid-project. He's not churning by choice, he's churning by neglect, and a single well-timed email would have kept him.
Setting goals that mean something
It's tempting to jump straight to "reduce churn." That's not a goal a team can build against. I broke it down into three measurable targets for a two-quarter horizon:
- Recover at least 30% of failed payments within the retry window, up from an assumed baseline near 12%
- Cut the average time between a failed charge and account resolution from roughly 9 days to under 3
- Reduce manual billing-ops intervention on recoverable accounts by half
Each of these is something engineering can build toward and something I can measure without ambiguity.
Prioritizing with RICE, not gut feel
I had five candidate features on the table: smart retry timing based on card networks, proactive card-expiry notifications, a self-serve payment update page, an internal dunning dashboard for billing ops, and a machine-learning based failure-reason classifier. Running each through RICE (Reach, Impact, Confidence, Effort) surfaced something I didn't expect: the flashy ML classifier scored lowest, not because it wasn't valuable, but because effort was high and confidence in near-term impact was low without more failure data first. The self-serve payment update page and smart retry timing scored highest. Cheap to build, directly addressed the biggest reach, and didn't require new infrastructure.
That's the RICE model doing its job: keeping the roadmap honest instead of chasing the most interesting technical problem.
MVP first, sophistication later
Phase 1 (MVP): Smart retry timing tuned to card network patterns, a self-serve card-update page linked from suspension emails, and a lightweight ops dashboard showing recoverable vs. dead accounts.
Phase 2: Proactive expiry notifications 14 and 3 days out, and a failure-reason classifier feeding the retry logic instead of running on a fixed schedule.
Sequencing it this way meant we could ship something measurable in one quarter and let Phase 2 be informed by what Phase 1 actually taught us about failure patterns, rather than guessing upfront.
The trade-off I'd defend in an interview
The hardest call was deprioritizing the ML classifier despite it being the "smartest" solution on paper. Engineering wanted to build it first. I pushed back because we didn't yet have clean, labeled failure data to train it well, and shipping a mediocre model would have delayed the parts of the fix that didn't need machine learning at all. Sequencing matters as much as selection. A roadmap isn't just a list of good ideas, it's an argument for what order they earn the right to exist in.
Why this translates from Scrum Master to Product Owner
Running sprints for two years on this exact system taught me the constraints before I ever had to make the calls. I know what "just add a retry" costs in engineering time because I've watched teams size that work. I know which stakeholders will push for the shiny model over the boring fix, because I've facilitated that argument in refinement sessions. For me, the gap between Scrum Master and Product Owner was never about knowledge. It's about who gets to decide. This case study is what I do with the decision rights when I have them.
If you're hiring for a Product Owner or Product Manager role and want to talk through how I'd approach a real backlog, I'd genuinely enjoy that conversation. Find me on LinkedIn.
Top comments (1)
Deferring the failure-reason classifier is the right call, and the case for it is stronger than you make it. Processors return a decline reason on every failed charge, so the split between retryable and dead is mostly readable rather than something you have to learn. Insufficient funds or a generic processing error is worth retrying. A lost or stolen card, or a do not honor, will not clear on the fourth attempt, and repeated tries there can count against you with the network. Phase 1's ops dashboard can label recoverable versus dead on day one by grouping on that reason, so the Billing Ops Lead is not waiting on Phase 2.
Worth checking whether your processor already runs card network account updater, which pushes reissued numbers to the merchant automatically and would absorb part of the expiry volume your 14 and 3 day notifications target.