Sag mal… wie priorisierst du eigentlich? 10 Techniken für klare Entscheidungen.

Eine der Kernaufgaben von Produktmanagern ist das Priorisieren von Arbeitspaketen für das Entwicklungsteam und alle Produktmanager nehmen diese Aufgabe auch wahr. Doch jetzt kommt das Aber: Oft wird nur anhand des eigenen Bauchgefühls entschieden was gebaut werden soll und was nicht.

Auf Nachfrage können POs und Produktmanager meist nicht genau sagen, anhand welcher Kriterien oder Regeln sie priorisieren. Diese mangelnde Transparenz führt ggf. zu Spannungen mit dem Enwicklungsteam oder mit den Stakeholdern.

Wer aber einige Priorisierungstechniken kennt und anwendet sieht klar, trifft fundierte Priorisierungsentscheidungen und kann diese auch besser begründen: so fällt es einem z.B. leichter das NEIN zu einem Feature zu erklären. Und langfristig verschafft man sich damit mehr Freiheit. Denn wer jede Entscheidung schlüssig begründen kann, kann das eigene Priorisierungssystem auch einfach transparent machen und Nachfragen nehmen so mit der Zeit automatisch ab. Denn irgendwann wissen alle: „unser PO, der macht das schon mit der Priorisierung. Der hat den Plan.“ (Mehr zum Thema „warum sind Prios wichtig?“ in Rainers Artikel)

Solange aber jeder denkt, dass ein PO nach „Gutdünken“ entscheidet was wichtig ist, bleiben Entwickler und Stakeholder wachsam und die Nachfragen regelmässig.

Also gilt es, sich mit Priorisierungstechniken zu befassen und dann seinen eigenen Stil zu finden. Mit unserer Liste könnt ihr einfach mal starten. Wir sind gespannt, was davon bei euch zum Einsatz kommt.

Ein Hinweis noch: In manchen Firmen werden Backlog-Items priorisiert, in anderen Kundenprobleme oder User Stories, in wieder anderen KPIs die verändert werden sollen. Ich verwende im weiteren Verlauf meist die Begriffe Backlog-Item, Tasks oder Aufgabe. Einfach, weil sie am gebräuchlichsten sind.

 


Schritt 1 – Du bist dabei!

prios_schritt1

In einem ersten Schritt geht es darum,  aus der Fülle an Backlog-Items diejenigen auszuwählen, die in einem zweiten Schritt in eine bestimmte Reihenfolge gebracht werden sollen. Es geht also darum, zwei Stapel zu machen. Den einen Stapel priorisiert man dann, den anderen betrachtet man zu einem späteren Zeitpunkt erneut.

Folgende Methoden eigenen sich dafür ganz gut:

 

Rocks, Pebbles & Sand

Ziel dieser Übung ist es, alle Backlogitems in drei Cluster einzuteilen:

  • Große, wichtige Themenblöcke die wirklich was bewegen werden, wenn sie umgesetzt sind (zusätzliches Produkt) → Rocks
  • Themen, die für einen Teil der Kunden/Nutzer von Bedeutung sind und das Produkt eher ergänzen (neue Bezahlmethode) → Pebbles
  • Themen die kleiner sind, die man „mal so mitmachen“ kann (SSL-Zertifikat aktualisieren, Bugfixes) → Sand

Hier braucht es keine wirkliche Schätzung mit dem Team oder so. Es geht eher um die Wichtigkeit der einzelnen Themen. Für die weitere Priorisierung kann man den Sand erst mal außer acht lassen und auf Ebene der Rocks und Pebbles arbeiten. Für den Sand plant man einfach ein kleines Zeitkontingent ein und priorisiert den dann auf Tages- oder Wochenbasis dazu. Denn wer erst die großen Steine ins Glas legt, der bekommt den Sand immer irgendwie dazwischen.

rock_pebbles_sand_full

 

Themes

Der Begriff „Themes“ wird in der Produktentwicklung meist in Verbindung mit Roadmaps verwendet. Man entscheidet sich, für einen bestimmten Zeitabschnitt an einem strategisch relevanten Ziel zu arbeiten. Dieses Ziel sollte idealerweise in Form eines Kundenproblems formuliert sein.

Ein Beispiel: „Wir werden in den kommenden [4 Wochen] die Zeit, die ein Kunde braucht um [den Onboardingprozess] zu durchlaufen, drastisch reduzieren. Die angestrebte Zeit liegt bei [3h pro Kunde].“

Die Angaben in Klammer sind dabei natürlich beliebig veränderbar.

