Product Decision Records: Keep the Reasoning, Not More Meeting Notes

Six months after a launch, a team asks why workspace visibility is private by default. Nobody remembers.

The roadmap says when the feature shipped. The research repository contains interviews. Slack preserves fragments. A presentation says the choice was “aligned”.

None of them explains the decision that was actually made, which alternatives lost, or what would justify reopening it.

This is the gap a product decision record fills.

It is a small, durable account of a consequential choice. It preserves the reasoning needed by the next person, including the possibility that the decision was sensible then and wrong now.

Decision record 014, as accepted

The following record is fictional. It concerns a collaboration product in which new workspaces can be visible to everyone in a company or limited to invited members.

Title

Default new workspaces to invited members only.

Status

Accepted on 15 January. Product director owns the decision. Review by 30 June or when enterprise discovery produces decision-relevant evidence about administrative policy, whichever comes first.

Context

Small teams create workspaces for early plans, personnel discussions and client material. Creators do not always understand the visibility setting during setup.

Support has examples of accidental internal exposure. Current discovery is weighted towards smaller customers. Enterprise administration needs are not yet well understood.

Decision

New workspaces are private to invited members. A creator can switch to company visibility during setup or later. The interface explains who can discover and open the workspace.

Alternatives considered

1. Company-visible by default.
2. No default: require an explicit choice.
3. Administrator chooses one default for the organisation.
4. Infer the default from workspace type.

Evidence

• observed confusion in setup research;
• support cases involving unintended visibility;
• analysis of current visibility changes after creation;
• technical review of membership and permission behaviour.

The record links to the evidence. It does not paste every note into the decision.

Assumptions

• avoiding unintended exposure matters more than reducing invitations for the current customer mix;
• creators can identify the people who need initial access;
• administrators do not yet require a centrally enforced visibility default;
• the settings language is understandable enough for later changes.

Consequences

Private default reduces one exposure path. It adds invitation work, can hide useful work from colleagues and may weaken organisation-wide discovery.

Support and onboarding must explain visibility. Analytics must distinguish default acceptance from deliberate selection.

Review triggers

• enterprise customers require administrator policy;
• workspace discovery becomes a retention problem;
• research shows creators misunderstand “invited members”;
• permission architecture changes;
• material evidence contradicts any assumption above.

This is enough context to challenge the choice without replaying every meeting.

The admission test

Do not create a record for every button label, backlog order or routine implementation choice. A library full of trivial records becomes another place nobody searches.

Record a decision when at least one of these is true:

• reversing it later would be expensive or disruptive;
• it changes a customer, data or ethical promise;
• reasonable people support materially different alternatives;
• several teams must act consistently on the answer;
• the choice depends on uncertain assumptions;
• the decision is likely to be questioned after its context fades.

A pricing model, permission default, build-versus-buy boundary or target segment usually qualifies. Choosing Tuesday for a workshop does not.

The record is not a substitute for a decision framework. The framework helps make the choice; the record preserves what mattered afterwards.

What belongs in the record

Useful records are concise, but not skeletal. Include the parts future readers cannot safely reconstruct.

The decision sentence

Write a verb and a boundary: “Default new workspaces to invited members only.” Avoid “Improve permissions” or “Decision about visibility”.

Context at the time

Describe the problem, constraints and timing. Context explains why an imperfect option could be rational.

Alternatives genuinely considered

Do not manufacture rejected options after the meeting. Record the credible paths and the decisive trade-off for each.

Evidence and its limits

Link to research, analysis, technical assessment or policy. State which population, period and assumptions limit that evidence.

Consequences

Include work and risk created by the decision, not only benefits. A choice that creates no consequence is probably not described honestly.

Ownership and review

Name a role or person accountable for reopening the decision. Add triggers tied to changing evidence, not a ritual annual date alone.

This structure supports executive communication because it makes the choice and its trade-offs visible without a deck.

Keep discussion out of the final record

Meeting notes answer who said what. A decision record answers what the organisation chose and why.

Link discussion notes when the history matters, but do not make future readers mine a transcript for the conclusion.

The record should be drafted near the decision, circulated to the people accountable for it and accepted through a lightweight, explicit step.

“No objections in Slack” is weak acceptance for a consequential choice. State who had authority to decide and who was consulted.

The AWS guidance for architectural decision records uses a lifecycle with proposed, accepted and superseded states. Product records benefit from the same clarity.

