Produkt-Roadmap priorisieren: Schweizer Praxis mit klarem OKR-Bezug

Priorisieren Sie Ihre Produkt-Roadmap danach, wie stark eine Initiative Ihre OKR bewegt, und nicht danach, wie laut die Anfrage war. Wählen Sie ein Bewertungsmodell, das zu den Daten passt, die Sie tatsächlich haben, machen Sie daraus ein wiederkehrendes Teamritual mit einer namentlich benannten entscheidungsbefugten Person und überprüfen Sie die Rangfolge jedes Quartal. Wenn diese drei Dinge stimmen, ist der Rest, RICE-Rechnung, Kano-Umfragen, WSJF-Formel, nur noch Umsetzungsdetail.

---

Kurz zusammengefasst:

• Ein einziges Bewertungsmodell, das Quartal für Quartal zu Ihren Daten und Zielen passt, führt zu verlässlicheren Roadmaps und besseren Entscheidungen.

• RICE eignet sich am besten für grosse Backlogs mit vielen kleinen Ideen, sofern Schätzungen vorliegen. Kano zielt über Umfragedaten auf die Begeisterung der Kundschaft.

• MoSCoW hilft beim Zuschnitt eines Releases, sollte aber bei rund 60 % «Must»-Einträgen gedeckelt werden, damit die Priorisierung wirksam bleibt.

• Priorisierung muss sich am Ergebnis orientieren, klare Verantwortlichkeiten haben und in einer strukturierten, zeitlich begrenzten Sitzung mit Input aus allen Bereichen stattfinden.

• Wer die KPI zu den OKR regelmässig prüft und validierte Daten aus Experimenten einfliessen lässt, hält die Priorisierung an den tatsächlichen Ergebnissen ausgerichtet.

---

Welche Modelle eignen sich am besten zur Priorisierung einer Roadmap?

Jedes Modell beantwortet eine andere Frage, und das falsche für Ihre Situation zu wählen, ist der schnellste Weg zu einer Roadmap, der niemand traut. Hier steht, was jedes Modell mechanisch leistet und wann es seinen Platz verdient.

RICE bewertet Einträge nach Reach (wie viele Nutzende oder Kundinnen und Kunden pro Zeitraum), Impact (meist auf einer Skala von 0.25 bis 3), Confidence (ein Prozentwert, wie sicher Sie sich sind), geteilt durch Effort (Personenwochen oder -monate). Die Formel lautet (Reach × Impact × Confidence) ÷ Effort. Das funktioniert gut, wenn Sie ein Backlog mit vielen kleinen bis mittleren Ideen haben und schnell eine Rangfolge brauchen, ohne endlose Diskussionen. Die Übersicht des Pragmatic Institute zu Priorisierungsmethoden behandelt RICE neben Kano, Nutzen gegen Aufwand und gewichteter Bewertung als eines der vier dominierenden Verfahren, zu denen Teams greifen, und jedes hat seinen eigenen Einsatzbereich.

Kano sortiert Funktionen nach der Reaktion der Kundschaft: Basismerkmale (werden erwartet, ihr Fehlen führt zu Unzufriedenheit), Leistungsmerkmale (mehr ist besser, die Zufriedenheit steigt linear) und Begeisterungsmerkmale (unerwartete Funktionen, die überproportionale Zufriedenheit erzeugen). Diese Daten erheben Sie über Kundenbefragungen, in denen Sie fragen, wie sich Nutzende mit und ohne eine Funktion fühlen würden. Kano ist das richtige Werkzeug, wenn Sie sich über das Erlebnis differenzieren wollen und nicht nur Selbstverständlichkeiten ausliefern. Schwach ist es, wenn Sie schnell vorankommen müssen und keine Umfrageinfrastruktur haben.

