Das Backlog ist kein Mülleimer: Es ist ein Werkzeug zum Handeln

In vielen Produktorganisationen ist das Backlog zu einem sauberen Mülleimer geworden.

Eine Idee kommt auf? Backlog.

Eine Kundenanfrage? Backlog.

Ein nicht dringender Bug? Backlog.

Ein Discovery-Hinweis? Backlog.

Eine Intuition des Product Managers? Backlog.

Ein Satz, der in einem Vertriebsgespräch gefallen ist? Backlog.

Man wirft alles rein „um nichts zu vergessen". Und ein paar Monate später hat man 300, 500, manchmal 1.000 Zeilen, die niemand mehr wirklich versteht.

Das ist keine Transparenz.

Das ist Lärm.

Ein Backlog, das alles enthält, klärt nichts. Es gibt nur die Illusion, dass die Information irgendwo existiert — dabei ist sie längst unbrauchbar geworden.

Das Backlog sollte kein Ideenspeicher sein. Es sollte keine Kundenwunsch-Datenbank sein. Es sollte kein Discovery-Werkzeug sein. Es sollte kein Archiv sein. Es sollte nicht der Friedhof der Bugs sein, die man nicht beheben wollte.

Ein Backlog ist ein Werkzeug zum Handeln.

Es dient dazu, bereits reife Informationen zu organisieren, damit mehrere Personen zusammenarbeiten können.

Transparenz bedeutet nicht, alles zu zeigen

Das klassische Argument, alles ins Backlog zu stecken, ist das der Transparenz.

„Wenigstens ist alles sichtbar."

In der Theorie klingt das verlockend. In der Praxis ist es oft falsch.

Ein Backlog mit 500 Zeilen ist nicht transparent. Es ist undurchsichtig. Niemand weiß wirklich, was zählt. Niemand weiß, was noch gültig ist. Niemand weiß, was strategisch ist, was veraltet ist, was abgelehnt wurde, was nur eine Idee ist, was von einem wichtigen Kunden kommt, was bereits dreimal neu diskutiert wurde.

Alles ist sichtbar, also ist nichts mehr lesbar.

Nützliche Transparenz bedeutet nicht, alles offenzulegen. Sie bedeutet, Entscheidungen nachvollziehbar zu machen.

Warum ist dieses Thema in der Roadmap?

Warum ist jenes nicht drin?

Warum wird dieser Bug jetzt behoben?

Warum bleibt diese Kundenanfrage ein Signal und wird nicht zu Arbeit?

Warum wurde dieses Thema abgelehnt?

Eine unreife Idee kann außerhalb des Backlogs bleiben, ohne versteckt zu sein. Sie ist schlicht noch nicht bereit, ein kollektives Objekt zu werden.

Man muss die Räume unterscheiden:

• ein Produktgedächtnis;
• eine Signal-Datenbank;
• persönliche Reflexionsnotizen;
• Entscheidungen;
• Ablehnungen;
• ein Backlog.

Nicht alles muss zum Backlog werden.

Vor dem Backlog: der persönliche Raum des Product Managers

Bevor ein Thema ins Backlog kommt, kann es woanders existieren.

Und dieser andere Ort muss nicht standardisiert sein.

Ein Product Manager kann in Obsidian arbeiten. Ein anderer in Apple Notes. Ein anderer in Trello. Ein anderer in einem Notizbuch. Ein anderer in einer strukturierteren Datenbank. Der Name spielt kaum eine Rolle: Garten des PM, Schleuse, Parkplatz, persönliche Notizen — egal.

Solange die Arbeit individuell ist, kann jeder das Werkzeug nutzen, das ihm am besten hilft.

Das ist sogar vorzuziehen.

Der persönliche Raum des PM dient dazu, den Ideensturm aufzufangen. Man sammelt, verknüpft, vertieft, lässt reifen, streicht wieder. Manche Ideen werden reifen. Andere werden verschwinden. Viele verdienen es nie, von jemandem anderen gesehen zu werden.

Das ist normal.

Eine Idee mit drei Zeilen, abgelegt „um sie nicht zu vergessen", hat in einem kollektiven Werkzeug nichts zu suchen. Sie ist noch nicht bereit, die Aufmerksamkeit eines Entwicklers, eines Designers, eines Data Analysts, eines Sales oder einer Führungskraft zu beanspruchen.

Solange eine Idee ein individueller Gedanke bleibt, braucht sie kein kollektives Werkzeug.

Das Backlog beginnt, wenn das Thema kollaborativ wird

Die eigentliche Eintrittsregel ist einfach:

