Product Decision Record: Produktentscheidungen dokumentieren, die das Unternehmen strukturieren

Bestimmte Produktentscheidungen tauchen überall auf.

Sie tauchen im Roadmap-Komitee auf. Sie tauchen im Vertrieb auf. Sie tauchen im Support auf. Sie tauchen in den Spezifikationen auf. Sie tauchen in Tickets auf. Sie tauchen bei jedem neuen großen Kunden auf, bei jeder neuen Gelegenheit, bei jedem etwas sichtbaren Grenzfall.

Soll man auf einem Marketplace den Kunden oder den Anbieter bevorzugen?

Soll das Produkt in alle Sprachen übersetzt werden, die Prospects verlangen?

Soll man eine Ausnahme für ein Segment akzeptieren, das viel einbringen könnte?

Soll man einen Bereich öffnen, wenn das Produkt ihn noch nicht korrekt abdecken kann?

Diese Fragen sind keine Features. Sie sind keine Tickets. Sie sind keine Ausführungsdetails. Sie sind strukturierende Entscheidungen.

Und wenn sie nicht klar dokumentiert sind, trifft das Unternehmen sie immer wieder neu.

Manchmal mit denselben Personen. Manchmal mit anderen. Manchmal mit weniger Kontext. Manchmal unter kommerziellem Druck. Manchmal in Eile. Manchmal mit einer lückenhaften Erinnerung daran, was bereits entschieden worden war.

Das Problem ist nicht nur der Zeitverlust. Das Problem ist der Verlust an Kohärenz.

Eine wichtige Produktentscheidung darf nicht von der mündlichen Erinnerung derer abhängen, die im Meeting waren.

Genau das ist die Aufgabe eines Product Decision Records.

Die Inspiration: ADRs auf der technischen Seite

Technische Teams kennen bereits eine ähnliche Praxis: die ADRs, Architecture Decision Records.

Ein ADR ist ein kurzes Dokument, das eine Architekturentscheidung festhält. Es erklärt den Kontext, die in Betracht gezogenen Optionen, die getroffene Entscheidung und ihre Konsequenzen.

Der Nutzen ist einfach: Mehrere Monate oder Jahre später kann eine Person verstehen, warum eine technische Wahl getroffen wurde.

Nehmen wir ein Beispiel.

Eine Anwendung erfährt einen Lastanstieg. Die Kunden werden mehr. Die Anfragen nehmen zu. Verlangsamungen werden häufig. Das Team entscheidet sich dann, eine Warteschlangen-Technologie einzuführen, um bestimmte Nachrichten asynchron zu verarbeiten.

Diese Wahl ist keine Feature.

Einen Monat lang werden die Entwickler vielleicht an einem rein technischen Projekt arbeiten. Sie müssen sich schulen. Sie müssen einen Teil der Architektur ändern. Sie liefern dem Endnutzer keinen sofort sichtbaren Geschäftswert.

Aber diese Entscheidung kann einen wichtigen Engpass beseitigen. Sie kann es ermöglichen, das Zehnfache, Zwanzigfache oder Dreißigfache der aktuellen Last durch Hinzufügen von Servern zu bewältigen. Sie kann auch den Vertrieb entlasten, der neue Kundenzugänge verkaufen kann, ohne zu befürchten, dass die Anwendung einfriert.

Ein ADR ermöglicht es, diese Entscheidung zu dokumentieren.

Warum wurde sie getroffen? Welche Optionen wurden verworfen? Welche Konsequenzen werden akzeptiert? Was ermöglicht sie? Was schränkt sie ein?

Der Product Decision Record übernimmt diese Logik, aber auf der Produktseite.

Ein PDR ist keine Feature-Entscheidung

Ein Product Decision Record dokumentiert eine strukturierende Produktentscheidung.

Keine Gelegenheit.

Keine Jira-Karte.

Keine Spezifikation.

Keine Feature.

Ein PDR hält eine Entscheidungsregel fest, die das Unternehmen übernimmt und die mehrere zukünftige Produkte, Teams oder Situationen leiten wird.

Er sagt nicht: „Hier ist die zu bauende Funktionalität."

Er sagt eher: „In dieser Art von Situation ist das die Regel, die wir anwenden."

Das ist ein wichtiger Unterschied.

Wenn man PDRs verwendet, um jeden lokalen Arbitragefall zu dokumentieren, wird das Werkzeug zur Bürokratie. Es verliert seine Wirkung. Ein guter PDR muss eine Entscheidung betreffen, die strukturierend genug ist, um Dutzende von Neudiskussionen zu vermeiden.

Sein Wert liegt in seiner Seltenheit.