Habt ihr solch ein Theme erstellt und mit allen Ansprechpartnern abgestimmt, könnt ihr aus der langen Liste an Backlog-Items die auswählen, die auf dieses Theme einzahlen. Alle anderen Items legt ihr für den genannten Zeitraum beiseite.

 

MoSCoW

Die MoSCoW Methode ist super simple und kann leicht angewendet werden, um erst mal eine Grundlage zu schaffen. Bei dieser Methode legt man zuerst eine Art Meilenstein fest. Das kann ein festes Datum sein oder ein Name für ein Release. (Bespiel Release 1.5)

Anschließend teilt man seine Userstories oder Backlogitems in 4 Gruppen:

  • M – MUST haves: Funktionen, die bis zu dem Meilenstein auf jeden Fall fertig gestellt werden müssen.
  • S – SHOULD haves: Funktionen, die wichtig sind und wenn irgendwie möglich fertig gestellt werden.
  • C – COULD haves: Funktionen, die nur fertiggestellt werden, wenn alles aus Gruppe 1 und 2 fertiggestellt ist.
  • W – WON’T haves: Funktionen, die in dieser Iteration nicht bearbeitet werden.

Themen aus der letzten Gruppe dürfen dann getrost zur Seite gelegt und nicht mehr beachtet werden (natürlich in Abstimmung mit Stakeholdern). Und auch die Backlog-Items aus der vorletzten Gruppe haben erst mal Pause. Innerhalb der Gruppen 1 und 2 sollte mit einer anderen Methode weiter priorisiert werden.

 

Top-Down Strategic Planning

prios_kpis2

Euer Unternehmen hat eine Firmen-Vision oder sogar eine Produkt-Vision? Perfekt! Denn der Sinn selbiger ist es ja, dass alle Anstrengungen im Unternehmen an ihnen ausgerichtet werden können. Vielleicht gibt es ja sogar so etwas wie Fokus-KPIs. Also KPIs, die im kommenen Quartal/Halbjahr/… verändert werden sollen.

Also sammelt alles was es an „Top Down“ Dokumenten gibt und geht eure Backlogliste damit durch. Was nicht zu den strategischen Vorgaben passt pausiert vorerst.

 

Walking Skeleton

Unter einem „Walking Skeleton“ versteht man die einfachste Umsetzung eines kompletten Funktionsbereiches bzw. Geschäftsprozesses. Das „Walking“ bezieht sich auf den Umstand, daß diese erste Umsetzung bereits „lauffähig“ ist. Der Begriff „Skeleton“ beschreibt, daß dabei aber nicht alle Funktionen berücksichtigt sind. Das „Fleisch“ am Knochen fehlt also noch. Einige Unternehmen nennen diese erste Umsetzung auch „Proof of Concept“.

Wichtig bei dieser Selektionsmethode ist es, alle Funktionen auszuwählen, die dazu beitragen, dass man einen Prozess von Beginn bis Ende durchspielen kann. Also z.B. vom Startseitenaufruf, über die Produktsuche, die Produktauswahl, den Warenkorb, die Bezahlung bis hin zum finalen Checkout. Alles ist dann nicht hübsch und vielleicht auch noch nicht richtig kompfortabel, aber es „geht“.

 


Schritt 2 – Reihenfolge

Der erste Schritt ist getan: ihr habt nun eine überschaubare Anzahl an Backlog-Items/Ideen (30-50 ist ganz gut) und wisst, welche Themen es nun gegeneinander zu priorisieren gilt. Dann könnt ihr mit folgenden Methoden eine echte Reihenfolge („there aren’t two prio 1 topics!!“) in euer Backlog bringen:

 

Business Value Based

Danach, so die gängige Literatur, sollten Backlogs immer priorisiert sein. Sind sie aber sehr selten. Denn in vielen Unternehmen werden Business Ziele gar nicht so klar kommuniziert, dass der PO danach priorisieren könnet. Was fatal ist.

Also fragt ruhig mal wieder nach Business Cases, Forecast Dokumenten, KPI Scorecards. Was glauben das Management oder die Sales-Kollegen bringt den Kunden wirklich einen Mehrwert? Für was wären die Kunden bereit zu bezahlen. Aber auch Entwickler haben hier einen großen Anteil: Welche Teile der Software machen unproportional viel Arbeit und sind damit nicht wirtschaflich? Oder ihr seht euch nach manuellen Prozessen im Unternehmen um. Ggf. ist auch mit deren Automatisierung Business Value zu stiften.

