The Illusion of Progress
Why you continue to play Whack-A-Mole
Welcome back.
In the last Episode, we discussed the Hamster Wheel - that sinking feeling that you are moving fast but going nowhere.
Today, we address why you stay on the wheel. We need to confront the most dangerous drug in product management: The Illusion of Progress.
Let me tell you a story a friend of mine shared recently. Let’s call him David.
David managed a Product Team obsessed with “Bug Bashes.” Every Friday afternoon, they would gather in a dedicated space full of pizza drinks and they will blast music, and spend long hours crushing bugs. They even went the extra mile to gamify the process with leaderboards, everyone will high-five at 5:00 PM, and they’ll end the week feeling productive. They had “cleaned the house.”
But David noticed a disturbing pattern in the data.
In Week 1, they fixed 50 bugs. By Week 2, the backlog had filled up with 50 new ones. By Week 4, despite their “record-breaking velocity,” the backlog had actually grown to 60 bugs.
They weren’t cleaning the house. They were bailing water out of a sinking boat with a teaspoon.
When David finally canceled the TGIF pizza parties, the team was furious. They pointed to their velocity metrics as proof of their success. David’s response was harsh but necessary:
“We aren’t fixing anything. We are playing Whack-a-Mole. And the moles are winning.”
The Dopamine Trap
Why did the team fight so hard to keep the Bug Bash?
Because fixing a bug provides an immediate dopamine hit. It is a discrete, solvable task: Identify -> Code -> Deploy -> Done.
It feels like work. It feels like progress. But unless you locate the nest where the moles are breeding, you are wasting your life hitting them one by one.
In Systems Thinking, this behavior is known as getting trapped in the Event Level.
This is the very top of the Iceberg. As humans, we are evolutionarily wired to respond to immediate events. A saber-toothed tiger appears; we run. A server crashes; we reboot it. A customer complains about a typo; we fix the typo.
The problem is that your product is not a saber-toothed tiger. It is a complex machine.
If you have a typo on the landing page, fixing the typo is the wrong move. That is just hitting the mole. The real question is: “How did our Content Management System allow a typo to go to production without review?” That is finding the nest.
The Ratio: Are You a Junior or a System Architect?
So how do we stop hitting moles and start pouring concrete into the holes?
I judge Product Managers by a simple equation: Time Spent Fixing vs. Time Spent Preventing.
The Junior PM spends 90% of their time fixing. They are busy, stressed, and feel “essential.”
The Senior PM splits their time 50/50.
The System Architect spends 90% of their time preventing. They often look bored, but their product never breaks.
If you want to move from Junior to Architect, you have to find the source. If you are trapped in a cycle of Whack-a-Mole, the issues are likely originating from one of three specific “nests.”
Nest 1. The Process Nest (The “Hero” Culture)
The Scenario: A deployment fails and takes down the site. “Dave” jumps in, manually rolls back the database, and saves the day. Everyone claps for Dave.
The System Flaw: Why does a deployment require manual intervention at all? Why isn’t there an automated rollback script?
The Fix: Automate the rollback. Fire “Dave” from his role as Hero and make him the Architect of the pipeline.
Nest 2. The Quality Nest (The “Tech Debt” Interest)
The Scenario: A user reports that the “Save” button is broken on Mobile. Engineers rush to hotfix the CSS.
The System Flaw: The issue isn’t the CSS; it’s the fact that you shipped it. Why do you have no automated mobile testing suite?
The Fix: Stop building features for two weeks. Build a Cypress test suite for Mobile.
Nest 3. The Communication Nest (The “Game of Telephone”)
The Scenario: Engineering builds the feature, but it’s slightly wrong. Product writes a new spec to “clarify,” and Engineering rebuilds it.
The System Flaw: The Designer and the Engineer sit on different floors (or different Slack channels) and never talk.
The Fix: Move their desks. Force the conversation before the code is written.
The Weapon: The “5-Why” Interrogation
To find the nest, you need a weapon. That weapon is the 5 Whys.
This is a standard Lean manufacturing tool, but most teams use it incorrectly. They stop at “Human Error.”
Problem: The site crashed.
Why? The database locked up.
Why? A bad query was deployed.
Why? The engineer made a mistake.
STOP.
If you stop here, you just blame the engineer. You say “Be more careful next time.” That is Whack-a-Mole. You must keep going until you hit the System.
Why did the engineer make a mistake? Because they were tired.
Why were they tired? Because they were working overtime to hit an arbitrary deadline set by Sales.
Why did Sales set the deadline? Because they are incentivized on quarterly quotas, not successful deployments.
The Nest: The Sales Commission Structure.
You can’t fix that with code. But until you fix it, the site will keep crashing.
The Monday Morning Exercise: The “Stop Doing” List
Here is your homework. Look at your calendar for the last week and identify the “Firefighting” blocks, urgent Slacks, emergency calls, apologies to customers.
Pick the biggest fire you fought last week and ask the team:
“What would we have to build so that this specific fire cannot physically happen again?”
If it’s a customer question, build a self-serve tool. If it’s a bug, write a test case that runs on every deploy.
The Rule: You are not allowed to close a bug ticket until you have linked it to a Prevention Ticket.
If you fix the mole without filling the hole, you haven’t finished the job. You’ve just set the stage for the sequel.