Where Product Decisions Go to Die

Every product team has a graveyard. Not of failed features — of decisions. Choices that were made deliberately, mattered at the time, and left no trace that survives the people who made them.

The cost is not sentimental. It is that you make them again, or worse, quietly unmake them.

The four places decisions die

In the meeting. Decided out loud, agreed by everyone in the room, written down by nobody. This is the largest category and the one teams most reliably underestimate — the handoff meeting alone produces several a sprint.

In the thread. Decided in Slack, at 4pm, in a channel with eleven other conversations. Nominally searchable, practically not, because finding it requires remembering the words someone used rather than the question you now have.

In the ticket. Decided in a comment on a ticket that gets closed. The decision is technically preserved, in an artifact whose entire lifecycle is designed to end.

In someone's head. Decided by one person, held by that person, and gone the day they change teams. Every team has an unofficial historian, and treating that as a system rather than a risk is the most common version of this problem.

Why writing things down does not fix it

Here is the uncomfortable part: teams that genuinely document things still lose their decisions. Three reasons, and none is laziness.

Specs record the decision, not the reasoning. A PRD says the invite limit is 20. It does not say that 50 was considered and rejected because the seat model could not express it yet. A year later, the 20 looks arbitrary, because in the document it is arbitrary.

A PRD is a snapshot. It is accurate on the day it is approved. Every decision after that — during the build, in review, at launch — lands somewhere else, and the spec quietly stops describing the product. Nobody notices, because nobody rereads a shipped spec.

Retrieval is the hard problem, not storage. Most teams have written the thing down somewhere. What they cannot do is find it at the moment the question returns, phrased the way it returns. A decision you cannot retrieve is functionally identical to one you never recorded.

The three questions

A decision record earns its existence if it answers these six months later. Most answer only the first.

1 · What did we decide? The easy one. Usually the only one captured.

2 · What did we reject, and why? The load-bearing one. When someone proposes an approach next year, "we do it this way" ends no argument — it is a description of the status quo, and the person proposing the change can see the status quo. "We considered that and rejected it because the billing system could not do per-seat proration" ends the argument properly, and it ends it in either direction: either that constraint still holds, or it does not and the decision should genuinely be revisited.

3 · What would change our mind? The one nobody writes and everybody needs. A decision recorded with its expiry condition — "revisit if we move to per-seat pricing" — converts an argument into a check. Someone can answer it in thirty seconds instead of reopening a debate.

Note what these have in common: they are all about the path, not the destination. The current state is visible in the product. The path is not visible anywhere.

How you know you have the problem

Four symptoms, in increasing order of cost:

• "Why does it work this way?" is answered with a person's name rather than a reason.
• The same debate surfaces roughly twice a year, and each round starts from zero.
• A new joiner proposes something you tried and abandoned — and nobody can explain why it was abandoned, so it gets tried again.
• Someone reverses a decision without knowing they are reversing it. This is the expensive one. Not a debate, not wasted discussion — a change that silently reintroduces a problem you had already solved, made by someone acting reasonably on the information available to them.

The last one is why this is worth attention. The others cost time. That one costs the same bug twice.

Documentation and decision memory are different things

Worth separating cleanly, because teams substitute one for the other and then wonder why the gap persists.

Documentation describes the current state. It answers what does this do? It is maintained by updating it when things change, and its enemy is staleness.

Decision memory describes the path. It answers why is it this and not the other thing? It is maintained by appending, never editing — a superseded decision stays, with the thing that superseded it — and its enemy is silence.

Most teams attempt the first and assume it covers the second. It cannot, structurally: good documentation deletes the history that decision memory exists to preserve. When you update a doc to say the limit is 50, the fact that it used to be 20, and why, is gone. That was the useful part.

What good looks like

Not a process. Four properties:

It lives next to the work. A decision log in a separate wiki is a decision log nobody opens. Next to the spec, in the repo, in the tool where the work happens.

It is written at the moment. Three lines, when the decision is made, while the reasoning is still in your head. Curating it later means reconstructing reasoning you no longer have — and what you reconstruct is a justification, not a record.

It is findable by the question, not the title. People arrive with "can we let admins export this?", not with the name you gave the document in March.

It includes what was rejected. Every time. This is the single highest-value line and the one most consistently cut for brevity.

Why AI makes this more urgent

The obvious reading is that AI reduces the need — a model can summarise your threads, so why bother.

The opposite is true, and it is the more interesting shift. AI has made writing a spec cheap. Anyone can produce a competent-looking PRD in a minute. What a model cannot supply is your context: which approaches your team already tried, which constraints are real and which are habits, which decisions are load-bearing and which are arbitrary.

So a model with no access to your decision memory produces exactly what you would expect — plausible, generic, and periodically re-proposing things you rejected two years ago for reasons that are still valid. The output is fluent and the judgment is absent, which is a harder failure to spot than an obviously bad draft.

Writing was the bottleneck. It isn't any more. Context is, and decision memory is most of what "context" means for a product team.

FAQ

What is product decision memory? The record of why the product is the way it is — decided, rejected, and what would justify revisiting.

Why isn't writing things down enough? Specs record decisions without reasoning, go stale after approval, and are hard to retrieve at the moment the question returns.

What goes in a decision record? What was decided, what was rejected and why, and what would change your mind. The second is the one everyone omits.

How do I know we have this problem? The same debate twice a year, questions answered with names instead of reasons, and decisions reversed by people who don't know they're reversing them.