This context is really valuable when reasoning about the product or determining what's important to prioritize.
The issue with the "declare bankruptcy and important stuff will come back" is that you don't actually solve the underlying ruthless prioritization issue and very quickly end up in the exact same position.
You also irritate people that spent time writing up product issues for potentially important bugs by auto closing them (so many important things may not come back), but the bigger loss is that going through all of them gives you solid product historical context.
For what it's worth, the best PMs I know go through the backlog and understand what they're killing when they approach a project that's currently fucked. I think it has a positive side effect of giving them a lot of credibility too (as well as helping them ramp up).
Issues for those teams usually 'best effort' isolation going forward, which compounds the issue.
I mean, maybe not—you might lose the users impacted by the bug. Which from a company PoV is probably a loss, but depending on how broken incentives are may not be for the dev team.
I won’t argue that my way is the only correct way because I’m certain it’s not.
Something I didn’t make clear in the very brief description I gave was that, yes, capturing context of what was there is important.
That said - the two projects I worked in where we did this were filled with bad bugs (a separate and problematic issue).
Nothing really replaces spending time with users. That’s what I tend to opt for - figuring out what sucks in their experience and iterate on that.
It's great for individual contributors who don't care about understanding the product and are probably going to be in another team in 3 months.
In a previous job I did what the author did and it helped building an understanding of the project and with knowing at any time the list of the top X things we had to fix.
This seems like a great idea: technical debt bankruptcy.
In reality, you're throwing away hugely valuable data that people spent real time and effort producing for you.
See also: https://www.jwz.org/doc/cadt.html
https://hn.algolia.com/?dateRange=pastMonth&page=0&prefix=tr...
And of course that person didn't close their pet project or the features they promised.
It's slightly soothed when it's realized one of your summarily closed bugs could have prevented the next incident or major customer loss.
If I write a bug report, I'm doing the developers a favor by pointing out where they failed in development and validation. Simply closing the report with no action tells me that you don't care about the quality of your code or the way it affects the users; and that I've wasted my time thinking that you did care and writing up the bug.
Close everything older than 2 weeks. If it’s important/relevant, it will crop back up. If it’s not, then it stays unfixed.
This can be really uncomfortable to do. But it’s how I’ve rescued a couple of teams that I’ve led as either an EM or Tech Lead.
Put another way - if everything is important or “must fix”, nothing is.
So to the author: that seemed like a waste of time. I would not have done it because I’m not convinced the outcome would have been meaningfully different from my tactic.