Am Einfachsten erfolgt hier die Priorisierung mit dem „buy a feature“-Spiel. Der PO sammelt zuerst alle Features, Anforderungen, Kundenwünsche etc. und notiert diese auf Karten. Dann lädt man das Team und alle Stakeholder (Sales, Customer Support, Marketing, …) zu einem Meeting ein. Jeder Teilnehmer erhält einen fiktiven Geldbetrag, sagen wir 100 Euro und kann dann damit Features „kaufen“. Jeder darf seinen Geldbetrag frei aufteilen. Anschließend wird addiert, welche Features am teuersten erkauft wurden. Diese haben den größten Business Value.

 

Plus, Null, Minus – Priorisierung nach Kriterien

Bei der Priorisierung mit Kriterien ist vorher etwas Kreativität gefragt. Denn das Team oder der PO muss sich geeignete Kriterien ausdenken. Alle Backlog-Items / User Stories gilt es dann in jeder Kriterienkategorie zu bewerten. „+“ steht dabei für hoch / groß / ja, „0“ für neutral  und „-“ gering / klein / nein. Hier ein Beispiel:

Wichtigkeit für den Nutzer Anforderung klar? Bringt Wettbewerbsvorteil? Komplexität der Umsetzung
Userstory 1 + +
Userstory 2 0 + 0 +
Userstory 3 + 0 0

Hinweis: bei der Formulierung bzw. Bewertung gilt es darauf zu achten, im gleichen Modus zu bleiben um die Werte summieren zu können. Beispiel: „Abhängigkeit zu anderen Teams“ -> bestehen keine Abhängigkeiten, so ist dies positiv also mit „+“ zu bewerten.

Gute weitere Kriterien sind:

  • Abhängigkeit zu anderen Teams
  • Technisches Risiko bei Nichtimplementierung
  • Bringt technische Verbesserung
  • Verändert den Lifetimevalue des Kunden (wir verdienen mehr je Kunde)
  • bringt neue Verdienstmöglichkeiten
  • Verringert Kündigungen/Absprung
  • Erhöht Kundenbindung
  • Verbessert Kundenservice
  • vergrößert unser Einflussgebiet geografisch
  • Führt zu mehr mobilen Zugriffen
  • …..

 

Relative Weight Methode

Nach der „Relative Weight Methode“ wird jedes Backlog-Item nach den vier Faktoren Vorteil, Strafe, Risiko und Kosten jeweils mit einer Zahl von 1 – 9 bewertet:

  • Vorteil: Wie groß ist der Vorteil (oder Wert) wenn das Feature existiert?
  • Strafe: Wie groß fällt die Strafe aus, wenn das Feature nicht existiert?
  • Risiko: Wie hoch ist das Implementierungsrisiko, sind Abhängigkeiten zu anderen Teams oder wie hoch ist das technische Risiko?
  • Kosten: Wie hoch sind die Kosten für die Umsetzung?

Die ersten beiden Dimensionen bewertet der PO mit Kunden und Stakeholdern, die letzten beiden bespricht er mit dem Team. Anschliessend werden die Werte der ersten beiden Dimensionen addiert und durch den addierten Wert der letzten beiden Dimensionen geteilt.

prios_weight1

 

KANO Methode

Bei der Kano-Analyse wird eine Befragung von Anwendern durchgeführt, durch die eine Klassifizierung von Funktionalitäten eines Produktes in verschiedene Kategorien möglich ist:

Basisfaktoren: Basisfaktoren setzen die Anwender als selbstverständlich voraus, sie sind unbedingt erforderlich. Sind solche Funktionen enthalten, entsteht zwar keine Zufriedenheit. Fehlen sie aber, kann Unzufriedenheit entstehen. Zum Beispiel wenn man mit dem neuen Handy nicht Telefonieren kann.

Leistungsfaktoren: Diese wirken linear. Je mehr dieser Faktoren ein Produkt enthält, desto mehr Zufriedenheit kann erzielt werden. Leistungsfaktoren können ebenso Unzufriedenheit bei einem Produkt beseitigen. Zum Beispiel das kostenlose Versionsupdate aller Windows-Systeme auf Windows 10.

Begeisterungsfaktoren: Begeisterungsfaktoren sind Funktionen, die der Anwender so nicht erwartet, sie überraschen ihn in höchst positivem Maß. Sie sind die Kirsche auf dem Kuchen und oft die abgrenzenden Merkmale zum Wettbewerb. Die „automatisch Parken“-Funktion bei Autos stellt aktuell solch eine Funktion dar.

