Ein fünfzehnseitiges Product Requirements Document gegen eine Serviette mit drei Kästen und zwei Pfeilen — in der letzten Architektur-Review hat nur eines von beiden tatsächlich eine Entscheidung ausgelöst. Im Product Management hält sich hartnäckig die Annahme, ein PRD müsse möglichst vollständig sein, damit nichts falsch verstanden wird. Je mehr Text, desto weniger Interpretationsspielraum, so die Theorie dahinter. Was ich hier beschreibe, ist im Kern Visual Thinking für den Projektalltag, keine Illustrationsübung — und die Theorie stimmt eben nicht.
Niemand im Raum stellt eine Rückfrage, während ich seit zehn Minuten die komplexe Logik auf Seite acht erkläre. Ein Stakeholder starrt aus dem Fenster, der Lead-Entwickler tippt nebenbei in seinem Slack-Channel, der Designer scrollt durch eigene Entwürfe. Still ist nicht dasselbe wie verstanden — und genau an diesem Punkt bricht der Mythos vom lückenlosen Dokument in sich zusammen.
Der Mythos vom vollständigen Product Requirements Document
Die Idee klingt vernünftig: Wer jede Edge-Case-Logik in Bullet-Points ausformuliert, minimiert das Risiko eines Missverständnisses. Nur stimmt das in der Praxis selten. Text ist sequenziell; man muss ihn von vorne bis hinten lesen, um das Gesamtbild zu bekommen, und genau dafür fehlt in der Hektik eines SaaS-Alltags die Zeit. Ein PRD mit fünfzehn Seiten wird nicht gelesen, es wird überflogen: die Einleitung, vielleicht die Überschriften, selten die Details.
Das Gehirn verarbeitet Bilder schneller als Fließtext. Es gibt die Dual-Coding-Theorie, nach der wir uns Informationen besser merken, wenn sie verbal und visuell kodiert sind. In den meisten PRDs, die mir in den letzten Jahren untergekommen sind, fehlt die visuelle Hälfte komplett. Genau diese Lücke macht aus einem sauber geschriebenen Dokument trotzdem ein Missverständnis am Konferenztisch.
Kaum jemand liest ein fünfzehnseitiges PRD zu Ende
Ehrlich — kaum jemand. Keine Rückfrage zur komplexen Logik, keine Reaktion auf die Edge Cases, die ich gerade seit zehn Minuten erkläre. Mehr als eine Bildschirmseite Text pro Thema, und die Aufmerksamkeit kippt halt, egal wie wichtig das Thema eigentlich ist.
Deshalb klappe ich inzwischen öfter den Laptop zu und greife zu einem Blatt DIN A4, weiß, unbeschrieben, bevor ich überhaupt zu Ende erklärt habe. Nicht um die Logik zu verstecken, sondern um sie zu zeigen, statt sie vorzulesen.
Der Marker schlägt die Folie
Das Zittern in der Hand beim ersten Strich am Whiteboard ist unangenehm, aber nicht weiter schlimm, denn als PM will man professionell wirken, nicht wie jemand, der Container und Pfeile malt statt eine hochglanzpolierte Folie zu zeigen. Ich fange trotzdem an: ein grober Kasten für die User-Session, ein Pfeil zur Datenbank, ein Blitz-Symbol für den Fehlerfall — schnell genug hingeworfen, um mit dem Gespräch mitzuhalten, nicht um es aufzuhalten. Krumme Linien, falsche Proportionen. Aber das Quietschen des Markers auf dem Whiteboard löst etwas aus, das die Folie vorher nicht geschafft hat — das Tippen auf den Laptops hört auf, die Köpfe kommen hoch.
Wenig später steht der Lead-Entwickler auf. Er sagt nicht, dass er das Dokument nicht versteht. Er sagt: „Jonas, der Pfeil zwischen API-Gateway und Cache stimmt so nicht, das gibt ein Latenzproblem." Er nimmt mir den Marker aus der Hand, streicht eine Linie durch, zeichnet den Weg neu — korrigiert die Logik direkt in meiner hässlichen Skizze.
Zehn Minuten Whiteboard-Gekritzel klären an diesem Morgen mehr als zwei Stunden Dokumenten-Review vorher, weil ein Pfeil zwischen zwei Kästen (diese Art von Flow-Notation sagt mehr als jede Spalte in einer Tabelle) keine Interpretation zulässt: er ist richtig oder falsch, und Wissen wandert so direkt von Kopf zu Kopf, nicht über Umwege durchs Dokument. Wie viel Detail in so eine Skizze überhaupt gehört, merkt man meistens erst, wenn man eine Ebene zu tief einsteigt und die Runde aussteigt — das richtige Abstraktionsniveau zu treffen ist die eigentliche Kunst dabei, nicht das Zeichnen selbst.
Unfertige Skizzen schaffen echte Abstimmung im Team
Ein High-Fidelity-Mockup aus Figma sieht fertig aus, und genau das ist das Problem. Bei einem polierten Entwurf traut sich niemand, das Grundkonzept infrage zu stellen, dann kommt Feedback nur zur Button-Farbe, nicht zur Logik dahinter. Eine handschriftliche, leicht zittrige Skizze signalisiert etwas anderes: Das hier ist ein Entwurf, widersprich mir ruhig — Fehler sind in diesem Format eingepreist, nicht peinlich.
Diese Mischung aus digitalem Werkzeug und analogem Stift entscheidet in der Praxis oft mehr über die Gesprächsqualität als jedes Feature in Figma selbst: kein Entweder-oder, sondern ein ständiges Abwägen je nach Meeting. Nicht jeder Versuch funktioniert dabei. Eine komplexe Cloud-Infrastruktur als Oktopus darzustellen war ein Fehler: Niemand hat verstanden, wofür die Tentakel stehen sollten, wir haben drei Minuten gelacht, ich habe alles weggewischt und wieder einfache Kästen gemalt.
Genauso bin ich einmal mit einer GTD-App gestartet — Projekte, Kontexte, alles sauber eingerichtet — und drei Wochen später nie wieder geöffnet. Digitale Systeme mit zu vielen Kategorien scheitern bei mir fast immer an der ersten stressigen Woche. Papier und Whiteboard bisher nicht. Genau diese Art von Erfahrung lässt sich auch auf andere Bereiche übertragen, etwa wenn ich neuerdings Bug Reports visuell zu dokumentieren für eine bessere Abstimmung mit Entwicklern versuche — ein Bild zwingt zur Präzision, wo Text erlaubt, vage zu bleiben.
So fängst du mit visuellem PRD-Design an
Kein Design-Studium nötig, kein angeborenes Zeichentalent vorausgesetzt. Mein Repertoire besteht aus fünf Elementen — Container, Pfeile, Strichmännchen, Sprechblasen, ein paar Icons wie Blitz oder Zahnrad — und dieses kleine Vokabular reicht für den Großteil dessen, was ein Team an einem Nachmittag klären muss. Ein Strichmännchen für eine Stakeholder-Rolle sagt oft mehr als ein ganzer Absatz Nutzerbeschreibung.
Die Reihenfolge ist entscheidend: erst die DIN A4-Seite, dann der Text. Diese eine Entscheidung — wo auf dem Blatt die wichtigste Box landet, was größer gezeichnet wird als der Rest, eine Hierarchie, die sich über Fläche ausdrückt statt über Worte — zwingt mich dazu, vorher zu wissen, was eigentlich wichtig ist. Wenn ich eine Logik nicht zeichnen kann, habe ich sie meistens auch nicht verstanden. Das ist die Regel, nach der ich mittlerweile jedes PRD baue: erst zeigen, dann schreiben, nie umgekehrt. Denselben Trick nutze ich inzwischen auch, wenn ich Change Management Prozesse visuell begleite, weil es die Hemmschwelle senkt, sich an einem unfertigen Prozess zu beteiligen.
Im Meeting selbst ist das kein Live-Mitschreiben wie in einer Retro, wo es nur ums Festhalten geht — ein PRD-Sketch ist von Anfang an Planung, nicht Protokoll. Die Posca-Punkte auf dem Papier schimmern unter dem Neonlicht im Großraumbüro eher stumpf als glänzend, mehr Kreide als Lack. Trotzdem taucht letzte Woche ein Foto meiner Retro-Seite im Team-Channel auf — gepostet von einem Kollegen, der mich vorher nicht gefragt hat, einfach weil er die Seite fotografierbar fand.
Auf dem Rückweg vom Büro, am Eppendorfer Baum, erzählt mir eine Freundin, die einen Podcast über Nachhaltigkeitsthemen produziert, von ihrem eigenen Gäste-Chaos — auch sie landet am Ende bei einer Linie mit Knoten statt bei einer Tabelle. Das PRD-Problem ist offenbar kein PM-spezifisches Problem. Es ist eines von zu viel Text und zu wenig Fläche, ganz gleich, worüber ein Team sich eigentlich abstimmen muss.