MoSCoW teilt Arbeit in Must have, Should have, Could have und Won't have für diesen Zyklus ein. Es ist für den Zuschnitt von Releases gedacht, nicht für eine feine Rangfolge, denn es sagt Ihnen nicht, welches «Must» zuerst ausgeliefert wird. Der Haken: MoSCoW bricht in dem Moment zusammen, in dem alles zum «Must» wird. Die Agile Business Group recommends capping Must-have items at roughly 60% of available capacity, und genau das erzwingt echte Abwägungen, statt jedem Lieblingsfeature einen Bestandsschutz in der obersten Kategorie zu geben.

Nutzen gegen Aufwand (eine 2x2-Matrix aus Wirkung und Aufwand) trägt Initiativen auf zwei Achsen ab: geschäftlicher oder kundenseitiger Nutzen auf der einen, Umsetzungskosten auf der anderen. Alles im Quadranten mit hohem Nutzen und geringem Aufwand, oft «Quick Wins» genannt, kommt zuerst. Das ist das schnellste Modell für einen Workshop, weil es weder Formel noch Umfragedaten braucht, nur fundierte Einschätzungen des Teams auf einem Whiteboard oder in einem geteilten Dokument. Es lässt sich allerdings auch am leichtesten manipulieren, wenn jemand den Nutzen stillschweigend aufbläst oder den Aufwand für die eigenen Lieblingsideen kleinrechnet.

WSJF (Weighted Shortest Job First) teilt die Verzögerungskosten durch die Dauer oder den Aufwand einer Aufgabe. Die Verzögerungskosten selbst kombinieren meist Nutzen für Nutzende und Geschäft, zeitliche Dringlichkeit sowie Risikominderung oder das Eröffnen neuer Möglichkeiten. WSJF ist für Umfelder gemacht, in denen die Reihenfolge ebenso wichtig ist wie die Auswahl, etwa Plattformteams mit dutzenden voneinander abhängigen Initiativen, bei denen eine Verzögerung gleich drei weitere Vorhaben blockiert. Es verlangt mehr Eingangsdaten als die vier anderen Methoden und lohnt den Aufwand bei einem kleinen Backlog nicht.

Hier die Kurzübersicht:

• RICE: grosse Backlogs, viele kleine bis mittlere Ideen, braucht Schätzungen zu Reichweite, Wirkung, Zuversicht und Aufwand.

• Kano: Begeisterung der Kundschaft und Differenzierung über das Erlebnis, braucht Umfragedaten.

• MoSCoW: Zuschnitt von Releases und Abstimmung mit Anspruchsgruppen, braucht eine harte Obergrenze für «Must»-Einträge.

• Nutzen gegen Aufwand: schnelle Entscheidungen im Workshop, braucht nur zwei grobe Einschätzungen pro Eintrag.

• WSJF: Reihenfolge bei vielen Abhängigkeiten und Zeitdruck, braucht Schätzungen der Verzögerungskosten.

Atlassian’s prioritization framework guide macht denselben Punkt aus einem anderen Blickwinkel: Wählen Sie Ihr Modell nach Ihren Zielen, nach den Daten, die Sie realistisch erheben können, und danach, wie reif Ihr Team darin ist, Aufwand und Wirkung ehrlich zu schätzen. Ein fünfköpfiges Startup-Team, das ohne Nutzungsdaten «Confidence»-Werte errät, betreibt Theater, nicht RICE. Wenn Sie keine verlässlichen Daten haben, schlägt ein einfacher Durchgang nach Nutzen gegen Aufwand jedes Mal einen scheingenauen RICE-Wert.

Wie wählen und nutzen Sie ein Priorisierungsmodell noch diese Woche?

Sie brauchen keinen sechswöchigen Einführungsplan. Sie brauchen eine Arbeitssitzung und eine wiederholbare Struktur darum herum. Hier die Abfolge.

