The Bug That Won

2:47 on a Thursday. Level 6. The afternoon sun had been baking the west-facing windows for an hour, and the aircon was losing the argument — that particular brand of warm-office stillness where the vinyl flooring gets tacky under your feet and every keyboard sounds a little louder than it should. Someone a few desks over had cracked open a bag of shrimp-flavoured Lays, and the smell hung in the air the way only shrimp-flavoured Lays can. Somchai’s Thai iced tea had gone the colour of dishwater, the condensation pooling around the base of the plastic cup and creeping toward his mouse pad.

He wasn’t looking at his code. He was looking at Grafana. Specifically, at a green line that was doing something green lines aren’t supposed to do for a week-long bug fix — climbing at an angle usually reserved for launches, major releases, things that get mentioned in all-hands meetings. He tilted his monitor toward Namfon at the next desk, the way you do when you think the dashboard might be lying to you and you need someone else to confirm you haven’t lost your mind. She leaned in. Then she sat back. Then she leaned in again.

That bug fix had just outperformed every product experiment the team had run that quarter. Combined.

That’s the moment we need to talk about. Because somewhere in your backlog right now, buried under feature requests and roadmap priorities, there’s a bug that could be your biggest win of the year. And you’re ignoring it.

“Why Are We A/B Testing a Bug?”

You’ve heard the question. Maybe you’ve asked it yourself. It sounds perfectly reasonable: the thing is broken, just fix it. Why waste time wrapping it in an experiment?

As the physicist Richard Feynman once said, “The first principle is that you must not fool yourself — and you are the easiest person to fool.” We fool ourselves constantly about what matters. We assume features drive revenue. We assume bugs are just costs. We assume fixing things is grunt work that doesn’t move the needle.

The experiment says otherwise.

When you A/B test a bug fix, you’re not testing whether to fix it. You’re generating evidence. You’re building a dataset that proves, in language the business can’t argue with, that quality has commercial value. Every bug fix that wins an experiment — and they almost always win — is another data point in your arsenal.

Without that data, “we should invest in quality” is just an engineering opinion. With it, it’s a business fact.

The Booking Form

Here’s what makes the story above land so hard. The bug was on the booking form — the credit card page, specifically. Think about where the customer is at that point in the funnel. They’ve chosen the hotel. They’ve picked the dates. They’ve selected the room. They’re entering their payment details. They are committed.

This is peak sensitivity. Any friction here isn’t just annoying — it’s trust-breaking. The customer has done all the work, they’re about to hand over money, and something feels off. That hesitation, that moment of doubt, is extraordinarily expensive at scale.

As the behavioural economist Daniel Kahneman observed, “Losses loom larger than gains.” A bug at the point of payment doesn’t just lose you a booking — it loses you a customer who was already yours. The asymmetry is brutal.

The fix generated more incremental bookings for the quarter than all the team’s product experiments combined. Let that sink in. Months of product ideation, design, development, and experimentation — outperformed by a bug fix that took a week.

The Principle: Closer to the Money, More Quality Matters

This generalises beyond one story. The closer a user is to a transaction, the more every pixel, every millisecond, every interaction matters. A minor annoyance on your homepage? They’ll probably forgive it. A minor annoyance on your payment page? They’ll go to your competitor.

Your bug backlog isn’t a graveyard of things you’ll get to eventually. It’s an unpriced portfolio of experiments waiting to prove their value. Some of those bugs are sitting on top of revenue you don’t even know you’re losing.

Building the Reflex

The cultural shift isn’t complicated, but it requires discipline. When someone on your team picks up a bug, the question should be automatic: “How are we testing that?”

Not “should we test it” — how. Make it a reflex. Make it the question people hear so often it becomes second nature. Because every time you fix a bug without measuring the impact, you’ve missed an opportunity to prove that engineering quality is a revenue driver, not a cost centre.

Over time, three things happen. Engineers start seeing bug fixes as high-impact work, not grunt work. The business can’t dismiss quality investments because you have the receipts. And your bug backlog stops being a “we’ll get to it” graveyard and starts being evaluated as a source of potential wins.

The Bottom Line

W. Edwards Deming said, “In God we trust. All others must bring data.” Your bug backlog is full of data waiting to be collected. The only question is whether you’re disciplined enough to measure what happens when you fix it.

Your best experiment might not be on your product roadmap. It might be in your bug tracker, waiting for someone to ask: “How are we testing that?”

Now, if you’ll excuse me, I need to go look at our bug backlog. I have a feeling there’s a couple of winners hiding in there.