Dienstag, kurz nach der Mittagspause. Der Konferenzraum riecht nach abgestandenem Kaffee und der leichten Panik, die immer dann entsteht, wenn das Backend-Team das Wort Refactoring ausspricht. Ich starre auf ein Jira-Ticket mit mittlerweile 45 Kommentaren. Es geht um die Notwendigkeit, unsere API-Anbindung zu überarbeiten. Der Head of Sales tippt ungeduldig auf seinem Smartphone rum. Er will wissen, wann das neue Dashboard-Feature live geht. Die Entwickler reden über Microservices und Race Conditions. Ich merke, dass wir uns seit zwanzig Minuten im Kreis drehen, weil niemand im Raum das gleiche Bild im Kopf hat.
Laut meinem Kalender verbringe ich 62 Prozent meiner Arbeitswoche in Meetings. Das ist viel Zeit, um Dinge nicht zu verstehen. Ende 2025 habe ich aus purer Verzweiflung angefangen, meine Notizen visuell zu strukturieren. Nicht, weil ich plötzlich künstlerische Ambitionen entwickelt hätte — ich kann eigentlich kaum gerade Linien ziehen — sondern weil ich meine eigenen Protokolle nach drei Tagen nicht mehr entziffern konnte. Heute, an einem dieser typischen grauen Nachmittage im August, versuche ich zum ersten Mal, das abstrakte Monster namens Technical Debt aufs Papier zu bringen.
Das Problem der unsichtbaren Altlasten im SaaS-Alltag
Technische Schulden sind für Stakeholder wie Sauerstoff: Man merkt erst, dass sie fehlen — oder in diesem Fall zu viel sind — wenn man keine Luft mehr bekommt. Als Product Manager stehe ich oft in der Mitte. Auf der einen Seite die Entwickler, die warnen, dass das System instabil wird. Auf der anderen Seite das Management, das nur die Roadmap sieht. Die Schwierigkeit ist, dass technischer Ballast unsichtbar ist. Er steht in keinem Feature-Katalog.
In unserem Standard-Rhythmus von 14 Tagen pro Sprint versuchen wir immer, einen Teil für Wartung zu reservieren. Aber ohne Visualisierung wirkt dieser Teil für Außenstehende oft wie ein schwarzes Loch. Ich erinnere mich an den Spätherbst 2025, als wir ein Release verschieben mussten, weil eine veraltete Library den Geist aufgegeben hat. Damals hatte ich nur Textwüsten in meinen Notizen. Keiner hat verstanden, warum wir plötzlich drei Tage Stillstand hatten. Es fehlte die Brücke zwischen dem Code und dem Business-Value.
Ich habe angefangen, das Qualitätsmodell nach ISO/IEC 25010 nicht mehr als Liste mit 8 Hauptmerkmalen zu betrachten, sondern als etwas, das man zeichnen kann. Besonders die Wartbarkeit ist für uns im SaaS-Bereich kritisch. Wenn ich heute über technische Schulden spreche, versuche ich nicht mehr, die Begriffe der Entwickler zu kopieren. Ich übersetze sie in Bilder, die auch der Head of Sales versteht, ohne sein Handy zu zücken.
Die Stadtplan-Metapher: Architektur als Lebensraum
Im ersten Quartal des neuen Jahres habe ich eine Technik ausprobiert, die ich in meinem Sketchnotes-Tagebuch dokumentiert habe. Statt komplexe UML-Diagramme zu zeichnen, die außer den Architekten niemand versteht, habe ich unsere Systemlandschaft als Stadtplan visualisiert. Die stabilen Core-Services sind die soliden Altbauten im Zentrum. Die neuen, schnellen Features sind die modernen Glasbauten am Rand.
Und die Technical Debt? Die zeichne ich als baufällige Brücken oder Schlaglöcher in den Hauptverkehrsstraßen. Wenn wir ein neues Feature (einen neuen Glasbau) planen, zeigt meine Skizze sofort das Problem: Die Zufahrtsstraße ist eine baufällige Brücke. Wir können den Glasbau hinstellen, aber niemand kommt hin. Das versteht jeder. In der Sprint-Planung vor etwa drei Wochen passierte dann das Unerwartete. Das leise Quietschen des schwarzen Neuland-Markers auf dem Whiteboard, während das gesamte Team plötzlich schweigend auf meine Zeichnung starrt. Ich hatte gerade eine marode Brücke zwischen unserem User-Management und dem Payment-Modul gezeichnet.
In diesem Moment wurde die abstrakte Gefahr greifbar. Der Head of Sales fragte nicht mehr, warum das Dashboard länger dauert. Er fragte, ob wir die Brücke verstärken können, bevor wir den nächsten Turm bauen. Die Erleichterung, als ich merke: Ich muss kein Künstler sein, ein zittrig gezeichnetes Stoppschild versteht jeder im Raum sofort. Es geht nicht um Schönheit, sondern um Klarheit. Manchmal hilft es auch, wenn man weiß, wie man Konflikte in Meetings lösen kann, indem man die unterschiedlichen Standpunkte einfach nebeneinander an das Board pinnt.
Die Falle des visuellen Perfektionismus
Allerdings gibt es eine Gefahr, die ich auf die harte Tour lernen musste. Vor ein paar Monaten habe ich versucht, jede kleinste technische Unsauberkeit in meine Skizzen aufzunehmen. Ich wollte besonders gründlich sein. Das Ergebnis war ein völlig überladenes Bild, das eher wie ein Wimmelbild aus der Hölle aussah als wie eine Entscheidungshilfe. Das Team war paralysiert. Die Entwickler wollten plötzlich alles gleichzeitig refactoren, weil alles auf der Zeichnung so kaputt aussah.
Hier liegt der entscheidende Punkt: Die Visualisierung von Technical Debt in Meetings führt oft zu kontraproduktivem Perfektionismus, statt den Fokus auf die für das Geschäft notwendige pragmatische Fehler-Toleranz zu legen. Wir arbeiten in einem SaaS-Umfeld. Wir werden nie einen perfekten Code-Stand haben. Das Ziel der Sketchnotes darf nicht sein, den perfekten Zustand zu fordern. Das Ziel ist es, die Schmerzpunkte zu finden, die uns wirklich am Vorankommen hindern.
Einmal habe ich versucht, eine Cloud-Infrastruktur darzustellen, aber das Symbol sah am Ende aus wie eine traurige Kartoffel. Mein Kollege aus dem DevOps-Team hat mich den ganzen Nachmittag damit aufgezogen. Aber wissen Sie was? Wir haben trotzdem über die Latenzprobleme dieser Kartoffel gesprochen. Es hat funktioniert. Die visuelle Notiz ist ein Werkzeug zur Deeskalation, kein technisches Dokument. Ich habe neulich mal darüber nachgedacht, wie man Komplexe SaaS Business Modelle visuell erklären kann, und dabei gemerkt, dass die Reduktion auf das Wesentliche die eigentliche Kunst ist.
Pragmatismus am Whiteboard: Weniger ist mehr
Wenn ich heute im Meeting zum Marker greife, achte ich auf drei Dinge. Erstens: Was ist die eine kritische Abhängigkeit, die dieses Feature blockiert? Zweitens: Wie kann ich das Risiko symbolisieren, ohne Panik auszulösen? Ein kleines Warnschild reicht oft aus. Drittens: Ich lasse Platz für Ergänzungen der Entwickler. Oft nehmen sie mir den Stift aus der Hand und zeichnen selbst eine Verbindung ein. Das ist der Moment, in dem die Sketchnote ihre volle Wirkung entfaltet: Sie wird zum gemeinsamen Kommunikationsraum.
Technical Debt zu visualisieren bedeutet nicht, den Untergang des Systems zu prophezeien. Es bedeutet, eine gemeinsame Sprache zu finden. Wenn ich eine baufällige Straße zeichne, diskutiere ich nicht über Code-Zeilen, sondern über Investitionsschutz. Wir entscheiden gemeinsam, welche Schlaglöcher wir ignorieren können und welche uns die Reifen zerfetzen werden. Diese pragmatische Fehler-Toleranz ist das, was uns als Product Team schnell hält. Ohne meine visuellen Krücken wäre ich wahrscheinlich immer noch damit beschäftigt, die 46. Antwort in das Jira-Ticket zu tippen, während der Rest des Teams schon geistig im Feierabend ist.
Es ist jetzt spät am Nachmittag. Die Sonne drückt kurz durch die Hamburger Wolkendecke. Das Meeting ist vorbei. Auf dem Whiteboard klebt ein Foto meiner Skizze, das Ticket ist aktualisiert — diesmal mit einem Bildanhang statt einer Textwüste. Ich merke, dass mein Handgelenk leicht zieht, weil ich den Stift zu fest gehalten habe. Aber das ist okay. Zumindest weiß ich heute Abend, was wir morgen im Standup besprechen werden, ohne meine eigenen Notizen dreimal lesen zu müssen.