Ein Unternehmen sollte keine fünfzig PDRs pro Quartal produzieren. Einige wenige pro Jahr genügen. Fünf, zehn, fünfzehn, maximal zwanzig, je nach Größe und Komplexität der Organisation.

Ein PDR muss wichtig genug sein, um im Gedächtnis zu bleiben oder schnell gefunden zu werden, wenn eine Frage wieder auftaucht.

Beispiel: Marketplace, Kunde oder Anbieter?

Auf einem Marketplace gibt es eine strukturelle Spannung.

Wenn ein Konflikt entsteht, soll man den Kunden oder den Anbieter bevorzugen?

Man kann versuchen, beides zu tun. Man kann jedes Mal einen Kompromiss suchen. Man kann jeden Fall als Ausnahme behandeln. Aber in vielen Situationen muss man sich entscheiden.

Wenn das Unternehmen diese Entscheidung nicht dokumentiert, läuft jedes Team Gefahr, sie auf seine eigene Weise zu interpretieren.

Der Support will vielleicht die Kundenbeziehung schützen.

Das Partnerships-Team will vielleicht die Anbieter schützen.

Das Produkt will vielleicht die Regeln nicht verkomplizieren.

Der Vertrieb wird die Option pushen, die dem aktuell strategischsten Account hilft.

Und bei jedem Konflikt kommt dieselbe Frage zurück.

Ein PDR ermöglicht es, eine Richtlinie festzulegen:

Im Konfliktfall bevorzugen wir den Kunden.

Diese Entscheidung beschreibt keine Feature. Sie beschreibt nicht einmal einen genauen Workflow. Aber sie wird Dutzende von Entscheidungen beeinflussen: Erstattungsregeln, Streitbeilegungsrichtlinien, Support-Nachrichten, Produktprioritäten, operative Arbitragen, Kundenkommunikation.

Das ist genau das richtige Niveau für einen PDR.

Er dokumentiert eine übergreifende Entscheidung.

Er macht die Wahl explizit.

Er ermöglicht es den Teams, voranzukommen, ohne die Debatte bei jedem Grenzfall wieder zu öffnen.

Beispiel: Sprachen in einem SaaS

Nehmen wir einen anderen Fall, der in SaaS-Unternehmen sehr häufig vorkommt.

Die Vertriebsteams wollen in mehreren Ländern verkaufen. Ein deutscher Prospect verlangt eine Oberfläche auf Deutsch. Ein spanischer Prospect verlangt Spanisch. Ein großer italienischer Kunde verlangt Italienisch. Jede Gelegenheit scheint interessant.

Aber auf der Produktseite besteht das Übersetzen einer Anwendung nicht nur darin, Text zu ersetzen.

Man muss die Oberfläche übersetzen. Die Übersetzungen pflegen. Die Bildschirme testen. Die Dokumentation anpassen. Den Support schulen. E-Mails verwalten. Automatische Nachrichten prüfen. Änderungen verfolgen. Verhindern, dass einige Sprachen zu degradierten Versionen des Produkts werden.

Ohne eine klare Entscheidung kann jeder neue Prospect das Thema wieder aufwerfen.

Ein PDR kann die Regel festlegen.

# PDR 004 — Standardmäßig unterstützte Sprachen

## Status
Validiert

## Entscheidung
Das Produkt wird standardmäßig auf Französisch und Englisch unterstützt. Jede weitere Sprache erfordert einen Mindestschwellenwert an unterzeichnetem Jahresumsatz.

## Kontext
Die Vertriebsteams stoßen in mehreren Ländern auf Möglichkeiten. Jede Sprache fügt Kosten für Übersetzung, Wartung, Support, Dokumentation und Produktqualität hinzu.

## Berücksichtigte Alternativen
- Alle angeforderten Sprachen übersetzen: zu kostspielig und schwer zu pflegen.
- Nur Französisch unterstützen: zu einschränkend für die kommerzielle Entwicklung.
- Französisch und Englisch standardmäßig unterstützen, dann andere Sprachen unter Bedingungen öffnen.

## Getroffene Entscheidung
Französisch und Englisch werden standardmäßig unterstützt. Andere Sprachen werden nur geöffnet, wenn unterzeichnete Verträge einen definierten Schwellenwert überschreiten.

## Konsequenzen
- Bessere Qualitätskontrolle.
- Weniger schwer einzuhaltende kommerzielle Versprechen.
- Einige kommerzielle Möglichkeiten werden abgelehnt oder aufgeschoben.

## Bedingungen für eine Neubewertung
Die Entscheidung wird neu bewertet, wenn KI die Übersetzungskosten deutlich senkt und dabei ein akzeptables Qualitätsniveau beibehält, oder wenn ein neues strategisches Segment eine Sprache erfordert.