This is an adaptation of an architecture practice, not evidence that decision records improve every product outcome.

They also need product-specific fields: customer consequence, behavioural evidence, commercial constraint and review signal.

What happens when the world changes

By June, the fictional team has new evidence. Large customers want administrators to prevent both accidental exposure and isolated private workspaces.

The old binary default cannot express their policy. Some customers require private workspaces; others require company-visible work except for approved sensitive types.

The team does not edit record 014 until it appears to predict this evidence. That would destroy its value as a historical account.

Instead, it creates record 027.

Decision record 027, superseding the first

Title

Let administrators set an organisation workspace-visibility policy.

Status

Accepted on 2 July. Supersedes record 014 for organisations with an administrator policy. Record 014 remains active where no policy exists.

New context

Enterprise research and sales evidence show that one universal default creates two opposite governance failures. Permission architecture can now enforce policy at creation.

New decision

Administrators may choose private, company-visible or creator-choice policy. The existing private default remains for organisations that make no selection.

Creators see the policy and its consequence before naming the workspace. They cannot select a visibility forbidden by the organisation.

What changed

The assumption that administrators did not need central control is no longer credible. The architecture can now support policy without duplicating permission logic.

Consequences

The product gains administrative control and implementation complexity. Support needs policy diagnostics. Migration must not silently expose existing private workspaces.

Record 014 now links to 027. Record 027 links back to 014. The old reasoning remains intact, while the current answer is unambiguous.

That is supersession. It is not a correction of embarrassing history.

Immutability needs nuance

A decision record should be stable enough that readers can trust what it said. It need not be technically impossible to edit.

Allow corrections for broken links, spelling or factual metadata, with version history. Do not rewrite context, evidence or reasoning after later events.

When the choice changes, create a new record and link the relationship:

• supersedes;
• superseded by;
• amends a bounded part;
• related but independent.

AWS recommends keeping records immutable after acceptance and creating a new record when a decision is reversed.

The GOV.UK public-sector framework instead tells teams to review and update records as context changes. Product teams need an explicit convention rather than blending the two silently.

Product teams can adopt the principle without copying every architecture field.

Store records where decisions are found

The perfect template in an abandoned wiki is useless. Put records in a searchable, versioned place already used by the people making the product.

Use stable identifiers such as PDR-014. Link them from the roadmap item, relevant product brief, technical record and research evidence.

Add metadata sparingly:

• status;
• date;
• owner;
• product area;
• affected customer or capability;
• review trigger;
• supersession links.

Avoid tags for every stakeholder and feature. Search improves when the title names the decision in ordinary language.

A record should be readable in a few minutes. If evidence is extensive, summarise its decision relevance and link to the source.

Use the record to improve the decision

The act of writing exposes weak reasoning before acceptance.

If the team cannot name alternatives, it may be ratifying the first idea. If it cannot state consequences, it may be selling rather than deciding.

If assumptions have no review triggers, “reversible” may mean “we hope somebody notices”. If authority is unclear, alignment may be masking a stalled decision.

This connects records to alignment techniques. Alignment is not universal agreement; it is shared understanding of the choice, rationale and obligations.

Records can also link product and engineering reasoning. A product permission choice may depend on an architectural boundary documented in system design.

Neither record should duplicate the other. Cross-link the decisions and keep each accountable to its own audience.

A template worth keeping

Use this only for choices that pass the admission test:

1. Title: the choice in one sentence.
2. Status and date: proposed, accepted, superseded or declined.
3. Owner and authority: who decides and who was consulted.
4. Context: problem, constraints and timing.
5. Decision: scope and effective boundary.
6. Alternatives: credible options and decisive trade-offs.
7. Evidence: links, relevance and visible limitations.
8. Assumptions: beliefs that make the decision rational.
9. Consequences: benefits, costs, risks and required work.
10. Review triggers: evidence or change that reopens it.
11. Relationships: records amended or superseded.

The template should make records easier to write, not turn them into compliance prose.

A product decision record earns its keep when a new colleague can say: “I understand why they chose this, I can see what has changed, and I know how to challenge it.”

That is institutional memory with an escape hatch.

Sources

• AWS Prescriptive Guidance: ADR process
• AWS Prescriptive Guidance: ADR best practices
• GOV.UK: Architectural Decision Record Framework

Read next

• The Product Leader’s Approach to Decision Framework
• Developing Your Executive Communication Skills
• How to Lead Through Alignment Techniques
• From Theory to Practice: System Design