📜 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
- 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’
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
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
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
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
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
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
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.