1. Klären Sie zuerst das Ergebnis. Bevor Sie eine einzige Funktion bewerten, halten Sie fest, welches OKR jede mögliche Initiative bewegen soll, und benennen Sie, wer für dieses Ergebnis verantwortlich ist. Lässt sich eine Idee keinem aktuellen Ziel zuordnen, landet sie auf einer «Irgendwann»-Liste und nicht auf der aktiven Roadmap. ProductTalk’s argument for outcome-based roadmaps lohnt es sich hier zu verinnerlichen: Teams, die mit «Was sollen wir bauen?» statt mit «Welches Ergebnis streben wir an?» beginnen, driften meist in eine Feature-Fabrik ab und liefern Beschäftigungstherapie, die nie eine Kennzahl bewegt.

2. Wählen Sie Ihr Hauptmodell. Richten Sie es nach Ihrer Fragestellung und Ihren Daten aus. Ein grosses Backlog mit kleinen Ideen sortieren? Nehmen Sie RICE. Ein Release zuschneiden, bei dem es zu viele Anforderungen und zu wenig Sprint-Kapazität gibt? Nehmen Sie MoSCoW mit harter Obergrenze. Voneinander abhängige Plattformarbeiten in eine Reihenfolge bringen? Nehmen Sie WSJF.

3. Sammeln Sie die Eingangsdaten vor der Sitzung, nicht währenddessen. Reichweitenzahlen, Aufwandsschätzungen aus der Entwicklung, Zuversichtswerte, Hinweise auf Verzögerungskosten, was immer Ihr gewähltes Modell braucht. Legen Sie die Bewertungsregeln im Voraus fest (feste Skalen statt offener Schätzungen), damit im Raum nicht über die Methodik diskutiert wird, während es um Prioritäten gehen sollte.

4. Führen Sie die Bewertungssitzung mit einer bereichsübergreifenden Gruppe durch, nicht nur mit dem Produktbereich. Laden Sie Entwicklung, Design und eine Stimme mit Kundenkontakt ein (Vertrieb oder Support), begrenzen Sie die Sitzung auf 60 bis 90 Minuten und bewerten Sie Eintrag für Eintrag anhand der vorab festgelegten Skalen. Wer nicht dabei war, darf das Ergebnis später nicht stillschweigend blockieren.

5. Schliessen Sie mit einer Entscheidungsregel ab. Legen Sie vorab fest, wer das letzte Wort hat, wenn die Werte nahe beieinander liegen oder mitten im Zyklus eine kurzfristige Anfrage aus der Geschäftsleitung auftaucht. Die Empfehlungen des Pragmatic Institute zur Priorisierung behandeln eine namentlich benannte entscheidungsbefugte Person als strukturelle Voraussetzung und nicht als Kür, denn ohne sie wird die lauteste Stimme im Raum stillschweigend zum eigentlichen Modell. Für alles, was hoch bewertet ist, aber auf wackliger Zuversicht beruht, planen Sie ein kleines Experiment oder ein MVP, statt sofort die vollen Entwicklungsressourcen zu binden.

Profi-Tipp: Holen Sie eine technische Leitung auf Teilzeit- oder Interimsbasis in die Bewertungssitzung, wenn die Aufwandsschätzungen das schwächste Glied in Ihren Daten sind. Ein Teilzeit-CTO, der die betreffenden Systeme tatsächlich schon gebaut hat, erkennt aufgeblähte oder geschönte Aufwandswerte, die eine rein produktbezogene Diskussion übersieht.

Wie greifen OKR und Roadmap-Rhythmus ineinander?

OKR sollten als Filter wirken und nicht als Verzierung über einer Funktionsliste, die längst auf anderem Weg entschieden wurde. Jede Initiative, die um einen Platz auf der Roadmap kämpft, muss beantworten: Welches Ziel bewegt sie, und wie stark? Wenn das niemand in einem Satz beantworten kann, ist die Initiative noch nicht reif für die Bewertung.

Der Rhythmus zählt genauso viel wie die Bewertungsmethode selbst. Die meisten Teams, die das gut machen, pendeln sich auf einen Takt wie diesen ein:

• Quartalsweise OKR-Planung, in der die Führung Ziele und Schlüsselergebnisse für die nächsten drei Monate setzt oder überprüft.

