A rocket ship flying to the top right

The Vision and Principles for Our Internal Product

To help our Customer Operations team support one billion customers, we’re building tools that help them do their jobs as effectively as they can. These tools are our internal product: software that we build and use ourselves, to help make your experience of Monzo as amazing as it can be.

Product Vision 🔮

What is the future we’re trying to create?

We let people perform at the speed of thought

How are we achieving this?

We're creating a scalable and extensible platform that lets a global and elastic team learn and progress to achieve its highest performance.

This has a specific meaning to us and is very tightly related to our way of working, so we’ve outlined below what we mean by each of these things:

Scalable and extensible platform 📈:

  • We’re building a product that’s technically reliable and capable of supporting Monzo’s ambitious growth

  • We’re building a product that has many contributors and that’s second nature to engineers of all levels

  • We’re building a product that’s easy to change and lets us react quickly to external needs and opportunities

  • We’re building a product that lets us experiment and prototype fast

  • We’re building a product that supports an omnichannel approach to customer support, so Monzo customers can access it in the way that’s most useful for them

Global and elastic team 🌍:

  • We’re building a product that lets a globally distributed team operate seamlessly across different geographies and time zones

  • We’re building a product that lets different types of teams and user profiles co-exist

Learn and progress 🤓:

  • We’re building a product that makes sense to users of all levels: be it to complete beginners or those who’ve used it for years

  • We’re building a product where key documentation and training materials are embedded and presented to the right user at the right time

  • We’re building a product that encourages and rewards people for becoming experts in using it

Achieve its highest performance 🚀:

  • We’re building a product that’s intuitive, friction-free, and optimised for power users

  • We’re building a product that’s safe and makes it nearly impossible to do the wrong thing – users can work quickly and comfortably, safe in the knowledge that the tool has got their back

Product Principles 📜

To make sure we’re consistent in how we approach problems and build our product to achieve our vision, we have a set of principles.

These principles help us to:

  • bring to life our beliefs on how to build our product and how can our vision become a reality

  • ​​facilitate a shared understanding by distilling the nature of what we’re building into simple and easy to digest statements

  • ​​evaluate new ideas and solutions by clearly putting them in perspective

  • ​​steer group discussions into the right direction and make them more productive

  • ​​empower everyone to make decisions autonomously

  • ​​assess our outcomes against what we believe in - a good way to keep us accountable of our decisions!

Care about our platform contributors

We believe that great solutions let us stay flexible and better prepared for the future. Building an extensible platform implies we make our product easy to contribute to technically: we aim at having many teams building on top of it, so it has to be inclusive and accessible. We search for the best technical solutions but don't lose our strong focus on other developers’ experience.

Optimise for learning with simple solutions

If we get things right at the first attempt, most likely we're not being as fast or ambitious as we could be. But while we want to be swift, we want to reduce risks as much as we can.

Given this, we’ll optimise our development process for learning and for prototyping. We'll focus on building the simplest thing to get the job done, generating enough data and knowledge to take better decisions further ahead. This doesn’t mean we’ll launch and train users in unfinished or inconsistent products: we boost learnings with MVPs, which to our team stands for Minimum Viable Prototype.

Case Study: Refunding customers during the upgrade

When we asked customers to upgrade from the prepaid card to the current account, we knew some people would ask us to close their accounts and refund any money they had left.

For customers that added money to their accounts by topping-up with another debit card, we used a script that automatically refunded their money to the original card. If the customer had replaced the original card or closed their bank account, we needed to work out how to get their money back.

First, we thought about engineering a clever way to re-attempt the refund, or automating a process that would send the money back via bank transfer instead.

But, because we don’t believe we should invest engineering time in automating a process before we’ve learned enough to confirm that we need to, we decided to do it manually first and wait for the results. Every time a refund failed, a new task would be created in BizOps Hub, allowing an engineer to work out how to solve it.

By the end of the upgrade, only a couple of hundred refunds had failed. That’s a relatively small number that we could solve without any engineering effort, by asking customers for their bank details so we could send the money back by bank transfer.

Instead of building a fully-fledged feature upfront and automating in every possible case, doing things manually lets us learn whether it’s worth the effort in the first place, and saves us time and energy if it’s not!

Prove it

We’re aware that every feature contains a cost and we balance it against its value. We believe everything in our product should either have a purpose or be removed.

The way we explore purpose and impact is to always test and measure what we're building – whether with quantitative or qualitative data. We don't do this as an afterthought and prefer to have too much data than not have enough: when we build something we build in the ability to gather data so we can prove that we've built the 'right' thing.

Case Study: Reassessing regularly

When he said, “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away,” Antoine de Saint-Exupéry gave us an insight into building awesome products.

We know our product gets more and more complex each day, as we keep adding features that solve new problems. To make sure every feature is adding value, we meet every Monday to use data and user feedback to see if a feature should be removed from BizOps Hub.

We started exploring giving COps (members of the customer operations team) performance metrics directly embedded in the tools they use so they could check how well they and their team were doing at a glance, and how the overall customer support numbers looked like for a given day. We later on realised the metrics section of the product was barely used, as COps would have access to more complete and tailored metrics in separate dashboards they could easily access as well. Even though we intend to explore embedded metrics and bring a gamification approach to some aspects of our product, we decided to remove this entirely for a while as this problem was already solved thus reducing the complexity of the product.

Teach, guide, and empower

Our product drives efficiency and performance and works for everyone, regardless of what experience they have. We design our product to reduce the chance of mistakes and increase confidence.

We embed training and whenever we can we’ll customise the user experience automatically and let users personalise the product to fit them.

To empower our users to work at speed of thought we must design solutions that match the diversity of our COps: they must have the opportunity and confidence to use the tools in the way that makes them the best COp they can be.

Let consistency and patterns build trust

We're building a product that’s predictable and has a high conceptual integrity. This means users can develop a clear and reliable mental model that lets them navigate through the UI intuitively. We know trust increases when actions provide consistent feedback and you can move fast with a safety net that doesn’t let you make mistakes, and this matters to us.

Keep the big picture in mind

We’re conscious that building a web-based tool which is a poorly-integrated aggregation of features is worse than having these features in separate tools that people understand.

We focus on outcomes and not outputs: our product doesn't offer an aggregation of features but rather a holistic, consistent experience. Adding features that don’t support a workflow will decrease how easy it is to use and maintain because the code and UI are more complex. If we focus on workflows and outcomes instead of features we won’t fall into this trap.