Alle Artikel Das Richtige bauen

Funktionen priorisieren, wenn alles dringend erscheint

Vom FabricLoop-Team  ·  Mai 2026  ·  6 Min. Lesen

In den meisten Produktteams ist das Backlog ein Ort, an dem Dringlichkeit stirbt. Alles, was dort landet, war dringend, als es hinzugefügt wurde — eine Kundenbeschwerde, eine Vertriebsanfrage, eine Wettbewerberfunktion, eine interne Idee. Sechs Monate später ist alles noch da, alles fühlt sich noch dringend an, und niemand weiß so recht, was als nächstes zu tun ist.

Das Problem ist kein Mangel an Werkzeugen. Es gibt Dutzende von Priorisierungsframeworks: RICE, MoSCoW, Kano, ICE, gewichtete Bewertung. Das Problem ist, dass die meisten Frameworks eine Art falscher Präzision erfordern — Zahlen für Unbekanntes zuweisen — die sie streng erscheinen lässt, während sie tatsächlich nur ein Bauchgefühl durch eine Tabellenkalkulation wäscht.

Was wirklich funktioniert, ist einfacher: zwei Dimensionen, ehrlich bewertet, und die Disziplin, nach dem Ergebnis zu handeln.

Die einzigen zwei Dimensionen, die zählen

Priorisierung lässt sich auf zwei Fragen reduzieren. Erstens: Wie sehr verbessert das das Ergebnis, das uns wichtig ist? (Wirkung.) Zweitens: Was kostet es uns, es zu liefern? (Aufwand.) Alles andere ist entweder eine Verfeinerung dieser beiden oder eine Ablenkung davon.

Konfidenz wird manchmal als dritte Dimension hinzugefügt — „Wie sicher sind wir uns bei der Wirkung?" — und es ist es wert, sie im Hinterkopf zu behalten. Aber in der Praxis wissen die meisten Teams, wenn sie raten. Die Disziplin besteht darin, die Schätzung ehrlich zu kennzeichnen, nicht sie auf einer 1–5-Skala zu bewerten und zu einer Formel hinzuzufügen.

Wirkung vs. Aufwand — Priorisierungsraster
← Geringe Wirkung · Hohe Wirkung →
Geringer AufwandHoher Aufwand
Hohe Wirkung · Geringer Aufwand
Schnelle Erfolge
Diese zuerst angehen. Sie liefern überproportionalen Wert im Verhältnis zu den Kosten. Nicht zu lange überlegen — einfach umsetzen.
Hohe Wirkung · Hoher Aufwand
Große Wetten
Lohnt sich, aber sorgfältig planen. Wo möglich in kleinere Teile aufteilen. Sicherstellen, dass die Hypothese validiert ist, bevor vollständig investiert wird.
Geringe Wirkung · Geringer Aufwand
Füller
Diese bei freien Kapazitäten angehen. Nicht zulassen, dass sie Schnelle Erfolge verdrängen oder Große Wetten blockieren.
Geringe Wirkung · Hoher Aufwand
Zeitfresser
Nein sagen. Diese vernichten Kapazität ohne proportionalen Gegenwert. Konsequent aus der aktiven Betrachtung entfernen.

Das Schwierige ist nicht, das Raster zu verstehen — es ist, ehrlich beim Ausfüllen zu sein. Jedes Team hat Funktionen, die es bauen möchte und die zu „Zeitfressern" gehören, aber immer wieder als „Große Wetten" eingestuft werden. Das Framework funktioniert nur, wenn das Team ehrlich über die Wirkung sein kann.

Wirkung ohne falsche Präzision bewerten

Wirkung ist die Dimension, die Teams am schwersten zu bewerten finden, weil sie oft erfordert, die Zukunft vorherzusagen. Die Versuchung besteht darin, sie numerisch zu bewerten und sich dabei wissenschaftlich zu fühlen. Ein besserer Ansatz ist qualitativ, aber strukturiert.

Stellen Sie für jede Funktion unter Betrachtung drei Fragen:

„Die Frage ist nie: ‚Ist das eine gute Idee?' Fast alles im Backlog ist eine gute Idee. Die Frage ist: ‚Was kostet es, das jetzt nicht zu tun, im Vergleich zu etwas anderem?'"

Aufwand ohne Unterschätzung bewerten

Teams unterschätzen den Aufwand systematisch. Das ist gut dokumentiert — es hängt mit dem Planungsfehlschluss und dem Optimismusbias zusammen — und ist besonders ausgeprägt bei Funktionen, die mehrere Systeme berühren, teamübergreifende Koordination erfordern oder Fähigkeiten involvieren, die das Team noch nicht aufgebaut hat.

