Du hast heute Morgen eine Notion-Seite geöffnet mit dem Titel „PRD: [Feature-Name]“. Drei Stunden später steht da immer noch „PRD: [Feature-Name]“.
Du kennst das Problem. Du kennst die Lösung. Du hast deinem Engineering Lead gestern zweimal alles erklärt. Aber sobald du dich hinsetzt, um es aufzuschreiben, klemmst du.
Das ist kein Denkproblem. Das ist ein Tippproblem.
PMs werden nicht fürs Tippen bezahlt. Du wirst dafür bezahlt, Entscheidungen darüber zu treffen, was gebaut wird und warum. Das PRD ist nur das Artefakt, das die Entscheidung festhält, damit Engineering, Design und Leadership handeln können. Irgendwo zwischen „Ich weiß, was ich schreiben will“ und „Doc fertig“ verschwinden Stunden.
Es gibt einen schnelleren Weg. Das PRD ist eines der voice-freundlichsten Dokumente, die ein PM schreibt. Im Grunde ist es das, was du am Whiteboard sagen würdest, wenn du das Feature erklärst. Sobald du aufhörst, PRDs zu tippen, und anfängst, sie zu diktieren, sinkt deine Entwurfszeit deutlich.
Die PM-Schreibsteuer, über die niemand redet
Jedes PRD, das du schreibst, konkurriert mit einem Meeting, einem Roadmap-Review, einem Stakeholder-Thread in Slack. Das eigentliche Schreiben passiert in geklauten halben Stunden oder nach dem Abendessen.
Die Rechnung ist brutal. Ein durchschnittlicher Mensch tippt etwa 40 Wörter pro Minute. Ein durchschnittlicher Mensch spricht rund 150. Das sind grob 3,5-mal so viel, bevor man die Reibung mitrechnet, die das Schreiben zusätzlich verlangsamt: Löschen, Umformulieren, einen Satz dreimal hinterfragen, bevor du weiterkommst.
Ein 1.500-Wörter-PRD, das 90 Minuten zum Tippen braucht, dauert gesprochen etwa 25 Minuten. Das Denken ist dasselbe. Das Ergebnis ist dasselbe. Nur das Werkzeug ändert sich.
Warum PRDs perfekt für Stimme gemacht sind
Die meisten Dokumente bestrafen Diktat, weil sie Präzision verlangen: Code, Tabellen, Finanzmodelle. PRDs sind das Gegenteil. Sie sind erzählende Dokumente.
Denk an das letzte PRD, das du geschrieben hast. Der Abschnitt „Problem“ besteht aus zwei Absätzen, die erklären, warum etwas wichtig ist. Die „Lösung“ ist eine Beschreibung, wie die Sache funktioniert. Die „User Stories“ sind Sätze im Format „Als X möchte ich Y, damit Z“. Der Abschnitt „Edge Cases“ ist eine Liste von „Was passiert, wenn …“-Szenarien.
Nichts davon erfordert Tastaturpräzision. All das ist genau das, was du in einem Meeting sagen würdest. Das Format passt schon jetzt dazu, wie ein PM die Arbeit eigentlich kommuniziert.
Der 30-Minuten-PRD-Workflow
So sieht die Struktur aus, die funktioniert: 1. Öffne ein leeres Doc mit den Abschnittsüberschriften schon angelegt: Problem, Lösung, User Stories, Akzeptanzkriterien, Edge Cases, Out of Scope, offene Fragen. 2. Geh Abschnitt für Abschnitt vor. Diktiere jeden so, als würdest du ihn einem neuen Engineer erklären, der gerade ins Team gekommen ist. 3. Bearbeite nichts, während du sprichst. Der mentale Wechsel zwischen „Sprecher“ und „Editor“ bremst dich am meisten aus. 4. Wenn alle Abschnitte diktiert sind, lies den kompletten Entwurf einmal von oben nach unten. Zieh die Sprache zusammen. Korrigiere nur, was wirklich falsch ist. 5. Schick es zum Review.
Die Disziplin liegt in Schritt drei. Wenn du ständig anhältst, um Sätze zu korrigieren, bekommst du den Speed-Vorteil nicht. Dann tippst du im Grunde wieder — nur mit anderem Werkzeug.
Abschnitt für Abschnitt: jedes Teil eines PRDs diktieren
Manche Abschnitte lassen sich leichter diktieren als andere. So gehst du an jeden heran.
Problemstellung
Das ist der einfachste Abschnitt zum Diktieren. Reine Erzählung. Du erklärst, was kaputt ist, für wen es kaputt ist und warum es gerade jetzt wichtig ist.
Sprich es so, wie du eine neue Person im Team beim Stand-up briefen würdest. Nenne das Nutzersegment, die Reibung, auf die sie stößt, die Metrik, die betroffen ist. Mach dir keinen Stress um schöne Prosa. Das ist der Job vom Editieren.
Lösungsübersicht
Geh die vorgeschlagene Lösung so durch, als würdest du sie am Whiteboard skizzieren. „Der User klickt hier, sieht das und dann …“. Stimme macht das mühelos, weil es genau so klingt, wie du es ohnehin laut erklären würdest.
User Stories
User Stories klingen mechanisch wegen des „Als X möchte ich Y, damit Z“-Musters, lassen sich aber gut diktieren, wenn du dich auf das Format einlässt. Sag jede Story als einen Satz und geh dann zur nächsten.
Wenn du zehn Stories hast, diktiere alle zehn in einem Rutsch. Nummeriere sie nicht beim Sprechen. Überlass die Formatierung dem Doc-Editor oder einem nachgelagerten KI-Cleanup.
Akzeptanzkriterien
Listen sind der kniffligste Teil beim Diktieren, aber machbar. Es gibt zwei Wege:
Der erste: Diktiere die Kriterien als ganze Sätze und lass die KI sie zu einer Liste polieren. Sag zum Beispiel: „Der User soll Ergebnisse nach Datum, nach Nutzer und nach Status filtern können. Der Filterzustand soll über Sessions hinweg erhalten bleiben. Der Empty State soll einen Tipp anzeigen.“
Der zweite: Sprich die Bullet-Struktur explizit aus: „Bullet eins, nach Datum filtern. Bullet zwei, nach Nutzer filtern. Bullet drei, über Sessions hinweg erhalten.“ Nimm, was sich im Mund weniger sperrig anfühlt.
Edge Cases
Hier glänzt die Stimme wirklich. Edge Cases sind genau die Art von Laut-Denken, die gesprochen sauber rauskommt und getippt holprig wirkt. Fragen wie „Was passiert, wenn der User offline ist?“ oder „Was, wenn die Daten veraltet sind?“ fließen beim Sprechen viel natürlicher als beim Tippen.
Diktiere jeden Edge Case, der dir einfällt, auch die offensichtlichen. Beim Editieren kannst du immer noch ausdünnen.
Out of Scope
Drei Sätze. Vielleicht vier. Per Stimme ist das in unter einer Minute erledigt.
Offene Fragen
Dieser Abschnitt wird unterschätzt. Die meisten PMs lassen ihn weg, weil sie nicht unsicher wirken wollen. Tu das nicht. Im Abschnitt „Offene Fragen“ fangen Engineering, Design und dein Skip-Level die Dinge auf, die du noch nicht zu Ende gedacht hast.
Stimme ist genau das richtige Werkzeug dafür. Offene Fragen sind exakt die halbfertigen Gedanken, die gesprochen okay rauskommen und sich beim Tippen seltsam schwer anfühlen. Diktiere jede Unsicherheit, auch die, bei der du vermutest, dass es eine offensichtliche Antwort gibt. Die Hälfte löst sich beim nächsten Stand-up. Die andere Hälfte rettet dir den Launch.
Tonalität pro Abschnitt anpassen
Ein PRD ist nicht in einer Stimme geschrieben. Die Executive Summary oben sollte knapp und strategisch sein. Die technischen Specs sollten präzise sein. Der Abschnitt „Offene Fragen“ darf lockerer klingen.
Wenn du diktierst, wechselst du natürlich das Register. Deine Stimme wird formaler, wenn du über Strategie sprichst, und lockerer, wenn du Edge Cases durchgehst. Das Problem: Die meisten Diktiertools liefern dieselbe flache Transkription, egal in welchem Kontext.
Genau hier kommen Voicrs Smart Rules ins Spiel. Du kannst einen „Clean Professional Spec“-Stil für deinen Docs-Editor festlegen, einen „Casual Brainstorming“-Stil für deine Slack-Threads und einen „Technical Clarity“-Stil für dein Engineering-Wiki. Voicr erkennt die aktive App und wendet automatisch den passenden Stil an, sodass derselbe gesprochene Gedanke je nach Ziel anders landet.
Speziell für PRDs: Richte eine Rule ein, die saubere, professionelle Prosa erzeugt, Füllwörter entfernt und Bullet-Listen strukturiert, wenn du sie ansagst. Du sprichst einmal. Das Doc liest sich, als hättest du es sorgfältig geschrieben.
Wo Stimme nicht hilft
Ehrlich gesagt: Nicht jeder Teil eines PRDs profitiert von Stimme.
Tabellen und Matrizen tippst du nach wie vor schneller. Wenn dein PRD eine Feature-Vergleichstabelle, eine Berechtigungsmatrix oder eine Aufwandsschätzung enthält, tipp das.
Exakte technische Strings sind ebenfalls schneller getippt. API-Endpunkt-Namen, Spaltennamen in Datenbanken, Versionsnummern — du kannst zwar drumherum diktieren („der Endpunkt ist Slash users Slash ID“), aber das ist sperrig. Tipp die.
Diagramme lassen sich offensichtlich nicht diktieren. Skizzier sie im Tool deiner Wahl und bind sie ein.
Für alles andere — Narrativ, User Stories, Edge Cases, Entscheidungen, Begründungen — gewinnt Stimme bei der Geschwindigkeit. Und du bleibst nicht mitten im Satz hängen, weil du etwas perfekt formulieren willst.
Mindset-Wechsel: laut denken, später editieren
Der größte Gewinn beim Diktieren von PRDs ist nicht die WPM-Mathematik. Es ist, dass du aufhörst, während des Schreibens zu polieren.
Wenn du tippst, drückst du Backspace. Du schreibst einen Satz zweimal um. Du starrst zehn Minuten lang auf einen Absatz, der „fast richtig“ ist. Genau da sterben PRDs: in der Lücke zwischen Entwurf und Editieren, in der keins von beidem wirklich passiert.
Wenn du diktierst, bindest du dich. Du sagst einen Satz, er landet auf der Seite, du gehst weiter. Der erste Durchgang ist unsauberer als das, was du tippen würdest. Aber du beendest den Entwurf. Und ein unsauberer fertiger Entwurf ist dramatisch nützlicher als ein polierter unfertiger.
Sobald der Entwurf existiert, ist Editieren eine andere, viel schnellere Tätigkeit. Oft verbringst du mehr Zeit mit dem Feinschliff als mit dem Diktieren, und das ist okay. Ein vollständiges Doc zu verfeinern, ist ein klarer Job. Auf ein leeres zu starren, nicht.
Probier es bei deinem nächsten PRD aus
Such dir ein PRD aus, das du vor dir herschiebst. Öffne das Doc, setz die Abschnittsüberschriften, und diktiere von oben nach unten, ohne zu editieren. Stell einen 25-Minuten-Timer. Schau, was rauskommt.
Beim ersten Mal fühlt sich das komisch an. Du wirst dir Sorgen machen, dass das Ergebnis nicht gut genug ist. Widersteh dem Drang, mitten im Flow zu reparieren. Mach einfach fertig.
Wenn du willst, dass das Diktat so sauber rauskommt, dass du kaum noch editieren musst, übernimmt Voicr das Polieren automatisch. Halte FN von überall auf deinem Mac gedrückt, sprich einen Abschnitt durch, lass los, und füg den aufgeräumten Text in dein Doc ein. Voicr entfernt Füllwörter, korrigiert Grammatik und strukturiert deine Gedanken, bevor sie in der Zwischenablage landen. Der PRD-Entwurf, der früher einen Nachmittag gebraucht hat, ist in einer Sitzung fertig.
Deine PRDs schreiben sich nicht von selbst. Aber sie müssen auch nicht getippt werden.