How zero-latency feedback loops drive product growth at Monzo

Most product teams don’t struggle because they ship the wrong thing. They struggle because they learn too slowly.

You ship a feature, collect feedback, analyze it, debate priorities, and eventually make a change. By the time that loop closes, the team has often moved on. The insight that should have improved the product never quite gets its chance.

Feedback-loop latency is the gap between customer insight and action. The smaller that gap, the faster teams learn and improve. In this article, I’ll show why that matters, using a real example from Monzo and the lessons we learned while building feedback loops designed to move fast. 

Here’s a peek at what you’ll learn:

• What a zero-latency feedback loop looks like in practice
• Why speed often matters more than sophistication when learning from customers
• Three practical steps to collect, share, and act on feedback faster
• How faster feedback helped improve product-market fit in Monzo’s mortgage product

A problem hiding in plain sight

Before we dive into feedback loops, it’s worth understanding the customer problem that set everything in motion.

Monzo is the UK’s largest digital bank, with 14 million customers (including more than 800,000 business customers) and an NPS of around 70 in an industry where low teens are the norm. When we turned our attention to homeownership, we started with deep qualitative research across the entire home-buying journey.

We spoke with customers at every stage – from people dreaming about buying their first home, to those managing an existing mortgage, preparing to remortgage, or moving again. What emerged was a clear and consistent pattern: while many people had a mortgage, far fewer felt confident managing it.

Customers often didn’t know how much they still owed, when their deal expired, or how their monthly payments would change once it did. In some cases, the only time they saw this information was when an annual statement arrived in the mail – once a year, and often too late to act.

To address this, we built Mortgage in Monzo. The idea was simple: using credit file data, customers could connect their mortgage with no manual details required. Monzo would find it for them and surface it in the app, along with insights into rate changes, remortgaging timelines, and whether it made more sense to overpay or save.

It worked. But what really made the difference wasn’t just the product itself – it was what happened once customer feedback started flowing, fast. That’s where the story gets interesting.

Understanding zero-latency feedback loops

A product feedback loop is deceptively simple. You ship something, gather insights on what's working and what isn't, analyze that feedback to prioritize improvements, build those improvements, and ship again. The loop continues.

This should theoretically drive growth because each iteration gets you closer to product-market fit. Nothing revolutionary so far, right?

But here's what most teams miss: the speed of this loop matters more than almost anything else.

Let me give you two scenarios.

Team A rushes to get their product out the door. They skip building feedback mechanisms – there’s no time. Two months later, they finally send a survey. Three weeks after that, their data scientist gets around to analyzing it. By now, it's been a full quarter since launch. The company has moved on to the next priority. The loop never closes.

Their growth curve? An initial bump from launch, that quickly plateaus.

Team B takes a different approach. They build feedback collection into their MVP from day one. Within days of launching, they're reading customer feedback. They don't wait for sophisticated analysis; they read it as it comes in. Before Team A has even sent their survey, Team B has already shipped improvements – multiple times.

Their growth curve shows constant increases as they continuously find new ways to improve product-market fit.

The difference? Latency. Or, as I like to think of it, the time from insight to action.

Three ingredients for zero-latency feedback

So, how do you actually achieve this? Let me share three practical ingredients we’ve used at Monzo to drive our feedback-loop latency toward zero.

1. Make feedback collection automatic and contextual

Quick exercise: Pull out your phone and search your emails for "your thoughts" or "your feedback." How many did you get last week? How many did you even open?

I did this myself – dozens of feedback requests, all unread. We're bombarding users with surveys, and we're all competing for their attention. If you're relying on email surveys, you've already lost.

The solution? Make feedback part of your product experience.

At Monzo, when someone disconnects their mortgage, we don't send them an email a week later asking why. We ask right there, in the moment. It's a dynamic survey driven from our backend – no app release needed. Teams don't have to choose between shipping their MVP and gathering feedback. They can do both easily.

The survey is hyper-contextual. The reason they're disconnecting is fresh in their mind. We provide easy-to-select options based on what we've learned over time. "I got a new mortgage" isn't a failure – it's useful data. "My mortgage details are wrong" triggers a request for more detail.

We use default bias to our advantage in the "Tell us more" section. The text field is pre-selected, encouraging feedback without forcing it.

