What's so hard about going through Bugs?

Here’s a great post about Embracing the Grind.

My favorite part is toward the end, where the author describes how they got through 2000 open bug reports. Up until them, nobody could do it—or to be more accurate, nobody had the appetite to do it.

I printed out all the issues - one page of paper for each issue. I read each page. I took over a huge room and started making piles on the floor. I wrote tags on sticky notes and stuck them to piles. I shuffled pages from one stack to another. I wrote ticket numbers on whiteboards in long columns; I imagined I was Ben Affleck in The Accountant. I spent almost three weeks in that room, and emerged with every bug report reviewed, tagged, categorized, and prioritized.

This is a great story. It reminds me of Sam, and how one day, there were just… big foam boards all around the office. Sam said, “I had trouble visualizing the flow and logic of what we were talking about [we were discussing the Product Principle of whether or not Explorations should spin off their own Dataset or not], so I just printed them out.”

I don’t know where she got the foam board. I don’t know how late she was at the office pinning all of this stuff together. But she did it.

At the same company, my manager asked me, “what’s so hard about just sitting in a room and doing it? [it being getting through the backlog of Bugs]”

Indeed, what is so hard about it? Some reasons that might come up:

  1. You understand the bug, and you know who should own the fix. In this case, assign it to that group. If you don’t know who should own the fix, take your best guess and ask them to help you to reassign to the right person if you’ve gotten it wrong

  2. You don’t understand the bug. In this case, enlist a SME, a mentor, or your manager. It is equally all of their jobs to help you do this task. But do them a favor and have a handful of these ready to go in one short 20-25 minute meeting. Protip: make sure you dig into their thought process and reasoning so that you can lessen the times that this happens

  3. Not enough information to make a determination—when you have this case, ask clarifying questions to the bug filer, and assign it back to them. Ping them a week later. If they haven’t replied, close the ticket saying “I’m going to assume this has resolved or it’s not as urgent anymore, but please reopen if I’ve gotten that wrong”

Things that might fall into this category:

Here is a handy dandy Canned Phrase that you can use for dealing with Bug tickets:

Closing as won't do


The product team synced on this and to the best of our understanding, we believe that this should be closed as a “won’t do”


On the advice of a former mentor, I’ve started to think of Product Management primarily as an ambiguity-sensing and ambiguity-destroying function. PMs are curious, annoyingly tenacious, and skilled enough to notice when there is ambiguity, and reduce it to its component parts, such that the team can step into the ambiguity knowing that at least they are sure about the next step

As always, we are fallible. We made this decision with our best understanding of the information at hand and are closing this out to give you a firm decision to push back on. If there is information that we don’t have or we seem to have ignored that you feel strongly should lead to a different conclusion, please comment on here and let us know