• Monatliche Sichtung, bei der die Roadmap anhand frischer Daten neu bewertet wird, nicht von Grund auf neu gebaut, sondern nur angepasst.

• Verfeinerung auf Sprint-Ebene, bei der bereits priorisierte Einträge in baubare Teile für die Entwicklung zerlegt werden.

• Eine separate Überholspur für wirklich dringende Arbeit, etwa ein Sicherheitsfix oder ein defekter Zahlungsablauf, die das volle Bewertungsritual umgeht, aber trotzdem nachträglich einem OKR zugeordnet wird, damit die Nachverfolgung ehrlich bleibt.

Die Empfehlungen von PwC Schweiz zur OKR-Einführung dokumentieren Quartalszyklen als gängige Praxis, und zwar genau deshalb, weil kürzere Zyklen Initiativen zu wenig Anlauf geben, um Ergebnisse zu zeigen, und längere schlechte Wetten zu lange weiterlaufen lassen, bevor es jemand bemerkt. Ein Quartal ist lang genug, um etwas Bedeutsames auszuliefern, und kurz genug, um einen Irrtum einzugestehen.

Experimente und MVP sind der Weg, wie Zuversichtswerte zwischen den Zyklen aktualisiert werden, statt statische Vermutungen zu bleiben. Wenn Sie eine Initiative mit 40% Zuversicht bewertet haben, weil niemand die Annahme getestet hatte, sollte ein zweiwöchiges Experiment, das diese Annahme bestätigt oder widerlegt, direkt in die Sichtung des nächsten Monats einfliessen und nicht in einer Präsentation verschwinden, die niemand wieder öffnet.

Wie messen Sie, ob die Priorisierung funktioniert hat?

Die Bewertungssitzung ist nicht die Ziellinie. Sie ist der Startschuss, um zu verfolgen, ob das Ausgelieferte die Zahl tatsächlich bewegt hat, die Sie versprochen haben.

Wählen Sie Ergebnis-KPI, die direkt auf das OKR einzahlen, gegen das eine Initiative bewertet wurde, und keine generischen Schaufensterkennzahlen. Aktivierungsrate für Arbeiten am Onboarding, Bindungskurven für Funktionen zur Nutzungsintensität, Umsatzzuwachs oder Konversionsrate für Änderungen an der Monetarisierung. Wenn sich eine Initiative keinem KPI zuordnen lässt, den Sie in 30 bis 90 Tagen prüfen können, ist das ein Zeichen, dass sie von Anfang an nicht wirklich auf ein Ergebnis bezogen war, sondern ein Funktionswunsch im OKR-Kostüm.

Verzögerungskosten in einem Satz: Sie schätzen, was Sie an Wert oder Gelegenheit verlieren, für jede Woche oder jeden Monat, in dem eine Initiative ungebaut liegen bleibt. Genau durch diese Zahl teilt WSJF die Aufgabendauer, um dringende Arbeit vor lediglich wichtige zu stellen.

Sobald ein Experiment oder eine ausgelieferte Funktion echte Nutzungsdaten liefert, sollten diese Daten die ursprüngliche Zuversichtsschätzung für alles Vergleichbare ersetzen, das noch im Backlog liegt. Ein Launch, der die Prognosen übertroffen hat, erhöht die Zuversicht für benachbarte Wetten; ein flaches Ergebnis sollte sie senken. Rückmeldeschleifen mit der Kundschaft gehören zum selben Aktualisierungszyklus. Research on customer feedback’s revenue impact untermauert, warum Teams, die Nutzerrückmeldungen systematisch in die Bewertung zurückspielen, meist besser abschneiden als solche, die Priorisierung als einmalige Übung zu Quartalsbeginn behandeln und danach nie wieder anfassen.

Welche Fehler ruinieren die Roadmap-Priorisierung, und wie erkennen Sie sie?

Der häufigste Fehlschlag ist nicht die Wahl des falschen Modells. Es ist die schlechte Anwendung des richtigen. Einige Muster tauchen immer wieder auf.