Zwei Praktiken helfen. Erstens: Fragen Sie immer die Technik, bevor Sie den Aufwand bewerten, nicht danach. PMs, die den Aufwand einseitig bewerten, unterschätzen fast immer. Zweitens: Verwenden Sie das Konzept der „unbekannten Unbekannten" als expliziten Aufwandsmultiplikator. Jede Funktion, die einen neuen Codebereich, eine Drittanbieter-API oder einen Nutzerflow berührt, der nicht kürzlich getestet wurde, verdient eine Aufwandsbewertung, die 1,5-mal höher ist als die offensichtliche Arbeit vermuten lässt.

Das Scope-Creep-Signal Wenn eine Funktion dreimal geschätzt wurde und die Schätzung immer weiter steigt, ist das keine schlechte technische Schätzung — es ist ein Zeichen dafür, dass die Funktion nicht gut genug definiert ist, um sie zu bauen. Stoppen und neu definieren, bevor erneut geschätzt wird.

Die Dringlichkeitsillusion

Der Großteil der Dringlichkeit in einem Produkt-Backlog ist keine echte Dringlichkeit — es ist Aktualität. Ein Kunde hat sich letzte Woche beschwert, also fühlt sich seine Anfrage dringend an. Ein Wettbewerber hat letzten Monat etwas auf den Markt gebracht, also fühlt es sich kritisch an, gleichzuziehen. Aber Aktualität ist nicht dasselbe wie Wichtigkeit, und auf Aktualität zu reagieren ist eine der zuverlässigsten Methoden, wirklich wichtige Arbeit schleifen zu lassen.

Ein praktischer Test: Fragen Sie sich, ob Sie das noch als dringend betrachten würden, wenn Sie es vor sechs Monaten statt letzte Woche gehört hätten. Wenn die Antwort nein ist, handelt es sich um Aktualitätsbias und nicht um strategische Priorität. Notieren Sie es, bewerten Sie es ruhig anhand des Rasters und widerstehen Sie dem Drang, es nur deshalb zu beschleunigen, weil es frisch ist.

Das Problem des lautesten Kunden Der Kunde, der die meisten E-Mails zu einer Funktion sendet, ist selten repräsentativ für Ihre Nutzerbasis. Priorisieren Sie basierend auf der Breite und Tiefe des Problems, nicht auf der Beharrlichkeit der Person, die es meldet.

Wenn das Raster ein Unentschieden ergibt

Das Raster liefert nicht immer eine klare Antwort. Zwei Elemente landen im gleichen Quadranten mit ähnlichen Bewertungen, und Sie müssen trotzdem eines wählen. In diesen Fällen sind zwei Tiebreaker nützlich: strategische Ausrichtung (welches bringt Sie näher dahin, wo Sie in 18 Monaten sein wollen?) und Umkehrbarkeit (welches ist schwieriger rückgängig zu machen, wenn es falsch ist?). Bevorzugen Sie das Element, das strategisch besser ausgerichtet und umkehrbarer ist.

Wie FabricLoop bei der Priorisierung hilft Priorisierungsentscheidungen sind nur so gut wie die Belege dahinter. FabricLoop hält Kundenfeedback, Forschungsnotizen und Teamdiskussionen in einem Thread zusammen mit dem Backlog — sodass Sie beim Bewerten der Wirkung aus Belegen arbeiten, nicht aus dem Gedächtnis.

10 Erkenntnisse aus diesem Artikel

  1. Wenn alles dringend erscheint, hat Dringlichkeit ihre Bedeutung verloren. Das Gefühl der Dringlichkeit ist ein schlechtes Priorisierungssignal.
  2. Die meisten Priorisierungsframeworks waschen Bauchgefühl durch Tabellen. Ehrliches qualitatives Urteil schlägt falsche numerische Präzision.
  3. Wirkung und Aufwand sind die zwei Dimensionen, die zählen. Alles andere ist entweder eine Verfeinerung oder eine Ablenkung.
  4. Schnelle Erfolge (hohe Wirkung, geringer Aufwand) sollten fast immer zuerst kommen. Nicht zu lange überlegen.
  5. Zeitfresser (geringe Wirkung, hoher Aufwand) sollten vollständig aus der aktiven Betrachtung entfernt werden, nicht nur aufgeschoben.
  6. Wirkung ist Häufigkeit mal Intensität. Eine leichte Frustration für alle ist etwas anderes als ein schwerwiegender Blocker für wenige.
  7. Teams unterschätzen den Aufwand systematisch. Immer eine technische Schätzung einholen, bevor bewertet wird; Puffer für unbekannte Unbekannte einplanen.
  8. Die meiste Backlog-Dringlichkeit ist Aktualitätsbias. Fragen: Würde sich das noch dringend anfühlen, wenn es vor sechs Monaten gemeldet worden wäre?
  9. Der lauteste Kunde ist selten der repräsentativste. Priorisieren nach Breite und Tiefe des Problems.
  10. Wenn zwei Elemente unentschieden sind, bevorzugen Sie das strategisch besser ausgerichtete und umkehrbarere.