What Monzo Learned From Scaling its Lending Team

I’m a product manager at Monzo. We’re a UK-based bank and our mission is to make money work for everyone.

We recently reached 1,800,000 current account customers – after launching in January 2018 – and are focusing on growing our user base and revenue. We’re currently profitable on a per user basis, but not overall as a company, and so we need to grow both the number of users and the amount of money we earn per user to cover our ongoing fixed costs. I work on the revenue side of this equation, and build lending features like overdrafts and loans.

The lending team at Monzo has grown from five to 25 people in less than nine months to support this. In the same time, we’ve grown overdraft usage from zero to over 100,000 people, and revenue from zero to break-even on a per customer basis.

As we’ve grown, we’ve tried to develop a culture and set of processes that aim to motivate and empower people to make good decisions at speed, without having to ask for permission.

We try to motivate and empower the lending team through three practices. Firstly we explain the “why” by defining an inspiring vision with the team, and having a clear goal. Then we focus the “how”, by breaking the goal down into independent outcomes, and organising autonomous squads around them. Finally we structure the “what” – this means we create systems, frameworks and processes, rather than feeding squads a roadmap.

Let’s look at these three practices in more detail.

1. Explain the why

Create Ownership by Defining a Clear Vision and a Goal With Your Team

Key takeaways:

• A clear team goal should help people understand how their work contributes to the wider company’s objectives.
• An inspiring vision should help people understand how their work contributes to individual users, by explaining what your product or service aims to do for users.
• Both can be really motivating, and give people a reason to get up in the morning and something to feel proud of.

Make Sure Your Team Goals are Based on Company Goals

As a product manager, you’re responsible for working with your team (and the other team leads) to set a tangible team goal that will help the company meet its goals.

At Monzo a company-level goal would be to break even as a company, while our team-level goal would be to generate £X net revenue per customer. Lending works on per-user revenue.

Make Sure Your Vision is Customer-Centric

I see the vision as a set of principles to help you make good decisions on your way to achieving the team goal.

For example, without a set of guiding principles, Monzo might make it really difficult for you to pay back a loan early, so we maximise the interest and boost our revenue goal. With a principle of “putting the user in control” we’re unlikely to make that choice.

How do you get to a great vision? This is what worked for us at Monzo:

• Know your customer: collate everything you know about your customer. Here’s what we learned at Monzo for example. We built our knowledge from desk research, user interviews and personal experiences.
• Workshop: get your team in a room, split into small groups and brainstorm an inspirational future state for your company and your customers. What would you be proud of? In my experience you’ll come away with a few similarly-themed ideas, that you just need to polish up before sharing.
• Share it widely: as soon as you have something defined, share it widely. Get up in front of the company and tell them what your team is going to achieve.

At Monzo, a company-level vision is to make money work for everyone, while our team vision is to  help people use borrowing to achieve their goals (by putting people in control, and helping them feel good about their borrowing).

---

2. Focus the how

Create Ownership With Autonomous Squads Around Independent Levers

Key takeaways:

• You can reduce complexity by breaking the team goal down into independent levers. It turns a vague goal like revenue into an equation.
• You can improve focus by organising people into squads that own one or more levers, as it limits the number of things people need to worry about or understand
• A clear measure of success for each squad makes the goal tangible. People can ask themselves “will what I’m doing today affect this metric or key result? If not, why am I working on it?”
• Squad autonomy means people know that no one else will make decisions or do the work for them. It also limits the opportunity for blockers.

Break the Team Goal Down Into Independent Levers

I use a “split tree” to break the team goal down into independent levers. A lever should be granular enough that you could go out and move it tomorrow, this means it’s more of a leading indicator than a lagging one. It should also be enough of a problem for a squad (a group of people) to own (they can then break it down further if they need to).

In the lending team, we’ve split net revenue into revenue and loss, and then further into metrics we can move:

• Revenue: to increase revenue, we need to make more money (Shadow £) available to more people (Eligibility %), and build a good enough product that people want to take it up (Take Up %). These are the leading indicators, with revenue the lagging indicator.

• Loss: to reduce loss, we need to lend less money (Average £ in arrears) to fewer people (% customers in arrears) who aren’t going to pay us back, as well as helping those in financial difficulty recover (% recover).

Squads can break these levers down further. For example, instead of worrying about “how do we get people to use our loan?” the squad that owns Take Up % can focus on “how do I ensure all our users know we offer loans?” This reduces complexity, turning a vague goal like revenue into a clear and actionable equation.

I should note that we also track other non-revenue focused metrics like net promoter score. We also talk to users regularly to understand their experience of using our lending features.

