Every product accumulates features that did not pay back the attention they take. Killing them is the right move. Forgetting why you killed them is the wrong one, because the same impulse that built them the first time will build them again in two quarters, when someone new joins and pitches them.
The forgetting is structural, not careless. The people who lived through a failed feature leave or move on; the conditions that made the idea attractive (the loud customer, the competitor's launch, the plausible-sounding use case) recur on a cycle; and the idea itself is usually genuinely good-sounding, which is why it got built the first time. Without a written record, every generation of the team pays full tuition for the same lesson.
What to record
For every feature you kill: what it was supposed to do, the evidence that it did not, and the reasoning that led to the kill. Two or three paragraphs, dated, in the same place as the rest of your product decisions. That is the entire system.
The evidence line deserves numbers, however rough: adoption after the launch push faded, retention of adopters versus non-adopters, support burden per active user, the maintenance drag on adjacent code. And one field pays for the whole record later: what would have to be true for this to work. Sometimes the honest answer is "a different customer base than ours" and sometimes it is "nothing; the premise was wrong." Writing it at kill-time, while the evidence is fresh, is what turns a tombstone into a reusable decision.
Why it pays off
The next time the same idea surfaces (and it will), you have a real record of why it did not work. The conversation moves from "let's try X" to "we tried X for these reasons; here is what we learned; if you think it is different now, here is what would have to be true." Product judgement compounds when killed features are remembered.
Watch what it does to the social dynamics of the re-pitch. Without a graveyard, the person who remembers the failure has to argue from seniority ("we tried that, trust me"), which reads as dismissiveness and loses to enthusiasm. With one, the new pitch starts from the record, and the burden of proof sits where it belongs: on what has changed since. Ideas that clear that bar deserve the second try. Most quietly withdraw, at the cost of a link instead of a quarter.
Killing well is its own skill
The graveyard also improves the kills themselves, because writing "what happens to the users who depend on this" forces a real sunset instead of a silent one: usage measured, affected accounts told the honest why, a migration path or export offered, redirects and docs cleaned up. Teams with a graveyard habit kill more confidently and more kindly at once, which is why their products stay small while their judgement gets large. A product that only ever adds is a product whose team is afraid of what it cannot remember.
What this is not
It is not a sacred document and it does not prevent revisiting decisions. It is a forcing function for honesty: if the case for trying again is strong, fine, but you have to engage with what you already learned.