Focusing on outcomes: How we delivered our mortgage retention product

When you were at school, did the teacher ever tell you: “make sure you read the exam question carefully”? While it might have sounded silly at the time — of course you would read the question — their main goal was to get you to think carefully and analytically, even if you thought you knew the answer.

As a Product Manager in a fintech bank, let me tell you that you can apply this advice to your work, too. Often, a stakeholder or a client will get in touch about a product, and they will present you with their desired solution up front. But it’s really worth stopping to consider the ask — or the exam question — first. In this post, I’ll tell you how I applied this approach to a key product here at Atom bank.

A little bit of background

Last year, I took over as the Product Manager for a key mortgage retention product. A key process in residential mortgages is the successful management of the groups of accounts whose interest rate will all mature at the same point in the year.

At Atom we were fast approaching a period of where a third of our mortgage accounts would be deciding whether to stay with us or move lenders. The goal of the product was to deliver an in-app product switch option for eligible existing customers.

When I took over, we had the desired solution, customer journeys and technical requirements defined, with a backlog of around 200 requirements to deliver. The estimated end date would see Atom totally miss the opportunity to offer the option of a direct product switch to customers during the upcoming busy period.

As you can imagine, this delay raised questions from our stakeholders across the business. They wanted to know how we would manage the increased demand without the help of the app, and were concerned we would miss the opportunity to launch a new capability. Everyone knew what the end solution was, but didn’t know if we could deliver it quicker.

So where to start? Could we deliver the app journey any quicker? The answer was no, not with the current scope and remaining complexity to build. Put simply, it was time to stop and reconsider the original exam question and restructure our answer.

Outcome or output?

Knowing that the end solution could not be delivered by the deadline, I began by reviewing the end to end journey for the customer. I grouped the requirements into 14 capabilities (customer outcomes), of which we had six built or nearly completed.

By doing this, I identified four opportunities to deliver the app journey in increments to our customers. However there was still a risk we’d miss the desired launch date for the first increment.

With the desired output being unachievable, it was at this point the exam question changed. Instead of trying to figure out how we deliver the solution of a fully fledged in-app journey, we need to go back to the start and understand the desired outcome and how to work to achieve that.

We refocused from the output:

• an in-app direct product switch capability;

to an outcome:

• retain accounts maturing between 2023-2024 via a direct product switch process.

Answering the real exam question

At this point, we’d re-read the exam question and now knew it was actually: “How do we deliver a direct product switch journey for our accounts maturing in 2023?”

With around four months to go until the desired delivery date, we knew we were quite deep into our allotted exam time. I worked with a group of representatives from across the business (Technology, Operations, Risk, Marketing, User Experience and Compliance) to understand what options we had.

To ensure we had considered all elements, I used the POPIT framework to facilitate conversations:

• People — What training/awareness do our teams need?
• Organisation — Have we got enough people/resources to make this feasible?
• Process — Do we have a process we could use/enhance?
• Information — How will we monitor success and manage workflows?
• Technology — What is currently available/feasible to build?

With the exam question clearly in mind, we agreed, designed and deployed the first iteration of a direct product switch to customers within just ten weeks. The process leant on the technical capabilities the team had already built, while also incorporating a manual process to provide customers with an easy overview of their product switch options, expected payments and costs and a process to switch directly with Atom.

Did we pass the exam?

Within two months, we had a pleasing response from the account holders we contacted, with many going on to sign an offer for a direct switch. Now, 7 months since its initial launch, our direct product switching accounts for a significant number of the mortgages retained at Atom. Considering the position we started from and the speed at which we pivoted, we consider this a great success.

The uptake from customers wasn’t the only positives to emerge from the product. We were able to use this pilot to identify improvements to our technical services build, helping us find processes that needed reviewing. We also launched a post-switch customer survey to help inform our progress going forward.

Additionally, I think one of the biggest takeaways has been that we need to be prepared to change our mindset from always being wedded to a solution. Instead, we will focus on creating a solution that the customers want and need.

We took the lessons learned from this first stage of the product and took them forward to the next one. We reviewed the current designs and increments, then reapproached them with a new mindset and lens.

The next stage of app functionality for this journey was launched in quick succession of the manual process. We can now offer customers the ability to browse products, compare details and create an offer document within seconds, all within the app. We continue to build and develop basing our decisions and designs on the outcome we’re trying to achieve, rather than the solution.