Conversion dropped from 68% to 41% in two weeks. Eight stories, two sprints, without canceling the rest of the roadmap.
Conversion on the Open Finance consent journey dropped from 68% to 41% in two weeks — a sharp fall, not a gradual one. The journey depends on external partner banks at every step: bank selection, authentication, consent and proposal. Every day it stayed broken meant lost revenue and more support tickets. At the same time, the team was still committed to a roadmap delivery already promised to leadership, with capacity already allocated, which made any prioritization call more delicate.
We didn't know where in the journey people were dropping off, when the fall started, or why. With limited capacity to tackle everything at once, any wrong hypothesis cost time the operation didn't have.
I ran the investigation on my own. I compared the conversion rate of each step in the funnel (bank selection, authentication, consent, proposal) before and after the drop to pinpoint the exact abandonment point, also looking at the average time to complete each step and the volume of abandoned sessions. On the technical side, I cross-referenced API error rate, response time and success rate with the volume of support tickets and recurring reports of frozen screens and generic errors.
I used AI to structure hypotheses and draft the user stories, but validated every technical and financial figure against the real source before taking any number to leadership. I raised three hypotheses and scored each one on an impact-vs-effort matrix, factoring in the risk of not acting, and prioritized the highest-impact one before designing the solution.
Prioritize the partner-integration instability hypothesis over the other two.
WhyThe sharp drop and the frozen-screen reports pointed to an external technical cause, not a product or regulatory change.
ImpactI went straight to a health check, visible status and retry logic, without spending time on less likely hypotheses.
Slice the roadmap delivery instead of canceling it.
WhyLeadership was already expecting this delivery and capacity was already committed; canceling it would create a separate trust problem.
ImpactI decided to deliver a simplified version on the agreed date and the secondary improvements in the following sprint.
Bring the trade-off explicitly to leadership, with estimated financial impact and effort.
WhyIn a crisis, the temptation is to escalate the problem without a proposal.
ImpactPriority was decided right there, in the same meeting, with no further approval rounds needed afterward.
Translate the diagnosis into 8 user stories, prioritized with MoSCoW and split across 2 sprints.
WhyEach cause identified (timeouts with no fallback, no visible partner status, no retry) was dragging down conversion at a different point in the funnel. Slicing it into small stories, each with its own acceptance criteria and expected impact, made it possible to tackle whatever was driving the drop first.
ImpactSprint 1 concentrated the must-haves that stopped the bleeding (timeout with real fallback options, health check, automatic retry, status indicator); sprint 2 brought the should- and could-haves that sustained and extended the gain, closing on a projected 60–65% conversion recovery.
Not all urgency is equal: the incident jumped the queue because it was bleeding revenue every day, and the regulatory item would only have jumped ahead of it if it had a hard deadline.
Confidence doesn't come from speed or urgency, it comes from knowing exactly where to look and what to prioritize first.