A real 2 week Sprint…

tl;dr

A team at Monzo built a working Minimum Viable Product from scratch in just two weeks. It involved close collaboration with a 3rd party, upfront planning and showed us what our max speed could be. It’s not something we plan to do regularly, as the pace took its toll, but I wanted to share how we made it happen and some of our lessons learnt.

Context

The User Problem — Anyone on a fixed-term mortgage (the vast majority of mortgages) should remortgage at the end of each term (2, 3 or 5 years) to avoid large rate increases*. Remortgaging is confusing and many people put it off due to the stress involved in the process, or because they simply don’t realise they need to do it.

*If they do not, the amount that they pay each month will jump up substantially (as they slip onto something called a “Standard Variable Rate”). Standard Variable Rates are obviously great for the banks lending you the money, so they tend to do the minimum legally possible to inform customers that their fixed term is coming to an end.

Solution — Working with our partner mortgage broker, Mojo, we built a fully functioning product that allowed users to enter their information, find personalized remortgage quotes and book a phone appointment with an advisor, all through the Monzo app.

We didn’t know if we had enough users looking to remortgage to make it a viable product for Monzo, so we constrained ourselves to just 2 weeks in order to find out.

What we did to make it happen:

1) Built a partnership and agreed some commercials in advance

A couple of weeks before the 2-week sprint took place, one of our partnership leads was talking to potential partners and agreeing commercials for a test. We picked a partner who offered a great revenue share and showed they wanted to work with us by agreeing to commit engineering time to the test.

2) Went and visited the partner for half a day beforehand

We needed to quickly upskill ourselves on the market and the partner’s product offering, and (most crucially) build trust. Mojo came up big on all three fronts. They gave us time and were patient as we learnt from them what remortgaging was all about. This also gave us a chance to talk (and document) tech, what APIs they did and didn’t have and what we would need to build ourselves. The majority of the team were still working on another product launch and we wanted to minimise disruption, so only our tech and partnerships leads went with me.

3) Got buy-in from the team

We knew it was going to be hard and stressful work, and that it wouldn’t be possible without everyone’s explicit buy-in, so I made sure to ask the team if they were up for it beforehand. We sat down and talked it through, I explained the challenge and reason for the constraints, they asked questions and they agreed with a mix of enthusiasm and trepidation. We also agreed to pause all work from the Energy Switching product we had just put live, deferring all non-urgent bugs to after the sprint.

4) Planned extensively for kick off

Sometimes you can get away with a kick off that is just a few people in a room having a chat. This was not one of those days. 17 people, 4 from our partners, limited knowledge going in (for most people)… this was going to need to be on rails. There was pre reading (mostly about the market), there was a tight agenda and crucially a big room and a bag of post-its. After 4 hours in that room, we built more trust, understood the problem, agreed on a direction and mapped what’s in (or out) of the MVP.

5) Created the right environment for collaboration

I know I sound like a broken record, but Mojo were excellent to collaborate with. They never made us feel stupid, prioritised the work required to add booking and came down to London on more than one occasion to help. Communication on our shared Slack channel was quick, helpful and often humorous. Both sides came in with an open mind and it showed. We felt like we were in it together.

For our part we were super transparent with them, letting them know about our challenging timeline, giving status updates and being 100% honest with any challenges. Transparency builds trust.

6) Restricted the scope to certain use cases

Building products for everyone is really hard and takes a long time, so to start we only built for a subset of users whose situation was easiest from a design point of view. We started with remortgage applications made by single applicants who are not asking for more money and are on a fixed-term mortgage. We would then be able to expand from there if we were able to successfully meet their needs.

7) Tested our main hypothesis

One of the hardest things to decide for an MVP is just how minimum it should be. It needs to be quick to build, but if the data you get from it doesn’t help you make a go/no go decision, then it’s useless.

In this case, we thought about ending the journey with “request a callback”, but crucially we decided that wouldn’t give us the true conversion of the product. After entering your information, legally you have to speak to an advisor before remortgaging and so without testing if users would actually turn up for that call, we would still be making big guesses as to our conversion, which we needed to see whether it was worth investing more time into building out the product for real.

8) Reduced scope to keep to the timeline

I’m super lucky to have worked with an amazing team on this problem. Every standup we held each other to account for our progress and were honest if we thought it the timeline had become unrealistic. We simplified designs, make quick decisions and leaned on our partner when we got stuck. I wouldn’t have tried this with many teams, it would have broken them.

Lessons learned

A) It was very stressful for our designer (and the team in general)

As we wanted to flush out the user journey in the kick off workshop, it made life really hard for design as they needed to wait to get going in earnest until then. But that meant the moment that workshop finished they were under pressure to create designs for the iOS and Android developers. They coped admirably, but it was far from optimal.

B) Don’t ask everyone to leave your team alone

So I had the bright idea of creating extra space for my team by letting everyone else know about our challenge and asking them to excuse the team from everything else they might have in their calendars during that time period. But I did this without asked the team first. The response was concern from peers, annoyance from the team and a lot of time spent apologising by me. Even though my heart was in the right place, I clearly got this one wrong and appreciate the team for how quickly they fed this back to me, allowing me to limit the damage.

C) Assume positive intent and have empathy for others when giving feedback

This is a good life rule, but even more important when dealing with new partnerships. A couple of times, mostly I would guess due to the timeline stress, we forgot this and had to apologise. Whether it was a technical change made at short notice or changing release dates, when you work at pace mistakes will be made and all we can do is hold compassion at the front of our mind throughout.

D) MVP success requires some luck with timing

We had some positive results from the test, with around 1% of users getting to the end of our flow and booking an appointment with Mojo. However we know that lots more customers than this need to remortgage and that the experience direct with lenders is often poor, so we weren’t surprised to learn from our customers that for many it simply wasn’t the right time. This meant after the sprint we decided to pause the work and move to a higher priority — Monzo Plus.

Thanks to the team

Overall, it was amazing to see what we could achieve in just 10 working days: a fully working MVP that allowed users to quickly get remortgage quotes and book an appointment with a trusted advisor at Mojo. We learnt that it was possible to do this with a 3rd party, at short notice and to a high quality, even if we did need a rest after :)