Das Backlog beginnt, wenn ein Thema aufhört, ein individueller Gedanke zu sein, und kollektive Arbeit wird.

Wenn der Product Manager weiter allein arbeitet, ist es noch kein Backlog.

Wenn das Thema eine Machbarkeitsstudie erfordert, muss man mit Entwicklern sprechen. Dann kann das Backlog nützlich werden.

Wenn das Thema auf einer Nutzungs- oder Wertvermutung beruht, muss man vielleicht die Produktdaten mit einem Data Analyst erkunden. Dann kann das Backlog nützlich werden.

Wenn das Thema einen Interface-Entwurf erfordert, muss man mit dem Design zusammenarbeiten. Dann kann das Backlog nützlich werden.

Wenn das Thema aus dem Support kommt, muss man vielleicht Support, Produkt, Data und Entwicklung zusammenbringen. Dann kann das Backlog nützlich werden.

Aber ins Backlog einzutreten bedeutet nicht, drei Zeilen abzulegen und die anderen damit allein zu lassen.

Der Product Manager muss ein Minimum aus dem herausholen, was er im Kopf hat:

• warum man dieses Thema betrachtet;
• welche Zielgruppe betroffen ist;
• welcher Schmerz oder welche Chance angestrebt wird;
• welcher Wert erwartet wird;
• welche Frage entschieden werden muss;
• welche Signale bereits vorhanden sind;
• welche Zusammenarbeit notwendig ist.

Das ist keine bürokratische Checkliste. Es ist das Minimum, damit andere Personen mit dir arbeiten können.

Eine Anfrage wie „mach mir eine Datenanalyse zu diesem Thema" reicht nicht aus. Eine Anfrage wie „schau mal, ob es sich lohnt" auch nicht.

Das Backlog muss strukturierte Zusammenarbeit ermöglichen. Es darf keinen noch verschwommenen Gedanken delegieren.

Das Backlog ersetzt nicht das Gespräch

Es gibt die umgekehrte Falle: alles formalisieren zu wollen.

Überall Templates erstellen. Felder hinzufügen. Checklisten aufzwingen. Jeden Ticket in ein Mini-Dossier verwandeln. Schreiben, um sich abzusichern, statt zu arbeiten.

Das ist nicht besser.

Der notwendige Detaillierungsgrad hängt vom Team, vom Thema und vom gemeinsamen Kontext ab.

Wenn ein Product Manager seit drei Jahren mit demselben Entwickler arbeitet, muss er nicht immer so viel schreiben wie wenn ein Entwickler seit drei Monaten neu im Team ist.

Wenn das Team sich täglich spricht, können manche Dinge mündlich bleiben.

Wenn das Team neu, verteilt oder mit einem riskanten Thema befasst ist, muss mehr expliziert werden.

Die Konzepte Definition of Ready und Definition of Done können helfen. Sie geben Orientierung. Aber sie müssen lebendig bleiben. Sie dürfen nicht zu einer Bürokratie werden, die das Urteilsvermögen ersetzt.

Ein Entwickler sollte kein Ticket akzeptieren, das er nicht versteht.

Fehlen Elemente zur Beurteilung der Machbarkeit, muss er sie einfordern.

Fehlt der fachliche Kontext, muss er ihn einfordern.

Versteht er den Wert nicht, muss er das sagen.

Eine User Story war nie dafür gemacht, das Gespräch zu ersetzen. Sie dient dazu, es auszulösen.

Das Backlog sollte genauso gedacht werden.

Es strukturiert das Gespräch. Es ersetzt es nicht.

Ein Backlog muss begrenzt sein

Ein unbegrenztes Backlog widerspricht einer begrenzten Roadmap.

Wenn die NNL-Roadmap das Unternehmen vor Verzettelung schützen soll, kann das Backlog nicht alles aufnehmen, was die Roadmap ablehnt.

In einer Now / Next / Later Roadmap hängt das Now von der tatsächlichen Kapazität des Teams ab. Das Next muss begrenzt bleiben. Selbst das Later, das angeblich das Feld der Möglichkeiten darstellt, kann nicht fünfzig verschiedene Richtungen enthalten. Sonst wird es wieder zu einem Inventar.

Das Backlog muss diese Einschränkung verlängern.

Es bringt nichts, eine klare Roadmap zu haben und ein Backlog, das den ganzen Rest enthält.

Dieselbe Logik gilt für Bugs.

Wenn man eine Zero-Bug-Policy anwendet, muss ein echter Fehler behoben werden. Wenn es kein Fehler ist, kann er umklassifiziert werden. Wenn das Thema nicht der Behebung wert ist, nimmt man das hin und streicht es.