Organise People Into Squads That own one or More Levers

Assign ownership of one or two levers to each squad (a group of people). Show them the split tree; it clearly explains why their squad’s outcome matters to the company as a whole. This is extremely motivating and helps to focus their actions.

It’s important to communicate what you’re not focusing on too. In our case, we’ve made an active choice not to optimise for loan utilisation (we don’t want to encourage our customers to max out their overdrafts) or loan retention (we actively want our users to pay back early if they can, by using our budgeting tools).

When the lending team was five people, we had one squad. Now we’re larger, we have three squads who own the following levers:

• Product:
  • Lever: Take-up %
  • Mission: Discover and build lending features that solve customer problems in a delightful way
•  Platform:
  • Lever: Eligibility % and Shadow £
  • Mission: Support lending the right amount, to the right people, at scale
• Collections:
  • Lever / goal: Recover %
  • Mission: Help people repay their loans and manage financial difficulty

By limiting the number of levers a squad owns, we limit the number of things people need to worry about, reducing complexity and mental overhead so they can move faster.

Have a Clear Measure of Success for Each Squad

The product manager should work with each squad to set an ambitious definition of success for the quarter – so squads know “when they’re done”. We use OKRs (objectives and key results) to do this.

It’s important that the product manager leads this conversation, but that they don’t have all the answers. They should ask questions like: “What can we do this quarter to move the levers? How much can we move them by? If we only had six weeks to achieve the same goals, what would we do differently?”.

For example, in the Platform squad our key results are:

• Increase the average amount of credit available to eligible users
• Increase the percentage of eligible users from ~ X% to Y%
• Scale our systems to flexibly lend to more users
• Credit decision changes can be made (mostly) without engineering input

We then have really clear key results (KRs) for each objective. For example, the first objective – increase the average amount of credit available to eligible users – has the following KRs:

• Write a new credit risk and affordability strategy, get sign-off from the board
• Build new affordability estimator
• Become a full member with TransUnion, a credit scoring agency
• Lend the first £10,000 loan

A clear measure of success for each squad makes the goal tangible, so people can ask themselves “will what I’m doing today affect this metric or key result? If not, why am I working on it?”. It also makes it easier to gauge progress on a weekly cadence – “have we moved closer to the KR or the metric since last week?”.

Ensure Every Squad is Truly Autonomous

Ensure each squad has everything they need to achieve their goal, ideally with no dependencies.

Here’s what this means, and how we achieve it at Monzo:

• The squad is cross-functional: it has the right balance of engineers, designers, analysts and advisors from marketing, customer service, legal, risk and compliance
• The squad has full autonomy to achieve the goal:
  • Access to data or information: everyone in Monzo has access to most of our data through Looker, all of our emails are public via Google Groups, conversations tend to be on public Slack channels, and information is open to all on GDrive or Notion.
  • Decision-making rights: there’s a strong framework of delegated authority with very clear guardrails, giving squads the freedom to ship without the need for committees, business cases or sign-off (within known bounds).
  • Architecture and developer tooling: we’ve built tools and abstractions so that most engineers don’t need to worry about infrastructure (e.g. provisioning servers), and we use over 700 microservices to reduce cross-team dependencies, which also results in a fairly streamlined code review process.
• The squad has end-to-end responsibility for achieving its goals: it should be clear that no one else is going to move the lever if the squad doesn’t

There’s plenty more writing on how Spotify has famously done this, and Martin Eriksson gives the example of Transferwise here too.

Being autonomous means people know that no one else will make decisions or do the work for them. It also limits the opportunity for blockers, as, with the right mix of people in the team, you can pre-empt problems before they arise.

---

3. Structure the What

Create Frameworks and Processes, not Roadmaps

This creates ownership by setting a clear expectation that product managers won’t always make decisions. It avoids the product manager becoming the bottleneck, and promotes a sense of responsibility and confidence among the team. They feel empowered and so move faster.

Talking to customers to generate ideas gives the team confidence that they’re solving a genuine customer problem, and results in better outcomes. Binning the roadmap, and instead focusing on processes, frameworks, and questions, means the team is motivated, empowered, and focused on results.

Set the Expectation That Product Managers Won’t Always Make Decisions for the Squad

Product managers should not have all the answers on what to do next. There are two clear problem areas where this arises:

