Hauptgedanke

Eine Ordnungsebene rechtfertigt sich durch die Entscheidung, die sie speist, nicht durch die Feinheit, die sie hinzufügt. In einer Feedback-Datenbank speist das Geschäftsziel die Abwägungen zu Strategie und Segment; die angestrebte Arbeitshandlung speist die Discovery; die erwartete Fähigkeit speist Roadmap und Konzeption; das verortete Ärgernis speist Design und Backlog. Jede Ebene hat einen Adressaten und einen Zeitpunkt.

Der Test lässt sich umgekehrt lesen, und er ist streng: Eine Ebene, bei der man nicht sagen kann, wer sie liest und wofür, ist Dekoration. Sie wird befüllt, solange jemand auf die Erfassung achtet, und dann aufgegeben — nicht weil sie falsch wäre, sondern weil nichts von ihr abhängt.

Umgekehrt entfernt, wer eine Ebene streicht, nicht nur ein Etikett: Er entzieht einer Entscheidung ihr Material. Ordnet man alle Rückmeldungen auf der Ebene der Features ein, fehlen der strategischen Diskussion ihre Signale, und die Entscheidung fällt trotzdem — ohne sie.

Dieselbe Regel gilt für die Arten einer an einem Produkt festgestellten Abweichung, und deshalb unterscheidet man fünf statt einer: Ein Fehler wird zu einem Bug, der zu prüfen ist, eine Lücke zu einem Eintrag im Backlog, ein Widerspruch zu einer Schuld, die abzuwägen ist, ein Ärgernis zu einer Entwurfsschuld, ein Wunsch zu einer Gelegenheit. Fünf Ziele, fünf Instanzen. Eine Typologie ohne diese Eigenschaft — „schwer“, „leicht“ — würde einordnen, ohne irgendetwas auszulösen.

Ergänzt durch „Ich habe die Ontologie eines Produkts geschrieben. Dreimal dachte ich, ich wäre fertig.“ (2026-08-11).

Warum das wichtig ist

Das liefert ein Kriterium, um eine Ebene einzuführen oder zu streichen, wo sich die Diskussion sonst um die Richtigkeit der Einteilung dreht. Die Frage lautet nicht mehr „Gibt es diese Ebene wirklich?“, sondern „Welche Entscheidung würde besser getroffen, wenn es sie gäbe?“.

Es erklärt auch, warum Zentralisieren nicht genügt. Eine gut befüllte Datenbank, deren Ebenen an keinen Moment der Abwägung angeschlossen sind, liefert sauber eingeordnete Verbatims und Entscheidungen, die weiterhin anderswo fallen.

Nuancen und Grenzen

Die Verbindung zwischen einer Ebene und ihrer Entscheidung ist nicht festgeschrieben: Eine Ebene, die in einem Team von zehn Personen überflüssig ist, wird entscheidend, wenn sich mehrere Teams die Roadmap aufteilen. Das Kriterium muss neu geprüft werden, wenn sich die Organisation ändert; es wird nicht ein für alle Mal gesetzt.

Und eine Ebene kann mehreren Entscheidungen zugleich dienen — die erwartete Fähigkeit speist die Konzeption ebenso wie die Antwort auf eine Ausschreibung. Der Test verlangt mindestens eine erkennbare Entscheidung, keine ausschließliche Zuordnung.

Offene Fragen

• Sollte eine Ebene, über deren Entscheidung jemand außerhalb des Produktteams befindet, in derselben Datenbank bleiben?