6 Wege, Produkt-Features zu priorisieren (+ Tipps & Beispiele)
Wenn Sie mich fragen, sind zwei der wichtigsten Fähigkeiten im Produktmanagement Ihre Prioritäten zu kennen und „Nein.“ sagen zu können.
Heute gehen wir ausführlich auf Ersteres ein (denn das Zweite verdient einen eigenen Leitfaden) und helfen Ihnen, Ihre Arbeit zu priorisieren und alle an Ihren Prioritäten auszurichten.
Ein wichtiger Hinweis zu Frameworks für die Priorisierung von Produktfunktionen
Bevor wir beginnen, die verschiedenen Wege zur Priorisierung Ihres Backlogs zu erkunden, gibt es einen wichtigen Tipp, den ich mit Ihnen teilen muss.
Du willst mehr vom The CPO Club?
Registriere dich für eine kostenlose Mitgliedschaft, um diesen Artikel vollständig zu lesen:
Have an account? Log In
Priorisierungs-Frameworks sind nicht buchstäblich zu verstehen.
Nein, Sie müssen sie nicht genau so anwenden, wie sie im Buch (oder diesem Leitfaden) beschrieben sind. Das Produkt, für das Sie verantwortlich sind, könnte völlig anders sein als die, die der Autor leitete, als er sein Buch schrieb. Unterschiedliche Produkte bedeuten unterschiedliche Realitäten und Bedürfnisse. Es ist also völlig in Ordnung, das Framework an Ihre eigenen Anforderungen anzupassen. Letztlich ist ein gutes Framework das, welches für Sie funktioniert.
Produkt-Priorisierungsframeworks zum Ausprobieren
Wussten Sie, dass es ein Thanos-Priorisierungs-Framework gibt? Sie löschen einfach zufällig die Hälfte aller Funktionen in Ihrem Backlog!
Nun ja, das habe ich mir ausgedacht. Aber Sie verstehen meinen Punkt. Es gibt einfach zu viele Frameworks da draußen. So viele, dass ich sie definitiv nicht alle in diesem Leitfaden behandeln kann. Ehrlich gesagt sind Sie wahrscheinlich auch nicht hier, um sich Dutzende Frameworks zu merken.
Daher werde ich stattdessen die Frameworks erläutern, die ich persönlich in meinem Produktmanagement-Alltag nutze, und Ihnen zu jedem einige praktische Tipps geben. Es lohnt sich auch zu überlegen, wie Sie KI bei der Feature-Priorisierung zusammen mit diesen Frameworks einsetzen können.
1. Kano-Modell
Diese Priorisierungsmethode trägt den Namen des talentierten japanischen Autors und Managementberaters Noriaki Kano. Die Schönheit seines Ansatzes liegt in der Einfachheit.
Kano schlug vor, Ihre Funktionen in diese Gruppen zu unterteilen:
- Basisanforderungen: Dies sind grundlegende Funktionen Ihres Produkts, und deren Fehlen führt zu einem schlechten Kundenerlebnis (schlechte Bindung und Abwanderung sind garantiert). Ein gutes Beispiel dafür ist die Chat-Funktion in Intercom oder die Feedback-Suche für Kunden in G2.
- Leistungsmerkmale: Diese Features schaffen Nutzerwert, je nachdem wie stark sie ausgeprägt sind. Mehr davon bedeutet mehr Wert. Sehen Sie sich zum Beispiel die Akkukapazität/Reichweite eines modernen Elektroautos an. Eine bessere Reichweite schafft (meistens) mehr Wert für Fahrer. Ein weiteres Beispiel ist die Anzahl der Integrationen bei Zapier.
- Begeisterungsmerkmale: Statt direkten Wert zu schaffen und Nutzerprobleme zu lösen, konzentrieren sich diese Funktionen darauf, die Attraktivität Ihres Produkts zu steigern. Schön gestaltete Vision-Bereiche in einem Projektmanagement-Tool oder Ledersitze in einem Auto gehören dazu.
Wenn wir die Beziehung zwischen der Ausprägung dieser Funktionstypen und der von ihnen geschaffenen Kundenzufriedenheit visualisieren würden, sähe das ungefähr so aus.
Hier sehen wir, dass Leistungsmerkmale in ihrer Natur linear sind (das heißt, mehr davon bringt Ihnen mehr Wert). Basisanforderungen hingegen schaffen keinen großen Zusatznutzen. Sie sind vielmehr dazu gedacht, Unzufriedenheit bei Ihren Nutzern zu vermeiden.
Die Kategorie der Begeisterungsmerkmale schließlich sorgt für einen zusätzlichen Zufriedenheitsschub. Doch sie hat überhaupt keinen Effekt, wenn Sie bei Ihren „Basisanforderungen“ gepatzt haben.
Kano im echten Leben
Wie wenden Sie das Kano-Modell im Alltag an? Nach meiner Erfahrung wird Kano selten bei Priorisierungs- oder Brainstorming-Meetings eingesetzt. Der Grund ist, dass es sehr intuitiv ist, und man muss es nicht an ein Whiteboard malen und die Leute bitten, ihre Features nach diesen drei Kategorien einzuteilen.
Stattdessen lehren Sie in der Regel Ihre Stakeholder, im Sinne von Kano zu denken. So werden sie, bevor sie mit einer neuen Funktionsanfrage zu Ihnen kommen, die Idee in Gedanken durch dieses Framework laufen lassen und entscheiden, ob es sich lohnt, sie zu verfolgen oder nicht.
So delegieren Sie einen Teil der Feature-Priorisierung an Ihre Stakeholder und sparen eine Menge Zeit durch kürzere Brainstorming-Sitzungen.
2. MoSCoW-Methode
Die MoSCoW-Methode gehört zu den beliebtesten Methoden zur Priorisierung von Features. Zwei Gründe für ihre Popularität sind die Einfachheit und Effektivität.
Um diese Methode anzuwenden, müssen Sie sich jedes Feature auf Ihrer Liste anschauen und ihm eine dieser vier Prioritäten zuordnen:
- Muss haben
- Sollte haben
- Könnte haben
- Wird nicht haben
In der Regel vergibst du diese Prioritäten basierend auf einer Kombination mehrerer Faktoren, darunter dem Nutzen für die Nutzer, dem geschäftlichen Wert, der strategischen Ausrichtung, der Umsetzungskomplexität und anderen.
So sieht eine typische Liste von Funktionen für einen Musik-Streaming-Dienst aus, wenn du MoSCoW darauf anwendest.
- Hier haben wir dem Offline-Modus die Priorität „Muss haben“ gegeben, da viele unserer Nutzer Musik im Flugzeug hören werden.
- VR-Erfahrungen hingegen haben die Priorität „Wird nicht haben“ bekommen, da die Implementierung sehr aufwendig ist und nur wenige Nutzer ein VR-Headset besitzen.
MoSCoW im echten Leben
Obwohl du MoSCoW hervorragend nutzen kannst, um Priorisierungs-Meetings zu steuern, gibt es einen Nachteil, der es für solche Fälle weniger effektiv macht.
Da die Priorisierung auf einer Kombination mehrerer Faktoren basiert, ist es ziemlich zeitaufwendig, dass jedes Teammitglied die Gründe für seine Produktentscheidungen erläutert. Nach meiner Erfahrung verlaufen MoSCoW-Sitzungen deutlich langsamer und ineffizienter als bei anderen Frameworks.
Das heißt jedoch nicht, dass ich MoSCoW nicht mag. Tatsächlich ist es das Framework, das ich am häufigsten verwende. Mein liebster Anwendungsfall für MoSCoW ist die Funktionsliste in einem PRD.
Ich gebe den Lesern meistens erst Kontext zu Nutzerwert, technischen Komplexitäten und weiteren Faktoren im Dokument, bevor ich die Funktionen aufliste. Wenn sie dann „Muss haben“ neben einer davon sehen, kennen sie den Hintergrund für meine Entscheidung.
So verschafft mir MoSCoW eine leicht verständliche Funktionsliste in einem Product Requirements Document (Produktanforderungsdokument).
3. RICE-Methode
Im Gegensatz zu den vorherigen beiden Ansätzen ist das RICE-Scoring-Modell etwas strukturierter und weniger von intuitiongetriebenen Entscheidungen abhängig. Es identifiziert vier eigenständige Priorisierungsfaktoren und ermöglicht es dir, jeden einzelnen getrennt zu bewerten und zu quantifizieren. Diese Faktoren sind:
- Reichweite (Reach): Gibt an, welcher Anteil deiner Nutzer von dieser Funktion betroffen sein wird.
- Auswirkung (Impact): Das Ausmaß des Nutzens beziehungsweise der Auswirkung selbst.
- Vertrauen (Confidence): Zeigt an, wie sehr du dir sicher bist, dass die erreichten Personen diese Auswirkung tatsächlich spüren.
- Aufwand (Effort): Der zeitliche Rahmen, den dein Entwicklungs- und Produktteam braucht, bis diese Funktion bereit ist.
In der Regel wählst du eine Funktion aus und vergibst dann für jeden dieser vier Faktoren einen Wert zwischen 0 und 10. Im Anschluss berechnest du den RICE-Score mit folgender Formel.
Zum Schluss ordnest du deine Feature-Liste nach der wichtigsten Kennzahl dieses Frameworks – dem RICE-Score (höherer Wert = höhere Priorität). So sieht das Ergebnis einer RICE-Priorisierung aus.
- In dieser Liste sehen wir, dass das neue UI die höchste Punktzahl erhalten hat – dank geringem Aufwand und hoher Reichweite bzw. Auswirkung.
- Die Cloud-Sync-Funktion hingegen steht wegen des hohen Aufwandes für die Umsetzung ganz unten auf der Liste.
RICE-Score in der Praxis
Ich habe mehrfach erwähnt, dass sowohl MoSCoW als auch Kano nicht unbedingt für Priorisierungs- und Brainstorming-Meetings geeignet sind. Doch welches Framework verwende ich dafür? Das ist RICE!
Da du jedem Faktor getrennt eine Punktzahl geben kannst, wird es für die Beteiligten leichter, die Begründung für ihre Entscheidungen in diesen Meetings darzulegen (was bei MoSCoW oft fehlt). Außerdem kannst du die Bewertung der einzelnen Faktoren an die Teammitglieder delegieren, die sich in diesem Bereich am besten auskennen.
Zum Beispiel ist dein Produktentwicklungsteam am besten dafür geeignet, den Aufwand zu bewerten. Deine Datenanalysten wiederum können am besten die potenzielle Reichweite einer Funktion einschätzen.
4. User Story Mapping
Technisch gesehen ist User Story Mapping kein Priorisierungs-Framework. Stattdessen dient es dazu, die anstehenden Aufgaben für Ihr Team zu organisieren und zusätzliche Features zu identifizieren, die für vollständige Nutzerreisen erforderlich sind.
Um eine Story Map zu erstellen, listen Sie die wichtigsten Nutzeraktivitäten (oder Aufgabenbereiche) auf und notieren anschließend die Aufgaben, die die Nutzer für diese Aktivitäten erledigen müssen. Danach listen Sie alle Funktionen auf, die Sie entwickeln müssen, damit Ihre Nutzer diese Aufgaben ausführen können. Sie können dies entweder mit Haftnotizen an einem Whiteboard tun oder eines der vielen dedizierten Tools für Produktmanager verwenden.
So sieht die Karte für einen Musik-Streaming-Dienst aus.
Wahrscheinlich werden Sie an diesem Punkt noch nicht viel priorisieren.
Allerdings hilft Ihnen der Prozess, die notwendigen Features für jede Aufgabe aufzuschreiben, dennoch bei der Priorisierung. Sie werden feststellen, dass für bestimmte Aktivitäten Funktionen fehlen (die für Sie eine Priorität darstellen).
Sie fügen diese fehlenden Funktionen schnell Ihrem Backlog hinzu und schieben sie nach oben, um sicherzustellen, dass Sie diese spezielle Aktivität für Ihre Nutzer erfolgreich abgedeckt haben.
Im oben gezeigten Beispiel haben wir eine MVP-Story-Map, die sich in aktiver Entwicklung befindet (abgeschlossene Stories sind mit einem Häkchen versehen). Wenn Sie sich die Map anschauen, sehen Sie, dass die Aktivität „Account Management“ noch unvollständig ist, da die Social-Media-Logins noch nicht umgesetzt wurden.
Bevor wir also mit der Entwicklung der Künstler-/Albensuche beginnen, sollten wir zunächst die Account Management-Aktivität abschließen.
Story Maps im echten Leben
Genau wie RICE eignen sich Story Maps hervorragend für Ihre Priorisierungs- und Brainstorming-Meetings. Einer der größten Vorteile dieses Frameworks ist die Fähigkeit, die Nutzerperspektive in den Meeting-Raum zu bringen.
Wenn Sie sich die Nutzeraktivitäten und Aufgaben ansehen, ist es für Ihre Teamkollegen weniger wahrscheinlich, Feature-Ideen vorzuschlagen, die nicht den Bedürfnissen und Schmerzpunkten Ihrer Kunden entsprechen. Selbst wenn solche Vorschläge gemacht werden, können Sie diese leicht mit niedriger Priorität einstufen, da sie den Nutzern nicht helfen, ihre Aufgaben zu erfüllen.
5. Opportunity Scoring
Strukturell ist Opportunity Scoring ähnlich wie RICE. Allerdings sind die Kriterien im Opportunity Scoring System im Gegensatz zum Pendant nicht fest vorgegeben, sondern es steht Ihnen frei, diese selbst festzulegen.
Um zum Beispiel Ihre übergeordnete Roadmap mit Ihrem Führungsteam abzustimmen, könnten Sie Produktstrategie-Fit, Machbarkeit und potenzielle Einnahmen als Kriterien wählen. So sieht eine mit diesem Framework priorisierte Roadmap aus:
Hier wurde die Skala 0–5 verwendet, um jeden Faktor zu bewerten und die Summe aller Faktoren für jeden Eintrag auf der Liste zu berechnen.
Scorecards im echten Leben
Aufgrund der Flexibilität bei der Auswahl Ihrer eigenen Kriterien eignen sich Scorecards perfekt für Abstimmungsmeetings mit verschiedenen Teams.
Möchten Sie beispielsweise Ihre Roadmap mit den Rechts- und Sicherheitsteams abstimmen und deren Prioritäten berücksichtigen, wählen Sie Kriterien, die für diese relevant sind (z. B. Risiko einer Klage vs. geschäftlicher Nutzen). Mit Ihrem Marketingteam hingegen könnten Aufwand, Preisintensität, Geschäftsziele, Marktreichweite und Zuversicht als Kriterien dienen.
6. Effort Matrix
Erinnern Sie sich an die Eisenhower-Matrix, mit der Sie Ihre persönlichen Initiativen priorisieren? Die Effort Matrix ist eine angepasste Version davon, die speziell für neue Produktfunktionen gemacht ist.
Der vollständige Name ist Value vs Effort Matrix, da sie die Beziehung dieser beiden Faktoren für jede Ihrer Aufgaben visualisiert. So sieht sie aus:
Sie tragen den Aufwand auf der Y-Achse, den Kundennutzen auf der X-Achse ein. Anschließend teilen Sie – wie bei der Eisenhower Matrix – das Diagramm in vier Quadranten und ordnen Ihre Features entsprechend ihrem Wert und Aufwand zu. Danach priorisieren Sie Ihre Aufgaben in folgender Reihenfolge:
- Schnelle Erfolge (hochwertige Funktionen, die Sie sofort umsetzen können)
- Große Projekte (strategisch wichtige Features)
- Lückenfüller (potenzielle, leicht umzusetzende Features für später)
Funktionen im „Zeitfresser“-Quadranten werden meist verworfen, da es keinen sinnvollen Grund gibt, sie überhaupt in Ihr Backlog aufzunehmen.
Aufwandsmatrix im echten Leben
Sowohl der größte Vorteil als auch der Nachteil dieses Frameworks liegt in seiner Einfachheit.
Der Vorteil besteht darin, dass du den Priorisierungsprozess den Anwesenden leicht erklären kannst und sofort mit dem Auswählen der richtigen Funktionen beginnen kannst.
Der Nachteil ist, dass die Aufwandsmatrix die verschiedenen Faktoren, die eine wichtige Rolle bei der Priorisierung spielen (Vertrauen, Reichweite, Abhängigkeiten usw.), nicht abbildet.
Daher eignet sich dieses Framework am besten für kurze Abstimmungsmeetings, bei denen Details keine große Rolle spielen (da du in der Regel anschließend eine ausführlichere Sitzung mit RICE als Nachfolge hast).
Bringen Sie Ihre Stakeholder mit Ihrer Produkt-Roadmap in Einklang
Die Priorisierung der Arbeit ist wichtig. Aber sie wird keinen Wert haben, wenn Sie nicht alle auf dieselben Prioritäten einschwören. Viele der heute besprochenen Frameworks sind kollaborativ angelegt und sorgen automatisch für diese Abstimmung.
Wenn Sie sich jedoch für eines entscheiden, das nicht erfordert, alle Stakeholder im selben Raum zu versammeln, stellen Sie sicher, dass Sie Ihre priorisierte Liste mit den relevanten Personen teilen und mit deren Erwartungen und Bedürfnissen abgleichen.
Vergessen Sie nicht, unseren Newsletter zu abonnieren, um weitere Ressourcen und Leitfäden zum Produktmanagement sowie die neuesten Podcasts, Interviews und weitere Einblicke von Branchenführern und Experten zu erhalten.