• Spoon-feeding work: Team members show up to planning and expect a well-laid out set of tasks to work on that week. They expect neatly written JIRA tickets, with prepared copy and designs. They don’t want to think about the problem, or brainstorm how to solve it. This is a cultural change that takes time to shift, but you can start by not doing it and having an open conversation with your squad to explain why it matters. Success is much more likely if everyone is fully engaged with the problem.
• Bottlenecking work: Team members go to the product manager, who talks to marketing to get copy, and gives it back to engineers. Engineers realise there’s a character limit and the process repeats. The product manager gets swamped, and becomes a bottleneck. Product managers should politely decline to get involved in decisions, and suggest the engineers go directly to marketing.

Solving both of these problems is immensely important. They empower the team to move faster and more collaboratively, and will also lead to better outcomes.

Product Managers Should Generate Ideas and be the Voice of the Customer

Even if you’re not responsible for having the answers, you should still pull your weight. Above all, make sure you have a tight feedback loop with your customers (or prospective customers), and share their feedback widely in real-time. This is one of the most valuable things you can do.

How can you amplify the voice of the customer?

• Make raw customer conversations visible: I regularly talk to customers through our in-app chat and share the link so the team can read the raw chats, in real time. User interviews are written up and shared with executive summaries.
• Set goals around customer voice: in Q3 we had a quarterly goal, “every member of the team has sat in on a user interview, and written up the notes” and “can talk about the top three customer problems”.
• Build a backlog of customer problems or opportunities: this can be as simple as a few notes, a mindmap or a split tree, and you should continuously refine it as you learn more.

A customer perspective means your team will be confident that they’ll solve a real user problem, and result in better outcomes.

Bin the Roadmap, Focus on Processes, Frameworks and Questions Instead

We move fast, and work towards outcomes not output. In this situation, a feature-based roadmap that tells you what you’ll be building in three months time is guaranteed to be wrong. If it’s not, you’re not learning quick enough. More importantly, roadmaps encourage your team to stop thinking about the problem. Six brains thinking about the problem is better than one.

Instead, continuously refine your vision. Set clear goals, with associated targets. Build structured frameworks and processes for identifying how you can take steps today to get there. And, above all, do everything you can to improve the pace and quality of decision making for the squad.

Here are some specific tactics I use:

Regularly refine your vision, and share it widely with the company.

Have a quarterly kick-off to define the measures of success (OKRs) as discussed earlier. Do this for each squad, and come prepared.

Have a mid-quarter healthcheck, to assess whether you’re still working on the right objectives, identify new risks or blockers, and reprioritise for the second half of the quarter.

Encourage more regular healthchecks, such as a regular bi-weekly retro that helps you catch team health or strategic concerns on a tighter loop. We use Retrium and ask two questions – what’s gone well, what hasn’t gone well? We vote on the topics and dig into the top view. Set clear actions. Encourage 1:1s among your team too.

Run ideation sessions every few weeks. These can be used to build up an “idea or opportunity backlog” and provide a regular forum to take a step back, and think laterally about what you’re doing and why – “what opportunities are we leaving on the table? Should we be? Are we moving towards a local maxima or an invisible asymptote?”. Use these to build your longer-term strategy.

Talk to customers regularly and encourage your team to join. Share the results widely, let your team know the impact of their work on the lives of customers

Run a tight weekly planning for 30 mins to an hour. Make sure your squad never leaves your weekly planning without a clear, ambitious and outcome-focused step towards your quarterly goal.

Set incremental outcome-focused goals: for example, rather than a goal that will ‘lay the groundwork’ to make 500,000 users eligible for loans (but ultimately make no one eligible), are there things we can do in a single week to make 10,000 users eligible?

Make it efficient, and leave time to think: on a Friday afternoon I send round a link to Retrium, where everyone posts anonymous responses to “What should our ridiculously ambitious, outcome-focused weekly goal be?”. On a Monday morning I group the responses, we vote on the top two or three goals to discuss,  pick one, and break it down into discrete steps that need to happen to achieve it.

Make sure things get done: I make sure every key result has an owner who is responsible for making sure a decision gets made or the thing gets done

Keep goals to a minimum: ideally just one or two that the team can rally around

Run a daily standup for 10 mins .Be the chief question officer for your squad and make it your mission to embrace speed as a habit. As questions like: “What are we doing today to hit our weekly goal? Why can’t we roll this feature out to everyone today? Is there anything blocking anyone achieving the weekly goal? How can I help you move faster?”

Be present throughout the day, in person and on Slack, and think of yourself as the Chief Unblocker. Constantly de-scope (“Do we have to think about that now? What would happen if we ignored that case for now?”) and take things off your team’s plate.

All of this means you’ll get the best out of a team, in terms of motivation, empowerment and results.