Certain product decisions come up everywhere.

They come up in roadmap reviews. They come up with sales. They come up in support. They come up in specs. They come up in tickets. They come up with every new big client, every new opportunity, every edge case that gets a bit of visibility.

Should you favour the customer or the supplier on a marketplace?

Should you translate the product into every language prospects ask for?

Should you make an exception for a segment that could bring in a lot?

Should you open up a scope when the product can't yet handle it properly?

These questions aren't features. They aren't tickets. They aren't execution details. They are structuring decisions.

And when they aren't documented clearly, the company keeps re-deciding them.

Sometimes with the same people. Sometimes with others. Sometimes with less context. Sometimes under commercial pressure. Sometimes in a hurry. Sometimes with only a partial memory of what had already been settled.

The problem isn't just the wasted time. The problem is the loss of consistency.

An important product decision shouldn't depend on the spoken memory of whoever happened to be in the meeting.

That is precisely the role of a Product Decision Record.

The inspiration: ADRs on the technical side

Engineering teams already know a close cousin: ADRs, for Architecture Decision Records.

An ADR is a short document that traces an architecture decision. It explains the context, the options considered, the decision made and its consequences.

The benefit is simple: several months or several years later, someone can understand why a technical choice was made.

Let's take an example.

An application is hitting a load ceiling. There are more clients. Queries are increasing. Slowdowns are becoming frequent. The team decides to introduce a queueing technology to process certain messages asynchronously.

This choice isn't a feature.

For a month, the developers might work on a purely technical effort. They'll have to train up. They'll have to rework part of the architecture. They won't immediately ship any visible business value for the end user.

But this decision can remove a major bottleneck. It can make it possible to absorb ten, twenty or thirty times the current load simply by adding servers. It can also free up sales, who will be able to sell new client access without fearing that the application will freeze.

An ADR makes it possible to document this decision.

Why was it made? Which options were ruled out? Which consequences are we accepting? What does it enable? What does it constrain?

The Product Decision Record follows the same logic, but on the product side.

A PDR is not a feature decision

A Product Decision Record documents a structuring product decision.

Not an opportunity.

Not a Jira card.

Not a spec.

Not a feature.

A PDR traces a decision rule that the company owns and that will guide several products, teams or future situations.

It doesn't say: "here is the feature to build".

It says instead: "in this kind of situation, here is the rule we apply".

That's an important distinction.

If you use PDRs to document every local trade-off, the tool turns into paperwork. It loses its force. A good PDR has to bear on a decision structuring enough to prevent dozens of re-discussions.

Its value comes from its rarity.

A company shouldn't produce fifty PDRs a quarter. A few a year are enough. Five, ten, fifteen, twenty at most depending on the size and complexity of the organisation.

A PDR has to be important enough to be kept in mind, or found quickly when a question comes back around.

Example: marketplace, customer or supplier?

On a marketplace, there is a structural tension.

When a conflict arises, should you favour the customer or the supplier?

You can try to do both. You can look for a compromise every time. You can treat each case as an exception. But in many situations, you do have to choose.

If the company doesn't document this decision, each team is liable to interpret it its own way.

Support may want to preserve the customer relationship.

The partnerships team may want to protect the suppliers.

Product may want to avoid making the rules more complex.

Sales may push whichever option helps the most strategic account of the moment.

And with every conflict, the same question will come back.

A PDR makes it possible to set a guiding line:

In the event of a conflict, we favour the customer.

This decision doesn't describe a feature. It doesn't even describe a precise workflow. But it will shape dozens of decisions: refund rules, dispute policies, support messages, product priorities, operational trade-offs, customer communication.

That's exactly the right level for a PDR.

It documents a cross-cutting decision.

It makes the choice explicit.

It lets teams move forward without reopening the debate at every edge case.

Example: languages in a SaaS

Let's take another case, very common in SaaS companies.

The sales teams want to sell in several countries. A German prospect asks for a German interface. A Spanish prospect asks for Spanish. A large Italian account asks for Italian. Every opportunity looks appealing.

But on the product side, translating an application isn't just about swapping out text.

You have to translate the interface. Maintain the translations. Test the screens. Adapt the documentation. Train support. Handle the emails. Check the automated messages. Track the changes. Keep some languages from becoming degraded versions of the product.

Without a clear decision, every new prospect can reopen the topic.

A PDR can set the rule.

# PDR 004 — Languages supported by default

## Status
Approved

## Decision
The product is supported by default in French and English. Any other language requires a minimum threshold of signed annual revenue.

## Context
The sales teams encounter opportunities in several countries. Each language adds a cost of translation, maintenance, support, documentation and product quality.

## Alternatives considered
- Translate every language requested: too costly and hard to maintain.
- Support French only: too limiting for commercial development.
- Support French and English by default, then open up the other languages under conditions.

## Decision made
French and English are supported by default. Other languages are opened up only if signed contracts exceed a defined threshold.

## Consequences
- Better control of quality.
- Fewer commercial promises that are hard to keep.
- Some commercial opportunities will be turned down or deferred.

## Conditions for reassessment
The decision will be reassessed if AI sharply reduces the cost of translation while maintaining an acceptable level of quality, or if a new strategic segment requires a language.

This PDR doesn't close the topic for good.

It gives a current rule.

