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 contributors

We believe that simple solutions let us stay flexible and better prepared for the future, so we have a bias towards them.

Building an extensible platform implies we make our product easy to contribute to: 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.

Do it manually first, automate later

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 have a purpose, otherwise remove it.

The way we explore purpose and impact is to always test and measure what we're building – whether with quantitative or qualitative data. We understand that more data is better than not enough data and don't put this on a second plan.

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 then empower

We’re building a product that works for everyone, regardless of what experience they have.

We design our product so people get better at using it through embedded training and conscious nudges. Whenever we can, we’ll customise the user experience automatically and let users personalise the product to fit them.

Design for power-users first

Working at speed of thought with effortless interactions is top of mind when we’re considering how to build things: our product is meant to drive efficiency and performance.

We can do this because we include training and progression as a core part of our product. This doesn’t mean we don’t care about making our product useful for beginners. It means that when we make decisions we’ll optimise for the vision we have in which every user is a power user where shortcuts, avoiding unnecessary clicks and window management are welcome.

Case study: Replying to our customers at the speed of thought

Our goal is to have one individual COp being able to support 100,000 Monzo customers - that’s a lot! From July 2017 to July 2018 we sent over 2 million individual messages from Monzo to customers through in-app chat. If each message was a 1 Km trip, this would allow us to do 50 trips around the entire earth 🌍

Replying swiftly to our customers is crucial for COps, but it’s also important that our customers can tell that they’re talking to a human. So we needed to design BizOps Hub in a way that lets COps keep their individual approach, while performing exceptionally well.

So we added a new Saved Responses tool to our chat that lets COps create complete answers quickly, by typing in different abbreviations. They can combine them like Lego blocks and build complex answers on the fly.

1. When James gets in touch with a problem, a COp can type in a six-character abbreviation (“hilook”) that expands into a proper greeting, complete with emoji.

If James asks a common question, like how to change his Direct Debits to Monzo, a COp can use an eight-character abbreviation (ddswitch) to give James a proper explanation.

Because we know that COps type quickly, the tool even leaves room for typos! You’ll see the COp wrote ddsowthc instead of ddswitch, but the right answer still expanded. We use ‘fuzzy’ matching so that spelling precision won’t slow them down 🤓

3. When James replies to thank us, they can end the conversation using the abbreviation sokind

Overall, the COp in our example wrote a reply consisting of 603 characters in total, but only took around two seconds and 20 characters to build it!

If you’re new or you don’t know the abbreviations by heart, we want to make sure the tool’s still accessible to you. So we also added a search feature, that lets COps browse all the different categories of saved responses, see a short explanation, a preview of its content, and the abbreviation for each one. This means that they’re learning the right abbreviations even when they need to browse for the right answer.

Searching for Direct Debits Saved Responses and expanding the ddswitch abbreviation after exploring

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.

Balance a micro and a macro vision

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.