Um belastbare Ergebnisse zu erzielen, muss eine nennenswerte Anzahl an Nutzern befragt werden. Die Zahl hängt dabei von der Anzahl der Produktnutzer insgesamt ab. Ab 20 – 30  Befragten werden gute Ergebnisse erzielt.  Die Befragung kann mit einem Online-Survey erfolgen. Wie genau der Fragebogen aufgebaut werde sollte liest man hier.

Die Ergebnisse aus der Kano-Analyse helfen bei der Release-Planung. Die Basisfaktoren gelten als Pflicht und müssen alle geliefert werden, da sie sonst potentielle Unzufriedenheit beim Nutzer generieren. Leistungsfaktoren steigern die Zufriedenheit und sind zum Beispiel hilfreich für die Produktvermarktung. Ein Release sollte also einige Leistungsfunktionen beinhalten. Außerdem sollte je Release auch eine begeisternde Funktion enthalten sein. Damit wirkt man innovativ und differenziert sich vom Wettbewerb.

 

Validated Learning (lean startup)

Bei dieser Methode priorisiert man keine Backlog-Items, sondern Experimente. Man stellt eine Reihe an „Assumptions“ also Annahmen auf und priorisiert diese. Und zwar nach der Warscheinlichkeit ihrer Richtigeit und dem Risiko, das sie in sich tragen.

Ein Beispiel für die Risikobewertung: Nehmen wir an, wir wollen Eiscreme für Haustiere auf den Markt bringen. Dann wäre ein Annahme, dass Tiere gerne kalte Nahrung zu sich nehmen. Was eine riskante These ist. Denn wenn wir hier nicht richtig liegen, macht unser Produkt keinen Sinn. Es wird scheitern.

Die Annahmen mit dem höchsten Risiko und der höchsten Warscheinlichkeit auf Richtigkeit untersuchen bzw. testen wir zuerst. Sie werden also höher priorisiert.

[Alle Kunden sind von der langsamen Antwortzeit unserer Webseite genervt] kommt also vor [Bei Vollmond können weibliche Kunden über 50 die FAQ nicht einsehen]

Im Anschluss an die Priorisierung überlegen wir uns ein Experiment, mit dem wir unsere Annahme überprüfen können. Für jedes zum Lernen designte Experiment wird zuvor festgelegt, was als Erfolg gilt. Die Validierung kann sowohl qualitativ, z.B. durch Befragungen (Customer Interviews), als auch quantitativ, etwa durch Messungen, erfolgen.

Umgesetzt wird dann nur, was auch wirklich validiert wurde. Gegebenenfalls kann vorher dann z.B. nochmal eine „Relative weight“-Bewertung erfolgen, die die Umsetzungskosten berücksichtigt.

 


Schlussbemerkung

Wer diese Methoden einmal ausprobiert, wird schnell seine Lieblingsmethoden finden. Wichtig ist es daher, Zeit für das Kennenlernen der Methoden und den Priorisierungsprozess ganz generell einzuplanen. Ich persönlich mache gerne alle 3 Monate eine größere Priorisierungsrunde und nehme dann nur noch kleinste Feinjustierungen vor. So ist man nicht ständig im Modus des Abwägens und Erklärens. Und ich richte den Plan für die 3 Monate jeweils an mindestens einem echten Outcome für den Nutzer aus und priorisiere alle Funktionen darum herum. Ich stelle mir also die Frage: was wird sich in 3 Monaten für den Nutzer merklich verändert haben? Daraus kann man vielleicht sogar schon mal die Pressemitteilung schreiben. Dann verliert man das Ziel auch sicher nicht mehr aus den Augen.

Teilt gerne eure Erfahrung zum Thema Priorisierung in den Kommentaren. Vielleicht habt ihr ja auch noch eine weitere Methode entdeckt, die für euch super funktioniert.

Über Petra Wille

Petra Wille studierte Informationstechnik (Dipl.-Ing. (BA)) und war zuletzt, nach Stationen bei SAP, Hubert Burda Media und der XING AG bei der tolingo GmbH in Hamburg als „Managing Director“ tätig. Seit 2013 ist Petra Wille freiberufliche Produktmanagerin und arbeitet für Ihre Kunden an neuen Produktideen: immer mit agilen Projektmethoden und meist in internationalen, auch verteilten Entwicklungsteams. Außerdem berät und coacht sie Produktmanager und vermittelt Methoden und Handwerkszeug für ein professionelles, dynamisches Produktmanagement. Neben Ihrer freiberuflichen Tätigkeit ist Petra Wille begeisterte Kitesurferin und schreibt für produktbezogen.de

3 Kommentare

  1. Reka

    Danke für die vielfältigen Methoden, kannte einige noch nicht und werde sie gerne ausprobieren.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.