Was bringt mehr Klarheit in ein Stakeholder-Gespräch – ein Protokoll, das drei Tage später rausgeht, oder eine Skizze, die schon während des Satzes auf dem Blatt entsteht? Ich stelle mir diese Frage nicht aus Prinzip, sondern weil ich als Product Manager in einem Hamburger SaaS-Unternehmen mein eigenes Stakeholder-Management seit einem Jahr komplett auf visuelle Kommunikation umgestellt habe – mit Sketchnotes statt Stichpunkten.
Mein Kalender sagt, ich sitze 62 Prozent der Woche in Meetings. Ein großer Teil davon ist reine Erwartungsarbeit – Prioritäten erklären, Abhängigkeiten offenlegen, Missverständnisse einsammeln, bevor sie zu falsch gebauten Tickets werden. Dafür gibt es im Kern zwei Lager. Lager eins dokumentiert das Gespräch hinterher in Text. Lager zwei zeichnet mit, während das Gespräch noch läuft. Ich habe beide Lager monatelang parallel bedient, nicht als Lernkurve nacheinander, sondern in echten Meetings mit echten Konsequenzen.
Der Kurs, mit dem ich vor einem Jahr angefangen habe, war schnell gefunden: der Sketchnotes Kurs von Timothy90. Kein Kunstanspruch, keine kalligrafischen Übungen – nur Container, Pfeile, Symbole. Genau das, was man in einem Meeting braucht, in dem eine Hand den Stift hält und die andere eigentlich zuhören sollte.
Stakeholder-Management zwischen Textprotokoll und Live-Skizze
Zwei Ansätze, ein Ziel: dieselbe Stakeholder-Sitzung so festhalten, dass sie drei Wochen später noch Sinn ergibt. Ansatz A ist der klassische Weg – zuhören, mitschreiben, danach ein Protokoll verschicken. Ansatz B dreht die Reihenfolge um: zeichnen, während der Satz noch im Raum hängt, und erst danach über die Form nachdenken. Beide haben in echten Meetings bei uns im Team funktioniert. Beide sind auch schon ordentlich gescheitert.
Ansatz A: Das Protokoll danach – und die Post-it-Wand, die es retten sollte
Textprotokolle sind linear. Stakeholder-Erwartungen sind es nicht. Sie sind ein Geflecht aus Abhängigkeiten, halbformulierten Sorgen und technischen Einschränkungen, die kaum jemand laut ausspricht. Fasse ich das in Stichpunkten zusammen, geht die Struktur verloren – und drei Tage später hat jeder im Team eine andere Lesart desselben Dokuments im Kopf.
Um das zu reparieren, habe ich eine Zeitlang eine Post-it-Wand neben meinem Schreibtisch aufgebaut – jede offene Stakeholder-Frage ein eigener Zettel, farblich nach Team sortiert. Klang nach einer soliden Idee. Nach dem nächsten Sprint war die Wand leer. Nicht weil alle Fragen geklärt waren, sondern weil Zettel abgefallen sind, Leute sie mitgenommen haben, und niemand – mich eingeschlossen – sie nachgepflegt hat. Eine Wand, die laufend gepflegt werden muss, bleibt in der Praxis nie laufend gepflegt.
Ansatz B: live mitskizzieren, solange der Satz noch im Raum hängt
Am deutlichsten wird der Unterschied in einem konkreten Fall: einer Stakeholder-Review zu Technical Debt, bei der wir erklären mussten, warum ein Marketing-Feature nicht einfach nebenbei mitgeliefert werden kann. Normalerweise ein Garant für schlechte Stimmung im Raum. Diesmal klappe ich das Laptop nicht auf. Ich greife zum Fineliner und zeichne live, während die Diskussion läuft – ein Container für das Backend, ein kleinerer für die neue API, ein Blitz-Symbol dazwischen für den Engpass.
Niemand hat mich dafür belächelt. Im Gegenteil: Die Laptops klappen langsam zu. Ein Stakeholder, der sonst gerne vage bleibt und später unzufrieden ist, unterbricht sich selbst mitten im Satz und zeigt auf einen Pfeil, den ich – aus Unsicherheit über seine letzte Aussage – bewusst in die falsche Richtung gezeichnet hatte. Er sagt, das Marketing-Tool liefere Daten, es empfange sie nicht, und korrigiert die Skizze eigenhändig. Genau dieser kleine Fehler auf dem Blatt hat ein Missverständnis offengelegt, das in einem Textprotokoll erst beim fertigen Prototyp herausgekommen wäre – inklusive der Diskussion, die wir uns dann hätten liefern müssen.
Erzählt habe ich das später Hauke Wendorff, unserem Scrum Master, bei einem Kaffee im Winterhuder Fährhaus an einem Samstag. Hauke ist der Kollege, wegen dem ich überhaupt mit Sketchnotes angefangen habe – und auch diesmal hatte er sein Ladekabel wieder im Konferenzraum liegen lassen, zum gefühlt zehnten Mal. Seine Reaktion auf die Pfeil-Geschichte war trocken: Das sei kein Zeichenfehler, das sei ein Gesprächsprotokoll, das sich selbst korrigiert.
Der Effekt bleibt nicht auf einzelne Meetings beschränkt. Seit ich auch Product Release Notes visuell aufbereite, bekomme ich zu abgeschlossenen Features kaum noch Rückfragen zur Logik – der Zeitstrahl mit Meilenstein-Icons beantwortet die Fragen, bevor sie überhaupt gestellt werden.
Was in beiden Lagern sonst noch funktioniert
Zwischen den beiden Extremen gibt es eine ganze Bandbreite an Varianten, die ich bei anderen PMs und in Sketchnotes-Gruppen beobachtet habe. Manche strukturieren jede Seite über eine klare visuelle Hierarchie, bevor überhaupt der erste Strich fällt. Andere verlassen sich auf ein festes Icon-Vokabular, von dem sie nie abweichen. Es gibt Kollegen, die radikal auf Rapid-Capture setzen – einfach alles mitschreiben, was im Raum passiert – während andere vorher entscheiden, welches Layout zur Art der Besprechung passt. Wieder andere pendeln bewusst zwischen iPad und Papier und nehmen diesen Kompromiss in Kauf, statt sich für eine Seite zu entscheiden. Farbcodierung ist für manche Pflicht, um Prioritäten sofort erkennbar zu machen, für andere reiner Overhead. Den Unterschied zwischen Lettering und echtem Sketchnoting habe ich am Anfang unterschätzt – bis mir klar wurde, wie viel Zeit schöne Buchstaben in einem Meeting kosten, in dem es um Inhalt geht, nicht um Form.
Für Online-Meetings setzen manche auf Techniken zur Aufmerksamkeits-Verankerung, andere trainieren eher selektives Zuhören, wenn fünf Leute gleichzeitig reden wollen. Für Prozessdiagramme greife ich inzwischen auf eine eigene Fluss-Notation zurück, und sobald ich selbst einen Workshop moderiere, zählt vor allem Live-Moderation mit dem Stift in der Hand statt mit der Maus. Bei Priorisierungs-Workshops schlägt ein räumlicher Vergleich fast jede Tabelle. Fehlertoleranz ist sowieso Grundvoraussetzung – sonst traut sich im Meeting niemand, laut mitzuzeichnen. Für neue Teammitglieder funktioniert Wissenstransfer über solche Seiten erstaunlich gut, weil sie eine ganze Diskussion in einem Bild zusammenfassen. Bei Stakeholder-Analysen zeichne ich inzwischen kleine Figuren statt Namenslisten, und sobald es um Softwarearchitektur geht, wähle ich bewusst eine grobe Abstraktionsebene statt jedes einzelne Detail zu zeigen. Es gibt außerdem den Unterschied zwischen Planung vorab und reinem Mitschreiben während des Gesprächs – beides hat seinen Platz, je nachdem, wie gut das Thema vorher schon steht. Welche Stifte dabei zum Einsatz kommen, ist am Ende Nebensache, solange sie zur eigenen Hand passen. Bei sensiblen SaaS-Themen ziehe ich zusätzlich eine klare Vertraulichkeitsgrenze, was auf die Seite darf und was im Raum bleibt. Kundenfeedback lässt sich über Muster-Clustering erstaunlich gut verdichten, bevor es in eine Roadmap einfließt. Ob die eigene Handschrift am Ende noch lesbar ist, entscheidet, ob die Seite nach dem Meeting überhaupt noch jemandem hilft. Manche Teams visualisieren sogar ganze Change-Prozesse über eine durchgehende visuelle Metapher. Und eine bewusst unfertig wirkende Skizze ist in meiner Erfahrung selten Schlamperei – meistens ist sie Strategie.
Wann lohnt sich welcher Ansatz wirklich?
Rainer Habelmann, ein Stammleser aus einer Sketchnotes-Facebook-Gruppe, hat mir dazu neulich wieder die immer gleiche Frage gestellt: wie viele Minuten pro Seite das eigentlich kostet. Die nüchterne Antwort: Ansatz A kostet weniger Zeit während des Meetings und mehr danach. Ansatz B kostet mehr Aufmerksamkeit während des Gesprächs und fast nichts mehr danach.
Für mich persönlich hat sich die Rechnung verschoben, seit ich sonntagabends öfter mein Notizbuch durchblättere und eine ganze Arbeitswoche auf wenigen Doppelseiten wiederfinde – Meetings, Entscheidungen, offene Fäden, alles direkt sichtbar, ohne dass ich erst durch alte Chat-Verläufe suchen muss. Mit reinen Textnotizen hat mir das nie funktioniert.
Wer wie Rainer genau wissen will, wann sich welcher Weg lohnt: Ansatz A reicht, wenn eine Besprechung rein informativ ist und niemand im Raum unterschiedliche Erwartungen hat, die später aufeinanderprallen könnten – dann ist ein kurzes Textprotokoll schneller geschrieben als jede Skizze. Ansatz B lohnt sich, sobald mehrere Stakeholder mit unterschiedlichen, teilweise unausgesprochenen Erwartungen im selben Raum sitzen, bei Scoping-Gesprächen, Priorisierungen oder überall dort, wo spätere Missverständnisse teuer würden.
Für den Papier-Weg gilt bei mir immer noch die gleiche Empfehlung wie am Anfang: der Sketchnotes Kurs, der sich komplett auf Meeting- und Projektnotizen konzentriert statt auf schöne Buchstaben. Wer dagegen ohnehin aufs iPad wechseln will, weil die Notizen direkt ins Wiki sollen, findet im Digital Lettering Kurs die Ebenen- und Export-Logik erklärt, die Papier naturgemäß nicht bietet – für mich war das der Zusatzschritt, um auch bessere Lesbarkeit im Meeting zu garantieren, wenn meine Handschrift mit dem Tempo der Diskussion nicht mehr mithält.