Aber Bugs im Backlog für später zu sammeln bedeutet, den Schmutz unter den Teppich zu kehren.

Man glaubt, eine Information zu bewahren. In Wirklichkeit bewahrt man eine nicht getroffene Entscheidung.

Ein begrenztes Backlog schützt die Kapazität des Teams. Es schützt auch die mentale Energie. Eine endlose Liste erzeugt permanente Spannung: alles, was man nicht getan hat, alles, was man vielleicht tun wird, alles, was man für alle Fälle aufhebt, alles, was ohne klaren Grund wartet.

Das ist nicht neutral.

Ein wachsendes Backlog macht müde.

Wenn ich etwas hinzufüge, was nehme ich heraus?

Die Hygieneregel sollte einfach sein:

Wenn ich das hinzufüge, was nehme ich heraus?

Wählen bedeutet verzichten.

Hinzufügen ohne Entfernen läuft darauf hinaus, die tatsächliche Kapazität des Teams zu leugnen. Es ist so zu tun, als wären Zeit, Produktaufmerksamkeit, Entwickler-Verfügbarkeit, Design-Kapazität, Datenanalyse und Support-Last beliebig erweiterbar.

Das sind sie nicht.

Ein Thema kann das Backlog aus verschiedenen Gründen verlassen:

• die Welt hat sich verändert;
• das Geschäft hat sich verändert;
• die Produktstrategie hat sich verändert;
• das Produktwissen hat Fortschritte gemacht;
• das Thema ist nicht mehr relevant;
• das Thema ist zu schwach;
• das Thema ist außerhalb der Roadmap;
• das Thema ist nie gereift.

Man muss streichen können.

Das Backlog darf alte Ideen nicht vor dem Löschen schützen. Es muss die Fähigkeit des Teams schützen, an den richtigen Themen zu handeln.

Alte Tickets verrotten

Man unterschätzt die Alterung von Tickets.

Eine Idee, die heute erstellt und sechs Monate später wieder gelesen wird, ist nicht unbedingt eine gute Erinnerung. Sie ist oft überholt.

Das Produkt hat sich verändert. Die Kunden haben sich verändert. Der Markt hat sich verändert. Die Prioritäten haben sich verändert. Das Team hat gelernt. Die Technik hat sich weiterentwickelt. Die KI hat vielleicht möglich gemacht, was es nicht war, oder nutzlos gemacht, was wichtig schien.

Ein altes Ticket aufzugreifen kann schlimmer sein, als von vorne anzufangen.

Die Gefahr kommt auch aus der Verlustaversion. Weil das Ticket existiert, will man es bewahren. Weil jemand etwas geschrieben hat, zögert man, es zu streichen. Weil eine Anfrage erfasst wurde, will man ihr eine Chance geben.

Aber ein Ticket ist kein Vermögenswert, weil es existiert.

Ein altes Ticket ist nicht unbedingt eine Erinnerung. Es ist oft eine schimmlige Hypothese.

Wenn das Thema wieder interessant wird, kann man es sauber wiedereröffnen. Aber man muss es im aktuellen Kontext neu bewerten, nicht mechanisch eine alte Formulierung übernehmen.

Ein einziges Backlog, um Silos aufzubrechen

Ich glaube nicht an Backlogs, die nach Art der Arbeit getrennt sind.

Ein Produkt-Backlog.

Ein technisches Backlog.

Ein Bug-Backlog.

Ein Support-Backlog.

Ein Discovery-Backlog.

In einem einzigen Team bricht diese Fragmentierung die Priorisierung.

Natürlich, wenn mehrere Teams in unterschiedlichen Bereichen arbeiten, können sie mehrere Backlogs oder mehrere Ansichten haben. Aber in einem gegebenen Priorisierungsraum braucht man ein einziges Backlog.

Warum?

Weil man keine Kategorien priorisiert. Man priorisiert Schmerzen, Risiken und Wert.

Ein Thema aus dem Support kann Support, einen Data Analyst und einen Entwickler erfordern.

Ein Produktthema kann Produkt und Design erfordern, ohne großen technischen Einsatz.

Ein Export-Thema erfordert vielleicht kein Design, aber starkes Fachwissen und eine technische Validierung der Datenverarbeitung.

Die richtige Frage ist nicht: „In welches Backlog gehört dieses Thema?"

Die richtige Frage ist: „Welches Problem lösen wir, und welche Personen brauchen wir dafür?"