One word of warning if you’re thinking of creating in-app feedback forms: watch out for sampling bias. A company I used to work for would ask for feedback right after giving customers their loan. Turns out, people are pretty happy right after you send them £10,000. The high NPS was nice but not particularly useful.

2. Put feedback where your team already is

The best feedback tool is the tool you already use. So, rather than changing your workflow to incorporate your customer feedback, change your feedback pipeline to fit your workflow

I don't start my day by opening SurveyMonkey. I start it in Slack, so that's where our feedback lives. The whole team is there. They can comment and discuss feedback in real-time. The barrier to reading feedback drops to almost zero.

"But what about data privacy?" you might ask. Well, if we can make this work as a fully regulated bank, you can too. 

We run a sanitization layer before feedback hits Slack. It's not as complex as it sounds – basically a regex that removes anything looking like personally identifiable information (PII) – phone numbers, emails, etc. We prefer high recall over high precision – better to lose some clean feedback than leak PII.

We also include context like app version and platform. When an issue affects only iOS users on version 5.2, we know immediately. We link to internal IDs for deeper investigation if needed.

3. Trust recurring signals and use your product sense

I believe that product management is both an art and a science. However, problems crop up when we try to over-science it.

For instance, if five different people tell you the same thing in the same week, you've found a pain point. You don't need a month of sophisticated quantitative analysis to confirm it.

Here’s what this looks like in practice. Last week, a customer flagged a bug, and it appeared in Slack at 1:24 PM. Our tech lead saw it almost immediately, and by 3:56 PM, the fix was live. That kind of speed only happens when teams trust the signals they’re seeing and act on them.

There’s a lot of talk these days about using AI to analyze feedback. We've tried it. You know what happened? I found myself reading less feedback. It removed the immediacy. We wouldn't have fixed that bug in two hours if we were waiting for the weekly AI summary.

When "depressing" becomes your product feedback

Let me show you how this all came together for our mortgage product.

We started seeing a word we never wanted associated with our product: "depressing."

"Depressing to look at." 

"Makes me depressed seeing how much I owe."

"It's too depressing."

All real quotes from customers.

Hard to read? Absolutely. But we didn't need sophisticated analysis to see the pattern.

We'd never considered that showing £500 in your checking account next to -£195,000 on your mortgage might be anxiety-inducing. But for many customers, it was.

The insight led us to flip the entire experience. Instead of showing what you owe, we started showing what you own – the equity you've built in your home. We turned a negative story into a positive one.

Product sense still matters here. Being told our product was "depressing" didn't automatically tell us to switch to an equity view, but it gave us a massive head start in identifying where the problem was.

And it worked. Our retention cohorts tell the story. As we implemented these changes, newer cohorts started with higher day-zero retention and declined more slowly over time, signaling a clear improvement in product-market fit.

Breaking the ship-and-forget cycle

Fast feedback loops don’t require complex tooling or heavy processes. They come down to a few deliberate choices about how your team listens, learns, and acts.

At a high level, building low-latency feedback loops depends on three core ingredients:

1. Collecting feedback contextually, inside your product. Ask for feedback in the moment, while the experience is still fresh. Make it easy enough that teams don’t have to choose between shipping an MVP and learning from customers – they should be able to do both at the same time.
2. Putting feedback where your team already works. Customer feedback can be uncomfortable to read, and if it lives in a separate tool or report, it’s easy to ignore. Reduce that friction by placing feedback directly into the workflows your team uses every day.
3. Trust recurring signals. You don’t always need weeks of analysis to know what matters. When the same feedback shows up again and again, it’s often the clearest signal you’ll get. Product instinct still matters, especially early on.

Following these steps not only helps you get to product-market fit faster, but it will also empower your teams to ship lean and launch true MVPs. Why? Because when feedback loops are slow or unreliable, teams learn that whatever they launch is probably the best it’ll ever be. The concept of an MVP breaks down, and launches become overloaded with features "just in case."

Fast feedback loops change that dynamic. When teams trust they’ll hear from customers quickly and have the space to iterate, shipping something small becomes safer. Learning replaces guesswork, iteration replaces overbuilding, and MVPs become a starting point rather than a risk. Over time, that speed of learning compounds. 

Teams that close the gap between insight and action don’t just build better products – they build confidence in their ability to improve them.

This article is based on Ed Stuart-Bourne’s brilliant talk at the Product-Led Summit, London. Enjoy the complete recording here.