Have you heard? My new book Continuous Discovery Habits is now available. Get the product trio's guide to a structured and sustainable approach to continuous discovery. In this post, I argued that you should ignore bugs. It was easily the most controversial blog post I’ve written. If you haven’t read it, go ahead, read it. I’ll wait. It was fun.
Naturally, some people disagreed. If you read the comments, you’ll see that one of the key points I should have made in that post was that the high cost of interruptions often outweighs the benefits of fixing some bugs. That’s exactly what we are going to explore today.
If you write code in a production environment, you already get it. Interruptions are costly. You probably read my post, and said to yourself, finally someone who gets it. If this is you, feel free to skip the rest of this post.
If this isn’t you, and you fall into the category of people who believe you should stop everything and fix every bug as it comes in, otherwise you aren’t possibly delivering a good product and oh-my-god what will your customers think, keep reading.
While I do think everyone should learn to code, I don’t think you have to be technical to be a good product manager. But I do think you need to understand the cost of interruptions. So here’s my attempt to explain it in terms that hopefully anyone can understand – even if you’ve never written a line of code.
Remember when you were in school and you had to write a paper. You had to organize your thoughts. You had to construct an argument. Maybe you had to tell your audience what you were going to tell them, tell them, and then tell them what you told them.
Take a minute and remember what it was like to write a paper. Maybe you were an outliner. Maybe you wrote free-form. Either way, imagine you are a page and a half into a five page paper. You are on a roll, typing away. Thoughts firing as fast as you can type.
Now imagine someone interrupts you.
That’s kind of annoying. But it’s okay. You finish your sentence and you address the interruption.
After it’s over, you can easily read where you left off. It triggers the memory of where you were headed and after a few seconds thought, you are back at it
Not much lost.
Now imagine you are writing that same paper, but with a group.
Each page has a different author. You are writing page 3. Maybe you collectively outlined the paper ahead of time. Maybe you didn’t You have some vague idea of what everyone else is writing. Maybe you’ve even seen drafts. But it’s pretty hard to keep it all straight.
Now imagine you get interrupted half way through your section.
It’s a lot harder to pick up where you left off. You probably have to re-review the other sections. It’s not as simple as just reviewing your last few sentences and picking up again. You have to re-familiarize yourself with what everyone else is doing so that your stuff fits in. That interruption is a little more costly.
Okay, now imagine you are writing the same paper with a group, but that the people who wrote page 2 and page 5 are no longer around. You can’t ask them any questions. Maybe you don’t quite understand what they wrote. You just know that you have to make your section work.
You re-read each section half-a-dozen times. You finally get an idea of what you should write. You are one paragraph in and someone interrupts you.
Ugh. Now when you jump back in, you have to reread everyone else’s parts. You have to reconstruct what they were thinking. You have to figure out how your section fits with theirs. Now you can see that interruption is starting to drive you nuts.
But stay with me. There’s more.
Now imagine you are writing your paper in a group with two people missing and the paper is in Spanish. You’ve just been interrupted. You need to reread everyone else’s parts. Two people are no longer around. You only kind of know Spanish. I mean, if you really focus, you can figure out what each sentence says. But it’s not as simple as just reading where you left off and picking up again.
This is what engineers deal with on a daily basis. They work in environments where engineers have come and gone. Many people work on bits and pieces of the code base. They have varying degrees of familiarity / expertise with the language that they are working in. To get anything done, they have to hold a lot of context in their head while they work. You can only imagine how costly an interruption is in this environment.
Oh, and I’m not done. There’s one more thing.
Suppose you were writing your paper with four other people (two who are no longer around) and one of them wrote their section in Microsoft Word on a Mac, one wrote their section in HTML, and two wrote their section in Word Perfect for DOS (yeah, that’s right, blue screen, white font, and F7 to exit).
Now suppose someone comes to you and says, I know you are writing page 3, but I found a problem on page 2. If we want to publish a high quality paper we really need to fix this problem. There’s only one catch.
Page 2 was written in Word Perfect on DOS.
You don’t have Word Perfect. You don’t have DOS. In order to even look at that section you need to install new software. You need to reboot. You need to reconfigure everything. And then when you are done fixing page 2, you need to reconfigure everything back so that you can keep writing page 3.
So let me ask you this: is it really worth the effort to edit that sentence to not end in a preposition or can we let it go this one time?
I’m not exaggerating. This is what it can be like to address some bugs. Sure, some are easy to fix. It’s the equivalent of asking someone to change a word in a sentence one paragraph ahead of where you are writing. But some require you to reconfigure everything, understand a whole new context, read through other people’s code, and then hope that the change you just made doesn’t introduce new bugs – since you can’t possibly understand how everything works in a reasonable amount of time.
Engineering interruptions cost a lot. For those of us who don’t write production code on a daily basis, it can be hard to remember this.
But as good product managers, we need to make sure our engineers are working on the highest impact items, not making sure every page is pixel perfect. I’m a perfectionist by nature. But after 12 years of building products, I’ve learned that “good enough” really is good enough.
Now, for those of you who disagreed, does this help clarify? In light of this, do you still argue that we should stop and fix every bug? I’d love to hear your thoughts. Let’s keep the conversation going.
