Ein Product Owner verbringt seinen Tag nicht mit Priorisieren. Er verbringt ihn damit, Sätze zur Deckung zu bringen: was ein Kunde gestern gesagt hat, was vor drei Wochen zugesagt wurde, was das Team morgen bauen soll. Priorisieren ist der kleine Rest, der übrig bleibt, wenn diese drei zusammenpassen.
Was folgt, ist ein gewöhnlicher Dienstag. Keine Eskalation, kein Liefertermin, niemand krank — genau deshalb taugt er als Beispiel.
08:40
Der Kaffee ist noch heiß. Im Postfach liegt die Mitschrift des gestrigen Kundentermins: achtundzwanzig Zeilen, davon sechs, die etwas verlangen. Der Rest ist Kontext, Höflichkeit und ein Absatz über das Wetter.
Sechs Wünsche also. Die erste Frage lautet nicht „Wie wichtig ist das?“, sondern „Was davon ist überhaupt neu?“. Zwei dieser Sätze hat derselbe Kunde im Frühjahr schon einmal geschickt, nur anders formuliert. Wer das nicht bemerkt, legt sie ein zweites Mal an — und ab dann gibt es zwei Anforderungen für einen Bedarf, mit getrennten Zuständen, getrennten Verknüpfungen und einer Abdeckung, die dieselbe Zusage zweimal bewertet.
Zwei der sechs Zeilen tragen so einen Hinweis: 88 Prozent und 71 Prozent. Die mit 88 ist tatsächlich derselbe Satz vom März, nur höflicher, und wird verworfen — der Wunsch gehört zu der Anforderung, die es schon gibt. Die mit 71 ist etwas anderes: ähnliches Vokabular, anderer Zweck; sie bleibt. Zwei Minuten lesen, einmal entscheiden, statt drei Monate später zu erklären, warum derselbe Bedarf zweimal im Backlog steht und einmal davon schon gebaut ist.
Um 08:55 stehen vier neue Kundenanforderungen im Projekt, alle im Entwurf. Keine davon ist bisher etwas wert; sie sind nur an einem Ort — und das ist mehr, als vier Sätze in einer Mitschrift von sich behaupten können.
Vier Zeilen, mehr ist um 08:55 nicht passiert. Der Unterschied zum Postfach ist trotzdem der ganze: Diese vier Sätze gehören jetzt jemandem, sie haben eine Adresse, und keiner von ihnen kann mehr still verschwinden, weil eine Mail nach unten rutscht.
10:15
Verfeinerung ist der Teil des Tages, den niemand übernehmen kann. Die Liste dort ist kein Rangvorschlag, sondern schlicht alles, was als Kundenanforderung im Entwurf oder in Prüfung steht; die Zahl neben „Verfeinerung“ in der Navigation ist die Länge genau dieser Liste. Produktanforderungen kommen hier nicht vor.
Die dritte der vier Anforderungen lautet: „Die Auswertung soll schneller werden.“ Daneben steht ein Hinweis von Juujuu, erkennbar an einem farbigen Rand links. Die Kategorie ist Qualität; wie dringend der Hinweis ist, sagt allein die Farbe, das Wort dazu steht nirgends. Inhaltlich sagt er, was jeder aufmerksame Leser auch sagen würde: kein Ausgangswert, kein Zielwert, kein Messpunkt.
Also fragt er nach — im Chat neben der Anforderung, der an dieser einen Anforderung hängt und ihren Text kennt. Zwei Rückfragen und ein Anruf später steht da: „Die Monatsauswertung über 12 Monate und 50.000 Belege erscheint in unter 5 Sekunden; heute dauert sie 40.“ Bringt ein Hinweis eine fertige Formulierung mit, genügen ein Häkchen und eine Bestätigung — für Titel und Beschreibung, je Sprache, vier Felder und sonst keines. Alles Übrige tippt ein Mensch, und dort sitzt auch die Verantwortung.
Dann: Bestätigen. Drei gehen durch. Die vierte bleibt stehen, weil die Quelle fehlt — wer das verlangt hat, steht nirgends. Zehn Sekunden Arbeit, ein Name, weiter. In drei Monaten ist das der Unterschied zwischen einer Anforderung und einem Gerücht.
13:00
Nach dem Mittagessen die unbequeme. „Eine versendete Rechnung darf nicht mehr verändert werden.“ Klarer Satz, Quelle und Beschreibung vorhanden; er würde jede Schranke passieren. Trotzdem stimmt etwas nicht. Vor drei Wochen wurde etwas genehmigt, das anders klang: „Der Vertrieb kann eine Rechnung innerhalb von 24 Stunden korrigieren.“ Die Suche findet den Satz — sie vergleicht Zeichenketten und versteht keine Konzepte, „Rechnung“ findet Sätze, in denen „Rechnung“ steht, und heute reicht das. Zwei Minuten später liegen beide nebeneinander und widersprechen sich.
Gewarnt hat niemand. Kein Abgleich läuft im Hintergrund, kein Modell vergleicht Zusagen miteinander, keine Ähnlichkeitsprüfung greift in den Lebenszyklus ein. Widersprüche findet ein Mensch, der beide Sätze gelesen hat — eine Aufgabenteilung, keine Lücke. Ein Werkzeug, das behauptet, Widersprüche zu erkennen, wird nach dem dritten Fehlalarm weggeklickt.
Ein Werkzeug findet den Widerspruch nicht. Es sorgt dafür, dass er nicht vergessen wird.
Er lehnt ab, und Ablehnen verlangt den Grund: „Widerspricht der am 22. Juli genehmigten Korrekturfrist von 24 Stunden. Entscheidung des Kunden nötig.“ Abgelehnt ist dabei kein Endzustand — der einzige Weg heraus führt zurück in den Entwurf, und genau den nimmt der Satz um 16:10, nachdem der Kunde am Telefon 30 Minuten statt 24 Stunden zugesagt hat. Beide Anforderungen werden umgeschrieben. Der Grund von 13:07 bleibt stehen und erklärt in einem halben Jahr, warum dort 30 Minuten steht und nicht null.
Ablehnen ist der unangenehmste Klick des Tages. Jemand hat sich diesen Wunsch überlegt, und die Antwort lautet nein. Der Unterschied zu einem Nein im Flur ist, dass der Grund stehen bleibt — nachlesbar, auch in vier Monaten, auch von jemandem, der heute nicht dabei war.
Generell, unabhängig von diesem Fall: Wo ein Widerspruch ausdrücklich eingetragen ist, hört die Diskussion auf. Solange er steht, wird nicht genehmigt — an beiden Anforderungen, denn eingetragen wird er an beiden Enden. Kein Umgehungsweg, keine Rolle, die darüber hinweggeht. In der Verfeinerung nennt ein Banner den Grund; auf der Anforderungsseite erfährst du ihn, wenn du es versuchst.
15:00
Der Nachmittag gehört dem Plan — nicht der Frage, was wichtig ist, die war heute Morgen dran, sondern der Frage, was in das nächste Release passt. Über die Güte der Antwort entscheidet die Reihenfolge zweier Handgriffe: erst schätzen, dann zuweisen.
Der Grund für diese Reihenfolge steht in genau dieser Spalte. Eine Anforderung ohne Größe zählt null Punkte. Wer erst zuweist und dann liest, sieht ein Release mit 22 von 40 Punkten, hält es für halb leer und lädt noch etwas nach — obwohl sechs der vierzehn Einträge nur deshalb nichts wiegen, weil sie niemand geschätzt hat. Die Zahl lügt nicht, sie schweigt. Schweigende Zahlen richten in einer Planungsrunde mehr Schaden an als falsche.
Was hier nicht passiert, ist genauso aufschlussreich: Es wird nichts über ein Board gezogen und irgendwo fallen gelassen. Es gibt eine Auswahl in einer Liste, eine Aktion darauf und eine Tabelle, die danach eine andere Zahl zeigt. Weniger hübsch, deutlich schwerer misszuverstehen.
Im Bau Der Reiter „Zeitachse“ sagt das selbst. Dort steht heute kein Diagramm, sondern ein Satz darüber, was kommt: die Releases aller Produkte nebeneinander, damit Terminkonflikte sichtbar werden, bevor sie eintreten. Kommt in 2026.09.
17:20
Kurz vor Feierabend eine Nachricht aus dem Vertrieb: „Meyer AG fragt nach dem Export. Morgen zwanzig Minuten?“ Vor einem Jahr wäre das ein Termin am nächsten Vormittag gewesen, mit einer abends von Hand zusammengestellten Statusübersicht. Heute sind es zwei Antworten und kein Termin.
Die erste ist ein Link. Eine Anforderung hat eine Adresse, und auf ihrer Seite steht, was der Vertrieb wissen will: der Zustand, wer sie verlangt hat, welche Produktanforderungen an ihr hängen und — falls sie schon übergeben wurde — der Schlüssel des Jira-Vorgangs, der daraus entstanden ist.
Die zweite Frage kommt erfahrungsgemäß direkt danach: Was haben wir Meyer AG sonst noch zugesagt, das heute durch nichts gedeckt ist? Dafür gibt es den Lückenbericht — auf Projekt und Priorität eingrenzbar, als PDF oder Excel. Er listet die Kundenanforderungen, hinter denen keine einzige bestätigte Verknüpfung steht.
Eine Grenze gehört zur ehrlichen Fassung dazu. Die Karte mit der Abdeckung in Prozent hat keine eigene Adresse: Man erreicht sie durch Scrollen auf der Berichtsseite, nicht über einen Link, und eine Ausgabe hat sie nicht. Verschickt wird deshalb der Bericht, nicht der Bildschirm. Bei den Listen ist es umgekehrt — was du dort filterst und sortierst, steht in der Adresszeile. Eine gefilterte Liste ist ein Link, und wer ihn öffnet, sieht dieselbe Liste, kein Bildschirmfoto, das ab Sekunde eins altert.
Die beste Statusfrage ist die, die sich selbst beantwortet.
17:32, Schluss. Vier neue Anforderungen, eine davon messbar formuliert, eine mit Begründung abgelehnt und zurück im Entwurf, ein Release mit vierzehn geschätzten Anforderungen gefüllt, eine Statusfrage ohne Termin beantwortet. Nichts davon war heroisch — zusammen sind sie der Unterschied zwischen einem Produkt, das man erklären kann, und einem, an das man sich nur erinnert.
Kein Heldentag. Genau das ist der Punkt: ein Dienstag, an dem nichts eskaliert ist, weil die Fragen dort beantwortet wurden, wo sie aufgetaucht sind.
Wie derselbe Dienstag zwei Schreibtische weiter aussieht, wenn die Anforderung tatsächlich trägt, steht in Ein Tag im Entwicklungsteam — vom Ticket am Morgen bis zu der Frage, was die Arbeit am Ende abgedeckt hat. Und wie sich diese fünf Stunden eine Ebene höher lesen — als Portfolio, Termine und Fortschritt —, steht in Der Überblick, den Führung braucht.