Hi! I’m Cátia 👋 I’m a Backend Engineer currently working on partner integrations here at Monzo. I’ve been in a few product-facing teams since I joined in 2021, and each team has approached work a bit differently. However, they’ve all shared the same focus: get a Minimal Lovable Product (MLP) into customers’ hands early, gather feedback, and iterate 💡.

What’s the ideal way of working, you might ask? Honestly, there are many. Every team finds its rhythm, as it all depends on the team size, goals, and even the company culture 🤝.

At Monzo, our product teams have a lot of autonomy to figure out what works best for them. Over time some patterns have emerged across teams that help us move fast ⚡, stay aligned, and ship things we’re proud of. Here’s a look at what that usually looks like day to day.

Most teams have one planning session per week, usually on a Monday morning ☕. It’s around 30-45 minutes long, which is just enough time to reflect on what was achieved last week and plan the goals for the week ahead. Each team keeps a simple planning document as a central hub. It lists the top goals and links out to proposals and product decisions. It’s intentionally lightweight to focus on aligning the team on priorities for the week instead of large task lists.

Planning document for an engineering focused team, with generally known and smaller launches🚀. The same notion page is maintained throughout, just overriding weekly goals with new ones.

Planning document for a larger multidisciplinary team, working towards a single, bigger launch 🏗️. A duplicate of the page is created each week, with the current focus updated.

During planning, everyone contributes to setting goals, calling out blockers, and raising dependencies 🔗. The Product Manager helps guide priorities, the Tech Lead and Engineering Manager help keep goals realistic, but it’s a team-wide effort. To plan ahead members may create high level tasks in Notion, Jira or Linear at the start of development if they want to note something specific, but other than that it's up to each person to organise their own tasks throughout the week to reach the goal 📝. 

Keeping day to day planning light means teams can adapt fast. If something changes mid-week (and it often does) you are a lot more open to change, as there isn’t a sense of wasted effort from lengthy planning for something that is no longer a priority 🌀.

Around once a month teams do a bigger planning session. This is a time for the entire team to reflect on progress, check alignment with the broader goals, and discuss what’s next. It’s a chance to zoom out and make sure the work still connects to the bigger picture 🧭. Then every half (six months) we create a roadmap for the next half that outlines major themes or metrics we want to focus on. It’s led by the Product Manager with input from others in the team. It’s about setting a shared vision rather than a fixed list of projects.

These longer-term planning sessions are really valuable because they create space to step back, to reflect on what’s changed, and align on what matters next 🎯. Having that shared understanding of what’s coming up, and why, makes it much easier to make trade-offs, confidently shift priorities, and stay focused if things change. They also help rebuild momentum, as everyone (hopefully) leaves with a clearer sense of direction and how their work fits into the overall goals.

When starting a new feature or project, we usually begin with a technical proposal 🧠, which is a document that outlines what’s changing and why. It’s not meant to be too formal or heavy, just enough that someone could understand the context and how to go about making the changes.

Many teams also run quick kick-off sessions once a proposal is ready, to make sure everyone’s aligned before diving into delivery 🤝. It’s a call where we go through what we’ll do, and it’s a great opportunity to catch misunderstandings early and share any risks or open questions.

For tracking work, some teams use Linear or Jira, others stick to Notion task lists 🧾. The key is to use whatever makes collaboration easiest, especially across disciplines. Engineers tend to focus on writing clear pull request (PR) descriptions in GitHub, explaining why something is changing - since what has changed can be seen in the files themselves. That context is gold for anyone coming back later to understand decisions.

Communication happens mainly in Slack, where channels are public by default. This Monzo value, defaulting to transparency, is key in making product development flow smoothly 🌊. It means anyone inside or outside the team can follow along, ask questions, and stay informed with minimal effort from the project lead. We often share screenshots, demos, or quick videos as we build, as it helps surface feedback or spot issues early 📸. When decisions are made in calls, it’s common to drop a short written summary afterward so the context is captured for everyone.

An update on development of the new screen for partner perk codes. I was particularly excited to have had the artwork ready for launch.

The most exciting bit, shipping to customers! 🎉

Before a release, teams host Test Parties. These calls are set up for engineering (and anyone else interested) to test the feature using a Test Plan as a guide. The Test Plan has a list of use cases prepared beforehand by the project lead, and includes setup, steps to test and the expected outcome. It’s a fun, collaborative way to find edge cases and polish tasks before a launch.

We usually release changes gradually using feature flags, which lets us quickly toggle things off if needed and help us monitor performance as we ramp up numbers. We may also run A/B tests to experiment with features by showing different versions to groups of customers while others keep the existing experience. We track key metrics, like how many customers interact with a feature, to understand what’s working. The results aren’t always obvious, but when they are, we have the data to confidently roll out more widely. If not, we dig further into the designs and metrics and try something different. This iterative approach helps us deliver value early, learn fast, and keep improving without getting stuck in months of upfront planning.

For me, the biggest thing that makes this way of working effective is the shared context. Having a clear understanding of what’s happening now and what’s coming up soon makes it much easier to move quickly. When everyone knows what’s in flight, shifting priorities feels natural rather than disruptive, and it’s easier for the team to jump in and help move urgent tasks forward.

I’ve also found that keeping task tracking lightweight really matters in fast-paced, product-facing teams. Tasks are useful for understanding progress, but they’re not where all the detail lives –  that context usually sits in proposals, conversations, and pull requests. Focusing less on perfect task descriptions and more on shared understanding helps keep momentum.

Overall, this way of working has shown me that autonomy works best when it’s paired with visibility and trust. By keeping planning small and easy for everyone to follow, teams can adapt quickly and spend more time building things that actually matter. It’s not about getting everything right upfront, but about learning as you go and improving together 🚀.

If what you’ve read here resonates and you’re passionate about making money work for everyone, we’re hiring designers, engineers, product managers and many more across Monzo! Take a look at our careers page to see if we have the right role for you.