Why your product decisions keep getting relitigated

A product team spends two weeks evaluating whether to build a native mobile app or a progressive web app. They research the options, consult engineering on feasibility, analyse the user data, and decide on the PWA approach based on a specific set of constraints. The decision is discussed in several Slack threads, debated in a meeting, and confirmed in a follow-up message. Implementation begins.

Three months later, a new VP joins. They ask: "Why are we doing a PWA instead of a native app?" Nobody can produce the reasoning quickly. The Slack threads have scrolled away. The meeting wasn't recorded. The follow-up message is buried in a channel with thousands of messages. So the discussion starts again. The same arguments are made. The same analysis is conducted. The same conclusion is reached, two weeks later, after consuming time from the same people (minus the ones who've left) plus the new VP who triggered the reopening.

This relitigation pattern is one of the most common and most expensive inefficiencies in product organisations. It wastes time, frustrates the team, and delays the work that depends on the decision staying settled.

Why it happens

The decisions are usually good. The reasoning is usually sound. The problem is that the reasoning wasn't preserved in a form that's findable when the question comes up again.

Product decisions are typically made through a combination of Slack discussions, meetings, and informal conversations. Each channel captures a piece of the reasoning, and none of them preserves the full picture in a searchable, persistent form. The decision is distributed across three Slack threads, two meetings, and a Google Doc that was shared but never filed anywhere navigable.

When someone asks "why did we decide this?", the team can't produce the answer quickly because assembling it requires searching across multiple channels, reconstructing the timeline, and remembering which discussion happened where. The friction of finding the reasoning is high enough that it's often easier to re-discuss than to research.

Decision logs as the fix

A decision log that captures each significant product decision with its reasoning, alternatives, and constraints prevents relitigation by making the answer instantly findable.

The format is simple: what was the question, what options were considered, what was decided, why, and what would need to change for the decision to be revisited. When the new VP asks "why PWA instead of native?", the team points them to the decision record. The VP reads the reasoning, understands the constraints, and either accepts the decision or raises a new consideration that the original team didn't have. Either way, the relitigated discussion that would have consumed two weeks is compressed into a fifteen-minute read.

The challenge is creating decision logs consistently, which is where self-writing documentation matters. When the system captures the Slack thread where the PWA decision was debated and the meeting where it was confirmed, and generates a structured decision record from those sources, the log is created without anyone writing a separate document. The decision was made in the team's normal workflow. The documentation was generated from that workflow.

The compound benefit

Decision logs become more valuable as they accumulate. After six months, the team has a searchable archive of decisions and their reasoning. After a year, they have a comprehensive record of how the product evolved and why. New team members can read the decision history to understand not just what the product is but how it got to be that way, which is the context that prevents them from proposing changes that revisit settled ground.

The decision log also improves decision-making quality over time, because it creates accountability for reasoning. A decision that's documented with its rationale can be evaluated retrospectively: was the reasoning sound? Were the constraints accurate? Would we make the same decision today? This kind of reflective practice is impossible when the decisions and their reasoning are lost within weeks of being made.

Frequently asked questions

What counts as a "significant" decision worth logging? Any decision that affects the product direction, architecture, prioritisation, or scope and that you'd expect someone to ask about later. If a new team member would likely ask "why is it this way?", the reasoning should be documented. Day-to-day implementation decisions don't need logs.

Doesn't this slow down decision-making? When the decision records are generated automatically from existing discussions, there's no additional time cost. The team makes decisions the same way they always have (Slack, meetings, docs). The logging happens as a byproduct.

What about decisions that need to be revisited because circumstances changed? The decision record should include "what would need to change for this to be revisited." When those conditions are met, reopening the decision is appropriate and the record provides the starting point. This is different from relitigation, which is reopening a decision without new information.

Related reading: How to build a product knowledge base, Your codebase is documented but your decisions aren't, Documentation debt. Related pages: Decision log, Self-writing docs, For product managers.