Fünf Seiten Release Notes, sauber formatiert, mit Screenshots zu jedem Schritt – und in der Retro fragt trotzdem noch jemand, ob der neue Rate-Limiter jetzt live ist. Im Product-Management-Alltag bauen wir bei uns im SaaS-Team Features, dokumentieren sie bis ins letzte Detail – und am Ende bleibt eine Frage offen, die im Dokument längst beantwortet war. Ich habe den Text geschrieben, ich kenne jede Zeile, trotzdem kommt die Information nicht an.
Kurzer Hinweis vorab: Ich verlinke hier den Sketchnotes Kurs, den ich seit ein paar Monaten selbst durcharbeite – inklusive Affiliate-Link. Bucht jemand darüber, bekomme ich eine kleine Provision, am Preis ändert sich für euch nichts. Nur damit das klar ist, bevor es weitergeht.
Vor der Umstellung auf Sketchnotes habe ich Standups einfach aufgezeichnet – Audio, direkt im Call mitgeschnitten, Datei danach im Team-Space abgelegt. Kein Mensch hat sich die Aufnahmen später noch angehört. Ich auch nicht. Die Dateien lagen einfach da, ungehört, wie eine Art digitales schlechtes Gewissen.
Warum Textwüsten in SaaS-Teams niemand rettet
Das Problem ist nicht neu. Wir schreiben Release Notes bis ins letzte Detail, und trotzdem bleibt die eigentliche Botschaft irgendwo zwischen Absatz drei und Tabelle sieben hängen. Visuelle Kommunikation klingt im ersten Moment nach einem netten Extra für Kreative, nicht nach einem Produktivitäts-Hebel für ein ganzes SaaS-Team. In der Praxis ist sie für mich zum einzigen Weg geworden, wie Engineering, Sales und Customer Success überhaupt noch dieselbe Version der Wahrheit im Kopf haben.
In der Mittagspause laufe ich manchmal die Runde Richtung Speicherstadt, nur um den Kopf freizubekommen, bevor der nächste Call anfängt. Hilft selten gegen den Satz, der partout nicht kürzer werden will. Was hilft: den Satz nicht kürzer schreiben, sondern ihn zeichnen.
Was ändert sich, wenn ich Release Notes zeichne statt tippe?
Der Wechsel läuft über ein simples Prinzip: Kästen für Features, Pfeile für Abhängigkeiten, ein Icon statt eines Absatzes. Übernommen habe ich die Grundtechnik aus dem Sketchnotes Kurs, den ich seit ein paar Monaten durcharbeite – welches Symbol für welches Konzept steht, ist dabei fast ein eigenes kleines Vokabular für sich. Auf dem Whiteboard im Besprechungsraum quietscht der Marker trocken über die glatte Fläche, die Luft steht nach dem langen Meeting fast still – aber genau dieser enge Rahmen zwingt dazu, das Unwichtige zuerst zu streichen. Wie man eine Seite überhaupt so aufteilt, dass Prioritäten sofort sichtbar sind, ist nochmal eine andere Übung.
Mein erster Versuch ging schief. Ich wollte unsere Cloud-Infrastruktur als sauberes Server-Cluster-Symbol zeichnen, und am Ende sah es aus wie ein Knäuel Wäsche nach dem Trocknerprogramm. Wegwischen, neu ansetzen, kleiner denken. Ein Freund von mir braut seit Monaten IPA im Keller, Schritt für Schritt, ohne eine Phase zu überspringen – so ungefähr fühlt sich das Einüben eines neuen Symbols auch an: langsam, ein bisschen stur, bis es sitzt.
Die gezielte Frage statt fünf Seiten Overhead
Ein Kollege bleibt vor der Skizze stehen, zeigt auf das Icon für die Datenbank-Migration und stellt eine Frage, die exakt die Abhängigkeit trifft, die in der Doku auf Seite vier vergraben war. Danach gibt er zu, dass er Confluence-Seiten seit Wochen nur noch überfliegt.
Das deckt sich mit der Dual-Coding-Idee: Informationen bleiben besser hängen, wenn Sprache und Bild gleichzeitig ankommen. Zwischen Engineering, Sales und Customer Success ist das keine akademische Fußnote, sondern die Brücke, über die jede wichtige Information laufen muss.
Wissenstransfer zwischen Teams ist eigentlich ein eigenes Handwerk, aber schon dieses eine Icon hat mehr erklärt als der komplette Absatz zur Migration. Für die reine Priorisierung von Features nebeneinander gilt ohnehin wieder eine andere Logik als für eine Ablaufskizze, dazu ein andermal mehr.
Skizzen ohne Kontext: die Grenze für verteilte Teams
Ein Teil vom Team sitzt in Hamburg, ein Teil in den USA, und eine statische Zeichnung ohne Erklärung ist für alle, die nicht im Raum standen, oft nur ein Haufen Linien. Also nehme ich inzwischen kurze Loom-Videos auf, in denen ich mit der Maus über die digitale Sketchnote fahre – ob Papier oder iPad die bessere Wahl ist, hängt stark davon ab, wie async das Team überhaupt arbeitet. Wenn ich User Research Ergebnisse visuell aufbereite, verlinke ich direkt aus der Zeichnung auf die Rohdaten, sonst verliert die halbe Truppe im Homeoffice den roten Faden.
Besonders im Sprint Planning merke ich den Unterschied. Wir streiten nicht mehr über die Interpretation eines Satzes, sondern über die Logik eines Pfeils, und das moderiert sich über mehrere Zeitzonen hinweg überraschend ruhig – reine Live-Moderation am Whiteboard ist nochmal eine andere Baustelle. Wie lange die Konzentration in so einem Online-Meeting überhaupt trägt, hängt übrigens stark davon ab, ob man mitzeichnet oder nur zuhört.
Kein Kunstprojekt, sondern ein PM-Werkzeug
Gesichter zeichne ich immer noch wie Kartoffeln mit Augen, und das ist auch gut so – in einem SaaS-Unternehmen zählt Tempo, nicht Ausstellungsqualität. Seit einiger Zeit tracke ich sogar technische Schulden visuell, und sobald man Technical Debt visualisieren kann statt nur darüber zu jammern, hören Stakeholder anders zu. Ein Berg aus roten Kästen, der die Roadmap zu erdrücken droht, braucht keine weitere Erklärung.
In Woche acht hatte sich genug Material angesammelt, um es zu prüfen: den Stapel Retro-Sketchnotes aufgeschlagen, und jede Woche lag komplett auf einer Fläche da – kein Scrollen, kein Tab-Wechsel, nur Kästen und Pfeile, die sofort zeigten, worüber wir eigentlich gestritten hatten. Farbcodierung für Priorität oder Status ist nochmal ein eigenes System, das ich mir erst später sauber zurechtgelegt habe, und der Unterschied zwischen Handlettering und echtem Sketchnoting wird an so einer Seite auch ziemlich deutlich – hier zählt Lesbarkeit, keine schöne Schrift.
Wer selbst anfangen will, muss nicht gut zeichnen können. Ein Kasten, ein Pfeil, ein einziges Icon reichen als Einstieg – genau das habe ich aus dem Sketchnotes Kurs mitgenommen, mehr Gerüst als Kunstunterricht. Die eigentliche Lektion aus acht Wochen Release-Notes-Zeichnen ist simpel: Ein Dokument ist nicht dann gut, wenn es vollständig ist, sondern wenn jemand am anderen Ende der Zeitzone es versteht, ohne mich anzurufen. Morgen steht das nächste Stakeholder-Review an, und ich nehme nur das iPad und einen dicken Marker mit – die Folien bleiben diesmal aus.