Auch deshalb ist die Unterscheidung Bug / Feature oft zu arm. Der Kunde spürt einen Schmerz. Er fragt sich nicht, ob er ins Bug-Backlog, ins Produkt-Backlog oder ins technische Backlog gehört.

Die Frage ist: Welcher Schmerz ist im Hinblick auf Strategie, Kunden und tatsächliche Kapazität prioritär?

Eine Kundenanfrage ist kein Backlog-Item

Kundenanfragen zu erfassen ist wichtig.

Aber eine Kundenanfrage ist kein Backlog-Item.

Es ist ein Signal.

Kunden sind oft sehr gut darin, ihre Probleme zu erklären. Sie können einen Schmerz, eine Einschränkung, einen Kontext, eine Frustration, eine fachliche Anforderung beschreiben.

Sie sind viel weniger zuverlässig, wenn es darum geht, die richtige Lösung vorzuschlagen.

Man muss die Anfrage als Lernmaterial nehmen, nicht als Ausführungsanweisung.

Eine Kundenanfrage kann das Backlog speisen. Aber das ist nicht automatisch.

Sie kann in einer Signal-Datenbank bleiben.

Sie kann mit anderen Anfragen verknüpft werden.

Sie kann später wieder auftauchen.

Sie kann nie wieder auftauchen.

Sie kann nicht zur Produktstrategie passen.

Sie kann nicht in die Roadmap passen.

Sie kann einen zu isolierten Fall betreffen.

Sie kann interessant, aber nicht wichtig genug sein.

Das Backlog darf nicht alle Kundenanfragen aufnehmen, nur um sie nicht zu verlieren.

Eine Kundenanfrage ist Lernmaterial, keine Ausführungsanweisung.

Manche Ablehnungen festhalten, ohne ein verstecktes Backlog zu schaffen

Soll man Ablehnungen festhalten?

Manchmal ja.

Aber eine Ablehnung festzuhalten bedeutet nicht, ein Thema als zu erledigen zu behalten.

Manche Ablehnungen verdienen einen Eintrag, weil sie historisches Wissen schaffen. Heute lehnt man aus einem bestimmten Grund ab: Kosten, Strategie, Machbarkeit, fehlende Kompetenz, geringe Nachfrage, schlechtes Timing.

Ein Jahr später kann sich die Entscheidung ändern.

Das Geschäft kann sich weiterentwickelt haben.

Die Produktposition kann sich verändert haben.

Die KI kann machbar gemacht haben, was zu teuer war.

Das Team kann einen Data Analyst eingestellt haben.

Die technische Machbarkeit kann sich weiterentwickelt haben.

In diesen Fällen ist es nützlich zu verstehen, warum das Thema abgelehnt worden war.

Aber nicht alle Ablehnungen verdienen einen Eintrag. Viele schwache Ideen können einfach verschwinden.

Wenn die Ablehnung strukturierend, wiederkehrend oder transversal ist, kann sie sogar zu einem PDR werden. Man dokumentiert dann die Entscheidung, ihren Kontext, ihre Alternativen und die Bedingungen, die sie weiterentwickeln könnten.

Der Eintrag der Ablehnung soll dem Gedächtnis dienen. Er darf kein verstecktes Backlog recreieren.

Im KI-Zeitalter ist das Backlog nicht mehr der Ort, wo man denkt

Der vielleicht wichtigste Punkt heute ist dieser: Das Backlog ist nicht mehr der richtige Ort, um das Produkt zu durchdenken.

Werkzeuge wie Jira, Notion oder ihre Entsprechungen bleiben oft Karten-Werkzeuge. Verbesserte Textverarbeitungen. Räume, in denen man Items, Status, Felder, Kommentare organisiert.

Sie können nützlich sein, um Aktionen zu koordinieren.

Aber sie sind sehr schwach darin, eine Produktreflexion aufzubauen.

KI-Agenten, die in diese Werkzeuge integriert sind, verbessern manchmal einen Text, formulieren ein Ticket um, schlagen eine Zusammenfassung vor. Das ist am Rande nützlich. Aber es ist kein Denksystem.

Der eigentliche Wert liegt vorgelagert.

Ein reiches Produktkontext kann enthalten:

• Quellen;
• transkribierte Interviews;
• atomare Notizen;
• thematische Notizen;
• Glossare;
• Entscheidungen;
• PDR;
• Normen;
• Produktdaten;
• SQL-Abfragen;
• Analysen;
• Kundensignale;
• Verknüpfungen zwischen vorhandenen und fehlenden Features.

Mit KI wird dieser Kontext abfragbar.

Man kann blinde Flecken anfragen.

Optionen vergleichen.

Interviews verknüpfen.