• Zu viele «Must have»-Einträge. Wenn mehr als 60 % Ihres MoSCoW-Backlogs als «Must» markiert sind, funktioniert die Übung nicht mehr als Priorisierung, sondern ist eine Wunschliste mit zusätzlichem Papierkram, gemäss den Kapazitätsempfehlungen der Agile Business Group.

• Werte als objektive Wahrheit behandeln. RICE- und WSJF-Zahlen wirken präzise, weil es Zahlen sind, doch sie beruhen auf Schätzungen, nicht auf Messungen. Praxisnahe Empfehlungen zur Priorisierung verstehen Bewertungen durchgehend als Gesprächsanlass und nicht als Urteil und raten zu einer kurzen Empfindlichkeitsprüfung bei den Spitzenreitern: Verschieben Sie die Wirkungs- oder Aufwandsschätzung leicht und schauen Sie, ob die Rangfolge hält. Kippt eine kleine Änderung die Reihenfolge, behandeln Sie diese Einträge als gleichauf und entscheiden Sie nach Urteilsvermögen, nicht nach der dritten Nachkommastelle einer Formel.

• Abhängigkeiten ignorieren. Eine hoch bewertete Funktion, die von einer nicht zugeschnittenen Integration oder einer Migration von Altsystemen blockiert wird, bleibt liegen, so gut sie auch bewertet wurde.

• Keine benannte entscheidungsbefugte Person. Ohne sie verkommt Priorisierung dazu, wer in der jeweiligen Woche am lautesten zur Geschäftsleitung eskaliert.

Kurze Prüfliste für eine Roadmap, bei der Sie vermuten, dass sie bereits kaputt ist: Prüfen Sie, ob «Must have»- oder Spitzeneinträge rund 60 % der Liste überschreiten, bestätigen Sie, dass jeder Eintrag einem erklärten OKR zugeordnet ist, und überprüfen Sie, ob Schätzungen zu Verzögerungskosten oder Aufwand tatsächlich existieren und nicht nachträglich eingetragen wurden, um eine bereits gefallene Entscheidung zu rechtfertigen.

Disziplinierte Priorisierung ist nicht bloss eine nette Formalie der Steuerung. Fachbeiträge zur Priorisierungspraxis verbinden ein strukturiertes Vorgehen mit weniger Verschwendung in Forschung und Entwicklung und mit kürzerer Zeit bis zur Marktreife, weil Teams aufhören, halbfertige Initiativen neu zu bauen, die nie hätten freigegeben werden dürfen.

Profi-Tipp: Wenn Ihr Team jedes Quartal dieselbe Entscheidung neu aufrollt, liegt das Problem meist nicht am Modell, sondern an einer fehlenden Freigaberegel. Halten Sie in einem Satz fest, wer bei knappen Werten das letzte Wort hat, und nehmen Sie das in die Vorlage für die Sitzungsagenda auf, damit niemand die Antwort unter Druck erfinden muss.

Ein erfahrenes Entwicklungsteam hat genau dieses Vorgehen schon angewendet, eingebunden vom ersten Gespräch über den Projektzuschnitt bis zur Übergabe, für Kundschaft im Finanzsektor und in der öffentlichen Hand. Genau deshalb, weil Priorisierung ohne technische Fundierung bei Aufwands- und Abhängigkeitsschätzungen dazu neigt, Roadmaps zu erzeugen, die in einer Präsentation sauber aussehen und in der Sprint-Planung auseinanderfallen.

Wie sehen ein Bewertungsblatt und eine Agenda für die Priorisierung aus?

Ein Bewertungsblatt braucht mindestens: Name der Initiative, zugeordnetes OKR, Reichweite oder Umfang, Wirkungsschätzung, Aufwandsschätzung, Zuversichtswert, berechnete Punktzahl und ein Notizfeld für Abhängigkeiten. Ein kurzes durchgerechnetes Beispiel mit einer Bewertung im RICE-Stil:

