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.
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. Der Leitfaden zur Präsentation von Nutzerforschung zeigt dir, wie du Beobachtungen mit einer Produktentscheidung verbindest, ohne eine kleine qualitative Stichprobe auf alle Nutzer zu übertragen.
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.
Die PRD-Anleitung von Atlassian hält Annahmen und ausgeschlossene Arbeiten ausdrücklich fest; auch offenes Verhalten sollte sichtbar bleiben.
Im Beispiel liegt eine Unterhaltung bereits in Warteschlange Q. In der ersten Version soll ein berechtigter Supportmitarbeiter die Verantwortung übernehmen können. Die folgenden Kriterien sind Vorschläge für ein fiktives Produkt, keine Presenti-Funktionen oder abgeschlossenen Tests. Automatisches Stimmungsrouting und die mobile App bleiben wie auf der Umfangsfolie ausgeschlossen.
| Situation und Aktion | Beobachtbares Ergebnis oder offene Entscheidung | Methode und verantwortliche Rolle |
|---|---|---|
| Eine Unterhaltung in Q ist noch nicht zugewiesen; eine für Q berechtigte Person weist sie sich selbst zu | Die Person erscheint als Verantwortliche; beim erneuten Öffnen bleibt die Zuordnung erhalten, und das Übergabeprotokoll nennt handelnde Person und Unterhaltung | QA testet mit einem berechtigten Konto, prüft gespeicherte Zuordnung und Übergabeprotokoll und legt das Ergebnis dem Product Owner vor |
| Eine Person ohne Berechtigung für Q versucht dieselbe Zuordnung, auch über eine direkte Anfrage außerhalb der normalen Oberfläche | Die Zuordnung wird verweigert; Verantwortlicher und Übergabeprotokoll bleiben unverändert, und die Antwort gibt keine geschützten Gesprächsinhalte preis | Die Sicherheitsleitung definiert den Negativtest; QA prüft Oberfläche und Anfragepfad sowie den unveränderten Zustand |
| Zwei berechtigte Personen sehen dieselbe nicht zugewiesene Unterhaltung und versuchen nahezu gleichzeitig die Zuordnung | Offene Regel: Wird die konkurrierende Zuordnung mit einem Aktualisierungshinweis abgewiesen, oder gilt eine andere vereinbarte Konfliktregel? Der letzte Schreibzugriff ist nicht automatisch genehmigtes Verhalten | Product Owner und Entwicklungsleitung vereinbaren Regel und Rückmeldung, bevor QA einen wiederholbaren Parallelitätstest erstellt |
Die parallele Zuordnung kann nicht abgenommen werden, solange ihr erwartetes Ergebnis offen ist. Halte Regel, Entscheider und Review-Termin im Entscheidungsprotokoll fest und aktualisiere PRD und Folie gemeinsam. Ein ausgeblendetes Bedienelement belegt keine wirksame Berechtigungsprüfung; teste auch den direkten Anfragepfad. Bewahre Testergebnisse beim jeweiligen Kriterium auf, statt die vorgeschlagene Matrix als Testbericht auszugeben.
Ordne jedem Kriterium eine Priorität und bekannte Abhängigkeiten zu, damit das Team erkennt, welche Bedingungen die Freigabe bestimmen.
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 das 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.
Eine Abhängigkeit ist nicht automatisch ein Hindernis. Halte Status, Verantwortlichen und nächste Aktion fest; ohne benannten Verantwortlichen gehört sie in den Risiko- oder Entscheidungsteil.
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. Die Folien ersetzen weder die vollständige Spezifikation noch die Umsetzung. Unterscheide im Protokoll bestätigte Review-Ergebnisse von weiterhin vorgeschlagenen Anforderungen.
