The Vision and Principles for Our Internal Product

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:

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:

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.

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.

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!

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.

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.

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.

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.

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.