Eine Produktanforderungs-Präsentation ist kein kopierter PRD. Sie bringt die wenigen Punkte nach vorn, die ein Review braucht: Problem, Umfang, Nicht-Ziele, Akzeptanzkriterien und offene Entscheidungen. Mit Text zu Präsentation kannst du aus einer geprüften Gliederung einen ersten editierbaren Entwurf machen; die Anforderungen und Grenzen müssen trotzdem aus deinem PRD kommen.
Problem und Ziel schärfen
Beginne mit dem Nutzerproblem und der Entscheidung, die im Review fallen soll. Führe die relevante Evidenz an, zum Beispiel beobachtete Nutzung oder Support-Muster, ohne daraus eine größere Sicherheit abzuleiten, als die Daten tragen. Ein Ziel beschreibt die gewünschte Veränderung, nicht schon die technische Lösung.
Umfang und Nicht-Ziele trennen
Liste die enthaltenen Anwendungsfälle und die bewusst ausgeschlossenen Fälle getrennt. Nicht-Ziele schützen den Review vor stiller Ausweitung. Markiere Annahmen und offene Fragen, statt sie als feststehende Anforderungen zu formulieren.
Akzeptanzkriterien prüfbar schreiben
Formuliere Kriterien als beobachtbares Ergebnis: wer kann was unter welcher Bedingung tun, und woran wird es geprüft? Vermeide unmessbare Wörter wie „einfach“ oder „schnell“, wenn kein Prüfmaßstab folgt. Verknüpfe jedes Kriterium mit einer Priorität und einer offenen Abhängigkeit.
Abhängigkeiten und Risiken zeigen
Zeige Schnittstellen, Datenquellen, rechtliche Prüfungen und Entscheidungen anderer Teams. Eine Abhängigkeit ist nicht automatisch ein Blocker; kennzeichne Status, Besitzer und nächste Aktion. Liefere keine ungeprüften Liefertermine als Zusage.
Ein Entscheidungsprotokoll einbauen
Beende den Foliensatz mit einer kleinen Tabelle: Entscheidung, Optionen, Empfehlung, Begründung, Besitzer und Termin. Trenne beschlossen, vorgeschlagen und noch zu klären. So bleibt nach dem Meeting sichtbar, was tatsächlich vereinbart wurde.
Bewährter Aufbau für das Review
- Problem, Ziel und Review-Frage
- Zielgruppe und belegter Kontext
- Umfang und Nicht-Ziele
- Anforderungen und Akzeptanzkriterien
- Abhängigkeiten, Risiken und Annahmen
- Offene Entscheidungen und nächste Schritte
Halte pro Folie eine Entscheidung oder einen Nachweis im Mittelpunkt. Die Präsentation soll den Review verkürzen, nicht den gesamten PRD ersetzen.
Grenzen des Formats
Die Präsentation ist eine Entscheidungsoberfläche. Sie ersetzt weder die vollständige Spezifikation noch die technische Umsetzung. Bewahre die Verbindung zum PRD, kennzeichne Änderungen und aktualisiere nur die Aussagen, die im Review wirklich bestätigt wurden.
Die Review-Frage zuerst nennen
Eröffne mit einem Satz wie „Den Umfang der ersten Version für den gemeinsamen Posteingang freigeben“. Ergänze Entscheider, gewünschtes Datum und das Nutzer- oder Geschäftsproblem. Ein Projektname allein zeigt nicht, ob die Präsentation die richtige Frage beantwortet.
Beschreibe das Problem mit beobachteter Evidenz und einer Grenze. Trenne Nutzerbedarf von Lösungsidee: „Support verliert Kontext beim Wechsel der Warteschlange“ ist ein Problem; „einen neuen Routingdienst bauen“ ist eine Hypothese. Die erste Folie soll auch später hinzukommenden Personen Entscheidung, Empfehlung, Umfang und offenes Risiko zeigen.
Den Umfang in Ebenen zeigen
Teile die Lieferung in enthalten, ausgeschlossen und verschoben. Enthaltene Punkte beschreiben Verhalten oder beobachtbares Ergebnis. Ein Beispiel für einen gemeinsamen Posteingang wäre die Zuordnung zu einer Warteschlange, sichtbarer Besitzer und protokollierte Übergabe; automatisches Stimmungsrouting und eine mobile App könnten außerhalb liegen. Das sind Illustrationen, keine zugesagten Funktionen.
Wenn Anforderungen kollidieren, zeige den Zielkonflikt. Eine schnellere erste Version unterstützt vielleicht nur einen Identitätsanbieter, während eine spätere Phase weitere ergänzt. Benenne Folge und Person, die diesen Kompromiss akzeptieren muss.
Den kleinsten sinnvollen Nutzerfluss erklären
Wähle einen Hauptfluss: Auslöser, wichtige Entscheidungen und erwartetes Ergebnis. Randfälle bleiben getrennt, bis der Hauptweg verstanden ist. Pro Schritt gehören benötigte Information, Nutzeraktion und Rückmeldung auf die Folie. Markiere Richtlinien und externe Dienste als Abhängigkeiten und erfinde keine Bedienelemente nur für eine vollständige Optik.
Zeige Barrierefreiheit und Fehlerverhalten dort, wo sie die Anforderung ändern: Was passiert bei Ablehnung, fehlender Verbindung oder fehlender Berechtigung? Ein Ablauf, der nur im Erfolgsfall funktioniert, ist keine vollständige Anforderung.
Akzeptanzkriterien prüfen
Formuliere „gegeben“, „wenn“, „dann“ als beobachtbares Verhalten. Gruppiere funktionale, qualitative und betriebliche Kriterien. Verknüpfe riskante Kriterien mit einer Prüfart wie automatisiertem Test, Usability-Session, Sicherheitsprüfung oder Lasttest. Die Prüfart ist kein Erfolgsbeweis, sondern die gemeinsam vereinbarte Kontrolle vor der Freigabe.
Abhängigkeiten und Alternativen einordnen
Liste Identitätsanbieter, Datenmigration, Rechtsprüfung, Designsystem oder fremde APIs mit Besitzer und Status. Zeige im Zeitplan nur die für die Review nötigen Integrations- und Testpunkte; unsichere Schätzungen sind keine Zusage. Bei Alternativen vergleiche Lernzeit, Umkehrbarkeit, Nutzerrisiko und Wartungsaufwand und nenne die Kriterien, die eine Option besser machen.
Mit einer protokollierbaren Freigabe schließen
Bitte um Freigabe des genannten Umfangs, Freigabe mit Bedingungen oder Rückgabe für eine konkrete Änderung. Ergänze einen kurzen Entscheidungslog mit Freigaben, Ausschlüssen, Besitzer und nächstem Termin. Wenn Evidenz fehlt, schlage eine Discovery-Aufgabe oder einen Prototyp mit Lernziel vor. Sende die Präsentation zusammen mit dem PRD und Versionsdatum, damit später nachvollziehbar bleibt, was bekannt, gewählt und offen war.