Eine Agenda für 60 bis 90 Minuten, die funktioniert: (1) das OKR, dem jeder Eintrag zugeordnet ist, nochmals benennen, 10 Minuten; (2) die vorab gesammelten Eingangsdaten durchgehen, 10 Minuten; (3) jeden Eintrag gemeinsam bewerten, 40 Minuten; (4) Gleichstände markieren und bei den obersten drei eine kurze Empfindlichkeitsprüfung machen, 15 Minuten; (5) die freigabeberechtigte Person und die nächsten Schritte bestätigen, 10 Minuten.

Alles, was hoch bewertet wurde, aber auf wackliger Zuversicht ruht, machen Sie vor dem vollen Bau zu einem Experiment: eine Hypothese in einer Zeile formulieren, eine einzige Kennzahl wählen, die sie belegt oder widerlegt, eine verantwortliche Person benennen und einen Zeitrahmen von zwei bis vier Wochen setzen. Wenn Sie Unterstützung brauchen, um aus einem priorisierten Bewertungsblatt zugeschnittene, baubare Arbeit zu machen: Die Produktbegleitung von Ampersand Labs deckt genau diese Übergabe ab, und die Preisseite zeigt, wie Mandate wie Advisory oder Starter für Teams aufgebaut sind, die ab Tag eins eine erfahrene technische Partnerin im Raum haben wollen und nicht erst, wenn die Roadmap bereits feststeht.

Quellen

• Atlassian’s prioritization framework guide

• ProductTalk’s argument for outcome-based roadmaps

Häufige Fragen

Welche 5 Prioritätsstufen gibt es für Aufgaben?

Die meisten Systeme auf Aufgabenebene nutzen fünf Stufen: kritisch, hoch, mittel, niedrig und keine (oder zurückgestellt), meist abgeleitet aus Dringlichkeit und Wirkung statt aus dem Bauchgefühl. Auf Roadmap-Ebene erfüllen die vier Kategorien von MoSCoW (Must, Should, Could, Won't) einen ähnlichen Zweck, nur bezogen auf Funktionen und Initiativen statt auf einzelne Aufgaben.

Was bedeutet die Dreierregel bei der Priorisierung?

Die Dreierregel bedeutet in der Regel, die obersten Prioritäten auf jeweils drei Punkte zu begrenzen, seien es drei Quartals-OKR oder drei Initiativen in aktiver Entwicklung, damit Teams ihren Fokus nicht zu stark verteilen. Sie ist eher eine Frage der Disziplin als ein formelles Modell und passt gut dazu, die «Must have»-Einträge bei MoSCoW auf einen festen Anteil der Kapazität zu deckeln.

Welche Phasen durchläuft eine Produkt-Roadmap?

Eine Roadmap durchläuft typischerweise die Definition des Ergebnisses, die Bewertung und Auswahl von Initiativen, die Reihenfolge entlang von OKR und Abhängigkeiten, Umsetzung und Experimente sowie die Neupriorisierung auf Basis gemessener Ergebnisse. Ergebnisorientierte Roadmap-Empfehlungen beschreiben die erste Phase, also das Festlegen des «Warum», als jene, die Teams am häufigsten überspringen. Genau das führt später zum Abdriften in den Modus der Feature-Fabrik.

Was ist ein gutes Priorisierungsmodell?

Es gibt kein einzelnes bestes Modell. RICE passt zu grossen Backlogs mit kleinen Ideen, Kano zur Differenzierung über das Kundenerlebnis, MoSCoW zum Zuschnitt von Releases, Nutzen gegen Aufwand zu schnellen Entscheidungen im Workshop und WSJF zur Reihenfolge bei vielen Abhängigkeiten und Zeitdruck. Die richtige Wahl hängt davon ab, welche Daten Ihnen zur Verfügung stehen und wie reif Ihr Team ist, wie es auch die Priorisierungsempfehlungen von Atlassian nahelegen.

Empfohlen

• Von der Idee zum Produkt, Lovable & No-Code

• Software-Audits & technische Due Diligence Zürich

• KI-Automatisierung & Workflow-Agenten Zürich