It lets sales know what they can sell. It lets product turn down requests without rebuilding the whole argument. It lets management understand the real cost of adding a language.

And it contains a condition for reassessment.

If AI makes reliable, low-cost translations possible, the decision can change. If a new strategic segment requires a language, the decision can change. If several signed contracts justify the investment, the decision can change.

But if it changes, you don't rewrite the old PDR.

You create a new one.

What deserves a PDR

Not every product decision deserves a PDR.

That's actually the most important point.

A PDR has to stay rare. Otherwise it becomes just one more form of documentation that nobody reads.

A decision probably deserves a PDR if it's cross-cutting, structuring, durable, costly to reverse, likely to be re-discussed, useful to several teams, and important enough to shape several future decisions.

Conversely, a decision probably doesn't deserve a PDR if it's local, one-off, tied to a single feature, already covered by an existing rule, without lasting consequences, or too obvious to be re-discussed.

The test is simple:

If the decision won't prevent any future re-discussion, it probably doesn't need a PDR.

A PDR isn't there to document everything the Product Manager decides.

It's there to document the choices that shape the framework within which Product Managers, sales, support, operations and sometimes management will then make local decisions.

A short, structured, sufficient format

A PDR has to stay short.

The format is there to prevent oversights, not to produce a bureaucratic file.

A useful template might look like this:

# PDR <number> — <title>

## Status
Proposed | Approved | Superseded by PDR <number> | Abandoned

## Date
YYYY-MM-DD

## Decision
One clear sentence.

## Context
Why this decision is needed now.

## Alternatives considered
- Option A: ...
- Option B: ...
- Option C: ...

## Decision made
What the company chooses.

## Reasons for the choice
- ...
- ...

## Consequences
### Positive
- ...

### Negative
- ...

### Risks
- ...

## Conditions for reassessment
What could justify a new PDR.

## Decision-makers and people consulted
- Decision-maker:
- Consulted:

## References
- ...

The exact content can vary.

But the essentials must always be there: the context, the decision, the alternatives, the reasons for the choice, the consequences, the decision-makers, and what could make the decision evolve.

The PDR mustn't turn into a PRD.

It mustn't describe the whole execution.

It has to document the why.

You don't rewrite history

An approved PDR is not erased.

It isn't rewritten to hide a change of position.

If the decision needs to change, you create a new PDR that supersedes the old one.

This is essential.

The PDR isn't there to prove the company was always right. It's there to understand why it decided what it decided at a given moment.

In the languages example, the first PDR might say: French and English only by default, other languages subject to signed revenue.

Two years later, AI may change the cost of translation. Quality may become good enough. Support may equip itself. Product may decide that secondary languages will now be translated automatically, with human review on critical journeys.

That isn't a contradiction.

It's a new decision in a new context.

The old PDR stays useful, because it explains why the company had initially refused to translate everything. The new PDR explains why that refusal no longer fits.

This traceability prevents product amnesia.

It also prevents absurd internal trials: "Why didn't we do this before?" Maybe because, before, the cost, the quality, the resources and the commercial context didn't make it possible to do it properly.

PDR, PRD, roadmap, backlog: don't mix them up

A PDR is not a PRD.

A PRD describes what you want to build.

A PDR explains why the company chose a decision rule.

A roadmap shows what the company is doing, preparing, considering or declining within a given horizon.

A backlog organises work that is executable, or soon executable.

A ticket breaks down an operational action.

The PDR sits upstream.

It can shape a roadmap. It can constrain a PRD. It can explain why certain tickets exist or don't exist. But it doesn't replace them.

It's precisely because it stays at this level that it's useful.

If a PDR goes too low, it becomes a disguised spec.

If a roadmap tries to play the role of a PDR, it mixes communication and decision rule.

If a ticket carries a structuring decision, it makes that decision invisible to the rest of the company.

Each tool has to stay at its level.

The PDR is not paperwork

It's easy to misuse PDRs.

You can create too many. Make them too long. Turn them into meeting minutes. Use them to cover yourself. Have them approved by too many people. Write them after the fact to justify a decision already imposed.

In that case, yes, the PDR becomes paperwork.

But that isn't its normal use.

A good PDR removes paperwork.

It saves you from repeating the same explanation fifty times.

It saves you from reopening the same trade-off with every big prospect.

It saves you from depending on one person's memory.

It saves teams from navigating between implicit rules, unspoken exceptions and contradictory decisions.

Documentation isn't the problem.

Bad documentation is the problem.

A PDR that is short, rare, clear and immutable doesn't weigh the organisation down. It gives it a decisional backbone.

Conclusion

A product company doesn't just lack priorities.

It often lacks memory of its decisions.

It knows what it did, but it doesn't always remember why it did it. It remembers a conclusion, but not the context. It applies a rule locally, then forgets it elsewhere. It reopens a discussion because nobody can find the original ruling.

The Product Decision Record is there to prevent that.

It turns an implicit decision into an explicit rule.

It documents the product choices that shape the company.

It makes it possible to say: "We've already settled this. Here's why. Here are the consequences we accept. Here are the conditions that could make us change."

A good PDR doesn't add a layer of documentation.

It removes dozens of pointless discussions.

Pour en savoir plus

Why Organizations Prefer Soft Decisions The PM as Architect of Context The Tools of Organizational Coherence The product question should start from the source code