Neunzehn Features stehen auf der Liste. Keines ist markiert, keines gestrichen, keines hat einen Pfeil nach oben oder unten — optisch wiegt jede Zeile exakt gleich viel, egal ob sie einem Kunden das Leben leichter macht oder nur einem einzelnen Stakeholder gut gefällt. Genau da beginnt das Problem bei reiner Feature-Priorisierung als Text. Ich arbeite als Product Manager in einem Hamburger SaaS-Unternehmen und habe irgendwann angefangen, solche Listen mit den Mitteln aus einem Sketchnotes-Kurs neu zu zeichnen — nicht um hübscher zu protokollieren, sondern weil visuelles Denken beim Entscheiden tatsächlich etwas verändert.
Der verbreitete Irrglaube dazu: Wer eine Priorisierung zeichnet, trifft automatisch eine bessere Entscheidung. Stimmt so nicht. Ein Bild kann eine Diskussion genauso gut ersticken wie ein Textprotokoll — nur schneller und mit mehr Zustimmung im Raum. Der Unterschied liegt eigentlich nicht im Stift, sondern darin, ob man bereit ist, das eigene Bild danach wieder kaputt zu machen.
Der Mythos: Wer zeichnet, entscheidet automatisch besser
In Meetings zur Priorisierung reden Leute oft aneinander vorbei, weil jeder ein anderes Bild vom Backlog im Kopf hat. Jira und Excel bilden das nicht ab, solange die Liste linear bleibt — drei Stakeholder tragen ihre Wünsche vor, alle stehen brav untereinander, es sieht geordnet aus, ist es aber nicht. Der Mythos besagt: Sobald man das Ganze als Matrix oder Quadrant zeichnet, löst sich der Konflikt irgendwie von selbst. Genau das tut er nicht.
Was sich wirklich ändert, ist die Sichtbarkeit des Konflikts, nicht sein Verschwinden. Sobald zwei Achsen auf dem Whiteboard stehen, sieht jeder im Raum, wo die eigene Einschätzung von der des Nachbarn abweicht. Das ist unangenehm, und genau deshalb wirkungsvoll. Bequem wird ein Meeting dadurch nicht automatisch, nur ehrlicher, mehr ist halt nicht drin.
Ein Marker schafft mehr Klarheit als eine Tabelle
Vorher hatte ich es anders versucht. Für jede Prioritätsentscheidung legte ich ein eigenes Linear-Ticket an, sauber verlinkt, sauber benannt. Nach ein paar Sprints wusste niemand mehr, welches Ticket wirklich eine getroffene Entscheidung dokumentierte und welches nur eine Idee war, die irgendwer mal hingeworfen hatte. Die Struktur war da. Die Übersicht nicht.
Am Whiteboard verschwindet dieses Problem nicht komplett, aber es wird kleiner. Während die anderen weiter am Laptop tippen, kratzt nur der Fineliner leise über das Papier — genug, damit der Raum kurz aufhorcht. Wenn ich live eine Impact-vs-Effort-Matrix zeichne, zwingt der begrenzte Platz zur Entscheidung: Ein Feature landet oben rechts oder unten links, nicht irgendwo dazwischen in einer vagen Textbeschreibung. Man braucht dafür übrigens keinen ausgefeilten Symbol-Katalog. Ein Kreis für Aufwand, ein Kreuz für Nutzen, fertig. Maximilian, ein Junior PM, den ich über LinkedIn kenne, hat sich über die Jahre einen eigenen Katalog mit über vierzig Symbolen aufgebaut — und sagt trotzdem, dass ihm am Ende meistens drei oder vier reichen, wenn es wirklich um eine Entscheidung geht.
Mein Lead Developer korrigiert inzwischen lieber die Zeichnung als mich direkt. "Da gehört das nicht hin, der Aufwand ist höher", er zeigt auf den Quadranten, nicht auf mich. Wir reden über dasselbe Objekt statt über zwei verschiedene mentale Bilder.
MoSCoW macht Feature-Priorisierung sichtbar statt nur eine lange Liste
Die MoSCoW-Methode kennt jeder im Product Management: Must-have, Should-have, Could-have, Won't-have. In Textform verkümmert das Won't-have meistens zu einem Appendix, den keiner mehr liest. Gezeichnet wird daraus ein physischer Container — bei mir meistens ein Tresor oder eine Mülltonne, je nach Tagesform.
Sobald Features tatsächlich in diesen Tresor wandern, passiert etwas mit dem Raum. Die Diskussion wird kürzer, nicht länger. Kein Vielleicht lässt sich mehr zwischen die Zeilen quetschen, weil auf dem Papier schlicht kein Platz dafür ist. Das ist die eigentliche Stärke der Methode — und gleichzeitig ihre Falle, dazu gleich mehr. Wer selbst Workshops moderieren will, merkt schnell, dass einfache Sketchnotes am Whiteboard die Gruppendynamik spürbar beruhigen.
Das Dreieck der Kompromisse zeichnen
Ein zweites Modell, das bei mir ständig auf dem Papier landet, ist das Product-Management-Dreieck aus Business, Technology und UX. Jedes Feature zerrt an einer der drei Ecken. Kleine Pfeile zeigen, in welche Richtung der Zug am stärksten ist — ein Feature, das technisch brillant ist, aber keinen Business-Value hat, kippt das Dreieck in eine hässliche Schieflage, und das sieht man auf einen Blick, ohne dass jemand einen Absatz dazu schreiben müsste.
Bis heute sieht mein Symbol für technische Schulden eher aus wie ein umgekippter Wäschekorb als wie eine Bedrohung.
Mein Nachbar Matthias, der auch remote arbeitet, fragt mich regelmäßig, ob das mit den Zeichnungen inzwischen funktioniert, meistens beim gemeinsamen Weg zum Co-Working-Space. Die ehrliche Antwort: teilweise. Dass ich heute überhaupt Customer Journeys visuell darstellen kann, hätte ich mir vor der ganzen Sache nicht zugetraut — aber das Dreieck allein löst keinen einzigen Konflikt. Es zeigt nur, wo er sitzt.
Die Konsens-Falle: Wenn ein schönes Bild die Debatte erstickt
Hier liegt der eigentliche Denkfehler, den man in keinem Workshop zur visuellen Priorisierung erwähnt bekommt: Ein Bild wirkt fertig, sobald es einigermaßen sauber aussieht — und genau das bringt Leute dazu, aufzuhören zu widersprechen. Nur weil ein Feature ordentlich in einem Quadranten sitzt, heißt das nicht, dass es dort auch hingehört. Man traut sich seltener, eine Skizze zu zerstören, als ein Word-Dokument zu kritisieren.
Bei einem Sprint-Review wollte eine Designerin einmal die ganze Notizbuchseite abfotografieren, noch bevor die Diskussion überhaupt zu Ende war — das Bild sah einfach zu rund aus, um es infrage zu stellen. Genau in solchen Momenten fange ich an, meine eigene Zeichnung wieder zu zerstören. Ein dickes Fragezeichen über ein Feature, von dem ich weiß, dass es technisch heikel ist. Eine andere Farbe quer über einen Pfeil, der zu selbstsicher wirkt. Das bricht die Harmonie bewusst und zwingt alle zurück in die inhaltliche Arbeit — warum ein Sketchnotes Kurs meine Sicht auf unleserliche Meeting Notizen änderte ist dabei eine andere Geschichte, aber sie hängt mit genau diesem Punkt zusammen.
Die Regel, die ich daraus mitgenommen habe: Eine Sketchnote darf im Meeting nie fertig aussehen, solange die Entscheidung nicht wirklich getroffen ist. Sobald ein Bild zu glatt wirkt, gehört es absichtlich wieder aufgebrochen — sonst verwechselt der Raum eine hübsche Darstellung mit einer echten Einigung.
Das bleibt, wenn der Laptop zugeklappt ist
Protokolle, die niemand liest, schreibe ich kaum noch. Stattdessen wird das Whiteboard fotografiert und rumgeschickt, und Leute erinnern sich tatsächlich an das Bild statt an eine Zeile Text irgendwo in einem Dokument. Das ist der eigentliche Gewinn, nicht die Ästhetik — ich bin kein Designer und werde auch keiner.
Was bleibt, ist eine einfache Faustregel für jedes Priorisierungsmeeting: Zeichnen schafft Sichtbarkeit, keine automatische Einigung. Wer das verwechselt, bekommt hübsche Bilder und trotzdem die falschen Features im nächsten Sprint. Wer es nicht verwechselt, nutzt den Stift als das, was er ist — ein Werkzeug, um Widerspruch sichtbar zu halten, so lange, bis er tatsächlich geklärt ist.