Wiederkehrendes identifizieren.

Eine SQL-Abfrage generieren, um ein Verhalten in den Daten zu überprüfen.

Ein Interview in Themen umwandeln.

Einen Kundenschmerz mit vorhandenen oder fehlenden Features verknüpfen.

Ein Ticket erst am Ende erstellen.

In dieser Logik werden Jira oder Notion zu Ausgabeketten. Man schiebt Information dorthin, wenn sie bereit ist, kollektiv bearbeitet zu werden.

Das Ticket ist nicht mehr der Ort, wo man denkt.

Es ist der Ort, wo man das Ergebnis eines bereits strukturierten Gedankens hineinschiebt.

Das Discovery-Backlog ist ein schlechter Behälter

Das „Discovery-Backlog" wird damit zu einem schlechten Konzept.

Die Discovery verarbeitet reiche Signale. Sie erfordert Vergleichen, Verknüpfen, Analysieren, Kreuzen, Umformulieren, Synthetisieren.

Ein Kundeninterview sollte nicht direkt als Karte enden.

Es kann transkribiert werden. In Themen aufgeteilt. Mit Schmerzen verknüpft. Mit Kundenanforderungen verknüpft. Mit Produktanforderungen verknüpft. Mit vorhandenen Features verknüpft. Mit fehlenden Features verknüpft. Mit anderen Interviews gekreuzt. In Produktdaten überprüft.

Ein Backlog kann das nicht gut leisten.

Eine Kartenliste ist zu arm, um diese Arbeit zu tragen.

Die Discovery braucht ein Gehirn.

Das Backlog ist nur ein Werkzeug zum Handeln.

Manche Discovery-Ergebnisse können natürlich ins Backlog landen. Aber nur, wenn sie reif genug für eine strukturierte Zusammenarbeit sind.

Das Backlog sollte nicht der Ort sein, wo die Discovery gedacht wird.

Das Backlog ist wegwerfbar

Schließlich muss man eine unbequeme Idee akzeptieren: Das Backlog ist wegwerfbar.

Ein Backlog-Item dient bis zur Lieferung.

Danach verliert es einen Großteil seines Werts.

Tickets desynchronisieren sich. Specs desynchronisieren sich. Abwägungen ändern sich während der Umsetzung. Das endgültige Verhalten in der Produktion weicht oft von dem ab, was anfangs geschrieben wurde.

Die einzige dauerhafte Realität ist das, was geliefert wird.

Der Quellcode.

Das Produktverhalten.

Die Dokumentation, die von dieser Realität aus gepflegt wird.

Das bedeutet nicht, dass das Backlog nichts nützt. Es dient der Koordination. Es ermöglicht, dass mehrere Personen zusammenarbeiten. Es hilft, von einer Absicht zu einer Handlung zu gelangen.

Aber man darf es nicht wie ein heiliges Archiv behandeln.

Man muss die minimal notwendige Zeit darin investieren.

Genug, um zusammenzuarbeiten.

Genug, um zu handeln.

Nicht genug, um eine Dokumentation zu produzieren, die verrottet.

Das Backlog ist keine Quelle der Wahrheit. Es ist ein temporäres Koordinationsinstrument.

Fazit

Ein gutes Backlog enthält nicht alles, was das Unternehmen tun könnte.

Es enthält das, woran es bereit ist, gemeinsam zu arbeiten.

Was unreif ist, bleibt außerhalb des Backlogs.

Was ein Signal ist, bleibt ein Signal.

Was abgelehnt wurde, kann manchmal festgehalten werden, aber anderswo.

Was zur Discovery gehört, wird in einem Kontextsystem bearbeitet.

Was ein echter Bug ist, muss behoben, nicht gelagert werden.

Was ins Backlog kommt, muss in Richtung Handlung vorankommen können.

Im KI-Zeitalter wird diese Unterscheidung noch wichtiger. Der Product Manager kann vorgelagert einen viel reicheren Kontext aufbauen: Quellen, Interviews, Notizen, Glossare, Entscheidungen, Analysen, Daten, KI als Sparringspartner.

Das Backlog bleibt nützlich.

Aber es muss an seinem Platz bleiben.

Es ist nicht das Gehirn des Produkts.

Es ist nicht das vollständige Gedächtnis des Unternehmens.

Es ist kein Ideenspeicher.

Es ist ein Werkzeug zum Handeln.

Mehr dazu

Zero Bugs: Hör auf, Defekt-Bestände zu verwalten Roadmap NNL: ausrichten ohne zu verzetteln Warum Organisationen weiche Entscheidungen bevorzugen