Dieser PDR schließt das Thema nicht endgültig.

Er gibt eine aktuelle Regel.

Er ermöglicht es dem Vertrieb zu wissen, was er verkaufen kann. Er ermöglicht es dem Produkt, Anfragen abzulehnen, ohne die gesamte Argumentation zu wiederholen. Er ermöglicht es der Führungsebene, die tatsächlichen Kosten einer sprachlichen Öffnung zu verstehen.

Und er enthält eine Bedingung für die Neubewertung.

Wenn KI zuverlässige Übersetzungen zu niedrigen Kosten ermöglicht, kann sich die Entscheidung ändern. Wenn ein neues strategisches Segment eine Sprache erfordert, kann sich die Entscheidung ändern. Wenn mehrere unterzeichnete Verträge die Investition rechtfertigen, kann sich die Entscheidung ändern.

Aber wenn sie sich ändert, schreibt man den alten PDR nicht um.

Man erstellt einen neuen.

Was einen PDR verdient

Nicht alle Produktentscheidungen verdienen einen PDR.

Das ist sogar der wichtigste Punkt.

Ein PDR muss selten bleiben. Sonst wird er zu einer weiteren Form von Dokumentation, die niemand liest.

Eine Entscheidung verdient wahrscheinlich einen PDR, wenn sie übergreifend, strukturierend, dauerhaft, kostspielig rückgängig zu machen, anfällig für Neudiskussionen, für mehrere Teams nützlich und wichtig genug ist, um mehrere zukünftige Entscheidungen zu beeinflussen.

Umgekehrt verdient eine Entscheidung wahrscheinlich keinen PDR, wenn sie lokal, punktuell, an eine einzige Feature gebunden, bereits durch eine bestehende Regel abgedeckt, ohne dauerhafte Konsequenzen oder zu offensichtlich für eine Neudiskussion ist.

Der Test ist einfach:

Wenn die Entscheidung keine zukünftige Neudiskussion vermeiden wird, braucht sie wahrscheinlich keinen PDR.

Ein PDR ist nicht dazu da, alles zu dokumentieren, was der Product Manager entscheidet.

Er ist dazu da, die Entscheidungen zu dokumentieren, die den Rahmen strukturieren, in dem Product Manager, Vertrieb, Support, Betrieb und manchmal die Führungsebene dann ihre lokalen Entscheidungen treffen.

Ein kurzes, strukturiertes, ausreichendes Format

Ein PDR muss kurz bleiben.

Das Format dient dazu, Vergessen zu vermeiden, nicht dazu, eine bürokratische Akte zu erstellen.

Ein nützliches Template kann so aussehen:

# PDR <Nummer> — <Titel>

## Status
Vorgeschlagen | Validiert | Ersetzt durch PDR <Nummer> | Aufgegeben

## Datum
YYYY-MM-DD

## Entscheidung
Ein klarer Satz.

## Kontext
Warum diese Entscheidung jetzt notwendig ist.

## Berücksichtigte Alternativen
- Option A: ...
- Option B: ...
- Option C: ...

## Getroffene Entscheidung
Was das Unternehmen wählt.

## Gründe für die Wahl
- ...
- ...

## Konsequenzen
### Positive
- ...

### Negative
- ...

### Risiken
- ...

## Bedingungen für eine Neubewertung
Was einen neuen PDR rechtfertigen könnte.

## Entscheidungsträger und konsultierte Personen
- Entscheidungsträger:
- Konsultiert:

## Referenzen
- ...

Der genaue Inhalt kann variieren.

Aber das Wesentliche muss immer vorhanden sein: der Kontext, die Entscheidung, die Alternativen, die Gründe für die Wahl, die Konsequenzen, die Entscheidungsträger und was die Entscheidung verändern könnte.

Der PDR darf kein PRD werden.

Er darf nicht die gesamte Ausführung beschreiben.

Er muss das Warum dokumentieren.

Die Geschichte wird nicht umgeschrieben

Ein validierter PDR wird nicht gelöscht.

Er wird nicht umgeschrieben, um eine Positionsänderung zu verbergen.

Wenn die Entscheidung geändert werden muss, erstellt man einen neuen PDR, der den alten ersetzt.

Das ist wesentlich.

Der PDR ist nicht dazu da, zu beweisen, dass das Unternehmen immer Recht hatte. Er ist dazu da, zu verstehen, warum es zu einem bestimmten Zeitpunkt das entschieden hat, was es entschieden hat.

Im Sprachenbeispiel kann der erste PDR sagen: standardmäßig nur Französisch und Englisch, andere Sprachen unter Bedingung eines unterzeichneten Umsatzes.

