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
🌍 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
🤓 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
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
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!
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
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
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
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
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
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
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.
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
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.