Zwei Jahre später kann KI die Übersetzungskosten verändern. Die Qualität kann ausreichend werden. Der Support kann sich besser ausrüsten. Das Produkt kann entscheiden, dass sekundäre Sprachen fortan automatisch übersetzt werden, mit menschlicher Überprüfung bei kritischen Prozessen.

Das ist kein Widerspruch.

Das ist eine neue Entscheidung in einem neuen Kontext.

Der alte PDR bleibt nützlich, weil er erklärt, warum das Unternehmen anfangs abgelehnt hatte, überall zu übersetzen. Der neue PDR erklärt, warum diese Ablehnung nicht mehr angemessen ist.

Diese Nachvollziehbarkeit verhindert Produktamnesie.

Sie verhindert auch absurde interne Prozesse: „Warum haben wir das nicht früher gemacht?" Vielleicht weil früher die Kosten, die Qualität, die Ressourcen und der kommerzielle Kontext es nicht erlaubten, es korrekt zu tun.

PDR, PRD, Roadmap, Backlog: nicht vermischen

Ein PDR ist kein PRD.

Ein PRD beschreibt, was man bauen will.

Ein PDR erklärt, warum das Unternehmen eine Entscheidungsregel gewählt hat.

Eine Roadmap zeigt, was das Unternehmen in einem gegebenen Horizont tut, vorbereitet, in Betracht zieht oder ablehnt.

Ein Backlog organisiert die ausführbare oder bald ausführbare Arbeit.

Ein Ticket zerlegt eine operative Aktion.

Der PDR steht am Anfang.

Er kann eine Roadmap beeinflussen. Er kann ein PRD einschränken. Er kann erklären, warum bestimmte Tickets existieren oder nicht. Aber er ersetzt sie nicht.

Genau weil er auf diesem Niveau bleibt, ist er nützlich.

Wenn ein PDR zu tief geht, wird er zu einer verkleideten Spezifikation.

Wenn eine Roadmap versucht, die Rolle eines PDRs zu übernehmen, vermischt sie Kommunikation und Entscheidungsregel.

Wenn ein Ticket eine strukturierende Entscheidung trägt, macht es sie für den Rest des Unternehmens unsichtbar.

Jedes Werkzeug muss auf seinem Niveau bleiben.

Der PDR ist keine Bürokratie

Man kann PDRs leicht falsch verwenden.

Man kann zu viele erstellen. Sie zu lang machen. Sie zu Protokollen umwandeln. Sie zur Absicherung nutzen. Sie von zu vielen Personen validieren lassen. Sie nachträglich schreiben, um eine bereits auferlegte Entscheidung zu rechtfertigen.

In diesem Fall, ja, wird der PDR zur Bürokratie.

Aber das ist nicht sein normaler Gebrauch.

Ein guter PDR beseitigt Bürokratie.

Er vermeidet, dieselbe Erklärung fünfzigmal zu wiederholen.

Er vermeidet, dieselbe Abwägung bei jedem großen Prospect wieder zu öffnen.

Er vermeidet, von der Erinnerung einer Person abhängig zu sein.

Er verhindert, dass Teams zwischen impliziten Regeln, unausgesprochenen Ausnahmen und widersprüchlichen Entscheidungen navigieren.

Dokumentation ist nicht das Problem.

Schlechte Dokumentation ist das Problem.

Ein kurzer, seltener, klarer und unveränderlicher PDR belastet die Organisation nicht. Er gibt ihr eine Entscheidungssäule.

Fazit

Einem Produktunternehmen fehlt nicht nur an Prioritäten.

Oft fehlt es an Erinnerung an seine Entscheidungen.

Es weiß, was es getan hat, aber nicht immer, warum es es getan hat. Es erinnert sich an eine Schlussfolgerung, aber nicht an den Kontext. Es wendet eine Regel lokal an und vergisst sie dann anderswo. Es öffnet eine Diskussion wieder, weil niemand die ursprüngliche Abwägung findet.

Der Product Decision Record dient dazu, das zu vermeiden.

Er verwandelt eine implizite Entscheidung in eine explizite Regel.

Er dokumentiert die Produktentscheidungen, die das Unternehmen strukturieren.

Er ermöglicht es zu sagen: „Wir haben dieses Thema bereits entschieden. Hier ist das Warum. Hier sind die Konsequenzen, die wir akzeptieren. Hier sind die Bedingungen, die uns dazu bringen könnten, uns zu ändern."

Ein guter PDR fügt keine Dokumentationsschicht hinzu.

Er beseitigt Dutzende unnötiger Diskussionen.

Mehr dazu

Warum Organisationen weiche Entscheidungen bevorzugen Der PM als Kontext-Architekt Werkzeuge für organisationale Kohärenz Die Produktfrage muss vom Quellcode ausgehen