Produktfeature priorisieren

Ideen priorisieren, aber wie?

Es existieren zahlreiche Frameworks und Tools, die bei der Priorisierung der Themen für die Produktentwicklung helfen sollen. Die Ansätze besitzen jeweils unterschiedliche Vor- und Nachteile. Es gibt sicher nicht die eine perfekte Methode, denn in Abhängigkeit vom Produktlebenszyklus, den Zielsetzungen oder dem Team funktionieren die Methoden unterschiedlich gut. Daher ist es hilfreich, wenn man sich aus einem Werkzeugkasten bedienen kann, wenn es um die Wahl der richtigen Tools für den Job geht.

Tools für die Produktentwicklung

Eine paar Tools möchte ich heute knapp vorstellen. Hoffentlich kann so ein nützlicher Einstieg in die Thematik vermittelt werden. Sämtliche Methoden können in diesem Blogpost allerdings nicht erläutert werden, da dies den Rahmen sprengen würde. Schreiben Sie mich gerne an, wenn es Bedarf für weitere Infos zum Thema Feature / Backlog Priorisierung gibt.

RICE

Der RICE-Score ist ein Tool für die Priorisierung möglicher Kandidaten für die Roadmap und wurde von Intercom entwickelt. Intercom hat den Ansatz hier sehr gut erklärt.

Um sich der Priorisierung zu nähern, werden bei der Berechnung des RICE-Scores vier Faktoren berücksichtigt:

Reach (Reichweite)

Impact (Auswirkung)

Confidence (Zuversicht / Vertrauen)

Effort (Aufwand)

REACH: Bei der Reichweite wird abgeschätzt, wie viele Personen (z.B. Kunden oder Nutzer) in einem Zeitintervall (bspw. Quartal) durch das Produkt erreicht werden können. Also etwa: wie viele Kunden werden das neue Produkt pro Monat benutzen? Reichweite beschreibt damit also die Menge der Personen oder Events (z.B. bei transaktionaler Nutzung) je Zeiteinheit.

IMPACT: Der Impact bezieht sich auf die Einschätzung der Auswirkung einer Neuerung, wobei Wirkung näher in einem jeweils zu spezifizierenden Kontext definiert sein sollte. Dies kann etwa durch eine Zielsetzung näher bestimmt werden, wie bspw. “how much will this project increase conversion rate when a customer encounters it?” (siehe Intercom). Das bedeutet, dass der Impact in dem Kontext der Geschäftsziele oder in Form von Produkt-Metriken eingeordnet werden muss. Auf einer Skala wird dann der Impact definiert, Intercom meint: “Impact is difficult to measure precisely […] 3 for “massive impact”, 2 for “high”, 1 for “medium”, 0.5 for “low”, and finally 0.25 for “minimal”. These numbers get multiplied into the final score to scale it up or down.”

CONFIDENCE: Wie sicher sind Sie sich, dass Ihre Abschätzung stimmt? Die Zuversicht gegenüber der eigenen Einschätzung wird in RICE prozentual ausgedrückt (100% = hohe Konfidenz, 50% = niedrige Konfidenz). Der Confidence-Wert soll also berücksichtigen, inwiefern man die eigene Prognose belegen kann bzw. wie sicher man sich sein kann, dass ein erwarteter Impact für eine erwartete Reichweite eintrifft. Wenn Sie einen Roadmapkandidaten rein auf Basis des Bauchgefühls bewerten, dann könnten Sie eine Konfidenz von unter 50% angeben. Wenn Sie Daten, Marktanalysen oder Feedback zur Untermauerung Ihrer These vorweisen können, dann können Sie eine höhere Konfidenz angeben, z.B. 80% oder 100%.

EFFORT: Der Aufwand für die Umsetzung einer möglichen Neuerung wird bei RICE auf der Grundlage der Zeit (in “Personen-Monaten” = der Arbeit, die eine Person in einem Monat erledigt) ausgedrückt. Dies berücksichtigt dann übrigens alle Teammitglieder (Product Owner, Design / UX, Entwicklung), die an der Fertigstellung beteiligt sind.

Die Berechnung erfolgt nun ganz Excel-tauglich in der Form:

Reach x Impact x Confidence / Effort = RICE Score

Der RICE Score drückt den erreichbaren Impact im Verhältnis zur Investition aus (“total impact per time worked”).

Eine Excel-Vorlage als Beispiel stellt Intercom auch bereit. So kann man sich einen schnellen Eindruck zur RICE Methode verschaffen.

Meine Bewertung: Instrumente wie den RICE SCORE kann man sich selbst auch anhand eigener Bezugssytem in Excel erarbeiten und dabei differenzierter individuelle Aspekte berücksichtigen. Mir fehlen bei RICE meist ein paar Variablen, die ich durchaus gerne mit betrachte. Risiken sind z.B. nicht eingepreist und ebenso wenig werden Marketinginvestitionen oder Markt- und Wettbewerbssituationen betrachtet. Ob sich die Sache für B2B oder B2C-Produkte gleichermaßen eignet, halte ich ebenso für strittig.

Dennoch zeigt der RICE Score, dass man für die Priorisierung ein Bezugssystem definieren kann, innerhalb dessen man zumindest systematisch die Prioritäten durch die Berücksichtigung verschiedener Faktoren ableiten kann.

Es gibt auch andere Scoring-Methoden / Formeln, die für produktbezogene Priorisierung eingesetzt werden. Z.B. die Weighted Shortes Job First (WSJF) Methode von Don Reinertsen. Man sollte aber bei RICE und anderen Scoring-Ansätzen nicht vergessen, dass es sich bei den zugrundeliegenden Berechnungen stets um “Mondscheinformeln” handelt. Objektivität wird hier schnell suggeriert, aber die Berechnungen sind durch die Wahl der Kriterien jeweils höchst künstlich in diese oder jene Richtung optimiert, zudem ist die Bewertung immer subjektiv. Aus meiner Erfahrung stellen solche Hilfsmittel aber eine gute kommunikative Grundlage dar, die für Folgediskussionen nützlich ist. Ebenso helfen diese Tools bei der Klärung wichtiger Kriterien im Bewertungshorizont - im Falle von RICE muss ja bspw. definiert werden, wonach Impact bestimmt werden soll. Eine Festlegung von Produktprioritäten würde ich auf der Grundlage des RICE Score nicht in jedem Falle vornehmen, schon gar nicht im Bereich B2B. Als Tools ist es aber gut, nützlich und es gehört somit in meinen Werkzeugkasten.

Impact-Effort Analyse

Die Impact-Effort Matrix (auch manchmal als Value-Complexity Matrix zu finden) ist ein handliches Tool, um den erwarteten Aufwand und das erwartete Ergebnis gegenüberzustellen. Es erinnert stark an die ebeso erwähnenswerte Eisenhower Matrix und kann auch in ähnlicher Form verstanden werden. Die Eisenhower Matrix soll bei der Priorisierung von Todos helfen, indem die Dimensionen Urgent (Dringend) und Important (Wichtig) betrachtet werden. Das wird gerne im Zusammenhang mit der Organisation der eigenen Arbeit, also dem Selbst- und Zeitmanagement eingesetzt. Die Impact-Effort Analyse stellt hingegen, wie der Name es bereits verrät, die Dimensionen von Wirkung und Aufwand gegenüber.Es existieren auch weitere Spielarten dieser Betrachtung, etwa wenn Value (Wert) und Complexity (Komplexität) herangezigen werden. Das Ziel ist (wie bei der Eisenhower Matrix) denkbar einfach: man möchte verschiedene Initiativen im gleichen Bezugssystem bewerten und schnelle Handlungsableitungen erzeugen. Aufgrund der Bewertung eines Features nach Aufwand und Impact, wird dieses einem Quadranten der Matrix zugeordnet, welcher dann diese Handlungsempfehlungen nahelegt. Ein hoher Impact bei geringem Aufwand würde z.B. als “QuickWin” betrachtet und eine hohe Priorität implizieren.

Die Impact-Effort-Matrix und die Eisenhower Matrix hat Dr. Albert J Viljoen auf Medium sehr gut zusammengefasst. Dave Gray erklärt die Impact-Effort Matrix auf Youtube im Video, falls man weniger lesen möchte.

Meine Bewertung: Ich halte die Eisenhower Matrix und die Gegenüberstellung von Aufwand und Impact für absolut nützlich. Aber tatsächlich halte ich sie auch für so simpel, dass man diese Erwägungen auch im Kopf erledigen kann, sobald das Prinzip verstanden ist. Anders ist es, wenn man z.B. via Fragebogen oder Excel-Tabelle die gleiche Übung mit mehreren Personen anstellt. Dann können diese kleinen Tools der Diskussion absolut zuträglich sein, denn ein stärker geteiltes Bild von Wirkung (bzw. Wert) und Aufwand (bzw. Komplexität oder gar Investition) kann erreicht werden. Wenn im Team bspw. diskutiert wird, warum ein Feature großen Impact hat, dann sind dies die qualitativen Diskussionen, die eine Gruppe voranbringen. So hilft die Impact-Effort Analyse aus meiner Sicht am meisten als Visualisierungstool für die Diskussion im Team. Problematische Punkte gibt es aber auch. Z.B. ist es erfahrungsgemäß so, dass Aufwände oft sehr schlecht eingeschätzt werden, wenn es um komplexere Produkterweiterungen oder neue Entwicklungen geht. Auch der Impact kann (wenn nicht akkurater bestimmt) völlig fehleingeschätzt werden. Somit würde ich die Aussagekraft des Impact-Effort-Analyse nicht überbewerten.

Opportunity Scoring

Anthony W. Ulwick hat in “What Customers Want: Using Outcome-driven Innovation to Create Breakthrough Products and Services” viel Erhellendes in Form des Opportunity-Driven Innovation Frameworks ins Rennen geschickt. Alex Jupiter fasst wichtige Punkte des Buchs in einem Medium-Artikel zusammen.

Um den Kontext für den Opportunity Score einzuordnen, sollte man sich mit dem Konzept des job-to-be-done auseinandersetzen - hervorragend illustriert von Clayton Christensen in diesem Vortrag. Er beschreibt unterhaltsam, welchen JOB ein Milchshake für den Kunden erledigt, der diesen bei McDonalds morgens um 6:30 Uhr “anstellt”.

Der Opportunity Score aus Ulwick’s Framework hilft zu verstehen, durch welche Änderungen (Änderungen am Produkt oder allgemeiner einer Lösung) sich besondere Möglichkeiten ergeben unbefriedigte Kundenbedürfnisse zu bedienen. Ebenso findet man heraus, welche Kundenbedürfnisse bereits zur Genüge mit einer existierenden Lösung abgedeckt sind.

In dem Ansatz werden Kunden systematisch befragt, z.B. via Fragebogen. Die Befragung zielt auf die Ermittlung der Wichtigkeit (Importance) eines Ergebnisses bzgl. eines Arbeitsschrittes (~ des job-to-be-done) und der Zufriedenheit (Satisfaction) mit einem Ergebnis auf Basis einer bestimmten Lösung ab. Die so ermittelten Daten werden dann zur Berechnung eines OPScore (Opportunity Scores) verwendet. Man kann zuletzt via “Opportunity Landscape” die verschieden guten oder schlechten Gelegenheiten visuell darstellen, so dass im Team weiter die Implikationen für die Produktentwicklung abgeleitet werden können.

Eine gute Erläuterung des Vorgehens beim Opportunity Scoring findet man in einem Post von JP Carrascal / Notes for Growth. Dort heißt es: “The main metric used in the ODI framework is the Opportunity Score. This is the result of an analysis of the gap between the importance that customers assign to the expected outcomes of a job-to-be-done, and how satisfied they are with their current solutions.”

Meine Bewertung: Ich mag den Ansatz aus dem Grund, da er über die Betrachtung von Kostenund Nutzen hinausgeht und sich tiefer mit dem Verständnis von Kundenbedürfnissen befasst. Es werden hier aber auch andere Themen nicht betrachtet, z.B. welche Machbarkeiten oder Investitionen vorausgesetzt werden müssen. Das ist ok, muss aber natürlich berücksichtigt werden. Die Methode ist verhältnismäßig einfach durchführen und gleichzeitig ergiebig. Sie ist zudem nicht auf die eigenen Feature limitiert, sondern kann ebenso im Kontext einer Wettbewerbsanalyse eingesetzt werden. Es schadet definitiv nicht, diese Methode im Repertoire zu haben, wenn es um Priorisierungsfragen geht. Also ab in den Werkzeugkasten! Für kleinere oder einfachere Produktentscheidungen würde man aber vermutlich nicht immer zu Befragungen dieser Art neigen. Insofern ist auch diese Methode eine von mehreren, die man kennen sollte, auch wenn man sie nicht immer benötigt.

Story Mapping

Story Mapping wird häufig in agilen Organisationen eingesetzt, z.B. im Kontext der MVP (Minimal Viable Product)-Entwicklung. Die Methode bietet viel Spielraum für den großzügigen Verbrauch von Post-It’s, und Post-It’s mag schließlich fast jedes Team :)

In einem Artikel über ein “neues Backlog” brachte Jeff Patton 2008 die Idee einer Story Map ins Spiel, weil das flach, listenartig organisierte Product Backlog, bestehend aus vielen User Stories, ihm inzwischen Probleme bereitete. Die Idee der Landkarte half nun dabei, Themen visuell (meist in Form einer Matrix) zu organisieren und sich ein besseres Gesamtbild über das Produkts zu verschaffen. Patton hat eine Schnellübersicht zum Story Mapping als PDF bereitgestellt, die bei ersten Gehversuchen gute Begleitung bietet.

Sunit Parekh von Thoughtworks hat einen sehr netten Beitrag verfasst, den ich an dieser Stelle noch empfehlen möchte. Sein Fazit fällt so aus: “Story mapping is an effective inception tool to create a product backlog in a visually structured way. It helps in building a shared understanding, identify gaps in the backlog, see interdependencies, perform better relative sizing. Further, it can also help in slicing and release planning activities.”

Laut agilealliance.org geht Story Mapping auf ein Problem ein, welches bei der inkrementellen Entwicklung auftreten kann: “One intent of this practice is to avoid a failure mode of incremental delivery, where a product could be released composed of features that in principle are of high business value but are unusable because they are functionally dependent on features which are of lower value and were therefore deferred to future releases.”

Die Methode ist übrigens nützlicher, wenn viele User Stories vorliegen, die es zu organisieren gilt. In diesem Zusammenhang noch ein Verweis auf einen Artikel über das Splitten von User Stories, denn Priorisierung völlig inhomogener oder schlecht aufgeteilter User Stories fällt in der Regel schwer.

Meine Bewertung: Ich finde Story Mapping ist hervorragend für die gemeinsame Arbeit im Team geeignet und hilft dabei, einen geteilten Überblick zum Scope herzustellen. Der Nutzen orientiert sich aber erheblich auch daran, wie aktiv das Team die Landkarte schließlich nutzt. Als einziges Priorisierungsmittel funktioniert diese Methode nicht für Produkte in jedem Abschnitt des Lebenszyklus. Vor allem werden hier typischerweise bestimmte Aspekte außer Acht gelassen, die man in Metrik-orientierten oder formelbasierten Verfahren häufiger wiederfindet. Für eine unakademische MVP-Entwicklung ist der Ansatz aber gut geeignet. Für die Priorisierung würde ich tendenziell selbst eher andere Mittel wählen, aber für die Arbeit im Team und die Erfassung des Gesamtbildes ist Story Mapping aus meiner Sicht gut geeignet.

Buy a Feature

Buy a Feature ist ein relativ einfaches Innovationsspiel, welches man mit Kunden durchführen kann, um an mehr Input für die eigentlich Priorisierung zu gelangen. Es geht dabei vereinfacht gesagt darum, Feature zu bepreisen bzw. Kunden sich von einem festgelegten Budget Feature kaufen zu lassen. Durch die Auswahl und Begründung ergeben sich so neue Einsichten.

Luke Hohmann hat die Durchführung einer Buy a Feature- Session für 4-9 Teilnehmer beschrieben. Auf uxforthemasses.com wird ebenfalls beschrieben, wie Buy a Feature “gespielt wird” und es werden Vorlagen als PDF und Excel angeboten.

Dieser Ansatz sollte hier auch vorgestellt werden, da hier ein interaktiver Rahmen mit realen Kunden geschaffen werden kann, der weiter zu spannenden, qualitativen Ergebnissen führen mag. Für eine strukturierte Priorisierung ist Buy a Feature allerdings nicht auf kontinuierlicher Ebene geeignet, sondern ich betrachte dieses Innovationsspiel eher als zusätzlichen Inputkanal.

Meine Bewertung: Als Workshop-Format und Einstieg in eine qualitativ ergiebige Diskussion halte ich den Ansatz für gut. Für die Priorisierung alleine würde ich ihn nicht benutzen.

KANO Modell

Das Kano Modell habe ich zuvor bereits hier vorgestellt. Es hilft dabei, verschiedene Arten von Produktmerkmalen im Zusammenhang mit der Kundenzufriedenheit zu begreifen. So wird der Fokus auch vor allem auf die Summe aller Merkmale gelenkt, die das Produkt letztlich ausmachen. Ebenso wird, und das vermisse ich oft in anderen Ansätzen, die zeitliche Veränderung in der Wahrnehmung von Merkmalen behandelt. Etwas, das in der Realität eine große Rolle spielt, wie ich finde.

Man kann das Kano Modell systematisch anhand einer Fragebogenauswertung verwenden. Allerdings ist dies nicht die leichtgewichtigste Möglichkeit der Analyse. Inhaltlich halte ich aber die Kernaussagen des Modells für wichtig und empfehle daher, die Summe der Merkmale und Merkmalstypen (z.B. welche Merkmale sind Delighter?) bei der Priorisierung mental zu berücksichtigen. Ein Feature oder Merkmal isoliert zu bewerten ist eine Sache. Eine andere ist es, die Summe aller Produkteigenschaften zu betrachten! Dies wird im Kano Modell besser beantwortet als in manch anderen Methoden, da Eigenschaftstypen bestimmt werden. Ich kann das KANO Modell als Methodenhintergrundwissen nur empfehlen.

Kollaborative Ideation mit dem BOGI

Mit dem Battle Of Glorious Ideas (kurz: BOGI) werfe ich ein eigenes, schlankes Frameworks zur kollaborativen Ideensammlung und -Selektion in den Ring.

Der BOGI ein offenes und schlankes Framework, welches sich nicht starr an 4-5 Metriken orientiert, sondern die Fähigkeiten der Gruppe in den Vordergrund stellt. Dafür wird ein Ablauf als Blaupause vorgeschlagen, die verschiedene Aspekte (Gewichtung, Objektivierung, Machbarkeit etc.) in Kombination bringt, so dass ein kontinuierlicher Prozess möglich wird.

Die Priorisierung von Ideen (z.B. für neue Feature) wird hier kontinuierlich über einen stufenweisen Prozess erreicht, welcher stetig von den beteiligten Personen angetrieben wird. Andere Verfahren können hier leicht integriert werden, etwa um eine Ideenauswahl nach Kriterien einzuordnen.

Mehr Informationen erhalten Sie auf einer der BOGI-Website, dort wird bald auch ein E-Book zur Verfügung stehen. Wenn Sie Neuigkeiten zu dem BOGI von mir erhalten möchten, dann können Sie den conceptMonkey Newsletter abonnieren :)

Mehr Tools für die Priorisierung

Schlanke und oftmals datengetriebene Ansätze sind insbesondere im Kontext Lean Startup stärker verbreitet worden. Auch der Growth Hacking Trend hat eine experimentelle, an bestimmten Metriken orientierten Herangehensweise, weiter verbreitet. Auch mit diesen Themen kann man Podcasts und Bücher füllen, deshalb will ich nur einzelne Fragmente vorstellen:

AARRR

Wenn man sich LEAN Ansätze näher anschaut und Produktprioritäten anhand der Geschäftsmetriken aussteuern will, dann kann man sich z.B. die AARRR Metriken von Dave McClure anschauen. Diese will ich an dieser Stelle gar nicht länglich ausführen, sondern es soll hiermit der Hinweis erfolgen, dass die Ausrichtung an bestimmten Kriterien natürlich implizit die Priorisierung determiniert.

Lean Canvas

Eine Ableitung des allseits bekannten Business Model Canvas ist mit dem Lean Canvas passiert. Auf leanstack.com erfährt man mehr zu dem Ansatz. Es geht bei beiden Ansätzen (Lean + Business Model Canvas) zwar nicht in erster Linie um eine Priorisierung einzelner Feature oder Entwicklungsoptionen, aber die Denke hinter diesen schlanken Ansätzen zur Entwicklung der Geschäftsidee können trotzdem helfen.

Problem vs. Solution Space

Dan Olsen ist Berater und Autor von The Lean Product Playbook. Er weist zurecht immer wieder auf die Notwendigkeit hin, sich genauer mit der Problemseite befassen, wenn es um die Identifizierung der wichtigen Merkmale auf der Lösungsseite geht. Dies klingt zwar vielleicht naheliegend, aber in der Praxis beschäftigen sich Teams leider viel zu oft vorrangig direkt mit der Lösungsseite. Hier eine Präsentation von Dan Olsen, die auch das KANO Modell noch einmal im Kontext aufgreift:

Wie sollte man NICHT priorisieren?

Auch, wenn die folgenden Priorisierungswege ein paar Möglichkeiten aus der Reihe Worst Practices darstellen - man sollte es so einfach nicht machen!

Dringende Anfrage aus dem Vertrieb

Kunden sind Experten im Problembereich (zur Erinnerung: Problem vs. Solution Space), der Vertrieb ist hoffentlich Experte in der Beurteilung, was dem Kunden jetzt verkauft werden könnte bzw. welche Opportunities existieren. Dennoch ist eine Priorisierung auf Basis dringender Anfragen aus dem Vertrieb in der Regel nicht zielführend bzw. nachhaltig.

Dies hat unterschiedliche Gründe …

1 - Einzelanfragen sind nicht repräsentativ. Sie spiegeln nicht unbedingt die Wahrnehmung vieler Kunden wieder und können sich somit sogar als wertlos oder wirkungslos erweisen. Das Ziel sollte sein, ein Produkt für viele Kunden zu verbessern. Eine Prüfung sollte also geschehen.

2 - Anfragen erfolgen oftmals in Form eines Wunsches mit dem direkten Vorschlag wie die Lösungsseite aussiehen kann. Z.B. “Ist es möglich einen Excel-Export für xyz zu bauen?”. Die Frage ist aber, warum eigentlich(?)! Es wird häufig nicht das zugrundeliegende Problem reflektiert (z.B. hat der Kunde ein CRM-System, welches die IT vorgibt und in welches er als Nutzer Daten via Excel importieren möchte), sondern vorschnell ein möglicher Lösungsansatz weitergereicht, der nurmehr das Symptom behandelt. Die Lösungskompetenz sollte aber vom Hersteller / Anbieter ausgehen. Denn eventuell gibt es viel mehr Potential im Kontext des Problems zu lösen oder vielleicht ist die Lösung dieses Problems sogar kontraproduktiv.

3 - Eine Priorisierung auf Anfragenbasis zu kultivieren führt häufig dazu, dass der Lautere gewinnt. Das führt allerdings nicht zwangsläufig zu besseren Erkenntnissen für die Produktentwicklung oder Mehrwerten für den Kunden! Die Einordnung von Anfragen auf Basis einer breitere Datenbasis ist hier sinnvoll.

4 - Anforderungen können in der Einzelbetrachtung absolut Sinn machen. Es kann aber für ein Produkt absolut schädlich sein, wenn nur isolierte Einzelbetrachtungen erfolgen. Zwei Feature, die separat betrachtet Sinn machen, können kombiniert unsinnvoll sein. Insofern sollte immer geprüft werden, inwieweit eine Einzelerweiterung dem Produkt insgesamt zuträglich ist, da ansonsten auch kein Mehrwert für den Kunden geschaffen werden kann.

Nach Bauchgefühl

Ein Bauchgefühl kann stimmen, aber dennoch ist es kein gutes Fundament für die Entwicklung von Produkten. Bauchgefühle sind bestenfalls nicht verifizierte Hypothesen. Einer Hypothese kann man natürlich nachgehen. Dann wird sich hoffentlich zeigen, ob die Annahme ein Volltreffer war oder ursächlich auf die Voreingenommenheit und Verzerrung in der eigenen Wahrnehmung zurückzuführen ist.

Für die Trübung der Wahrnehmung gibt es nämlich viele Gründe (siehe auch Wikipedia: List of cognitive biases, Buster Benson via Medium: Cognitive bias cheat sheet). Samantha Lee hat in Business Insider 20 “cognitive biases” zusammengestellt, die einer guten Entscheidungsfindung im Wege stehen können:

Ein Bauchgefühl kann ein Anlass für die Entwicklung einer Produkthypothese sein, die dann verifiziert werden sollte (durch Tests / Feedback / Daten). Ansonsten ist es eben nur: Bauchgefühl.

Because the CEO wants it

Gleiches gilt für den Klassiker: die C-Suite möchte Feature X oder Entwicklung Y sehen.

Man kann hier vortrefflich unterschiedlicher Meinung sein, ob es nun richtig oder falsch ist, wenn etwa der CEO solche Eingriffe auf die Priorisierung vornimmt. Klar ist aber, dass sich diese Art der Priorisierung nicht in eine nachhaltige Systematik bringen lassen kann und ebensowenig als Finesse aus der Trickkiste des Produkthandwerks betrachtet werden sollte.

Hierarchie ist zwar ein häufiges, aber selten sinnvolles Argument. Es ist natürlich auch problematisch, wenn die Produktorganisation ad absurdum geführt wird. Es wird auf diese Weise nicht bestärkt, dass bessere Argumente, messbare Ergebnisse oder höherer Kundennutzen die bessere Grundlage für die Priorisierung und Produktentscheidungen einnehmen sollen. Also all jenes, was letztlich Produkte und Organisationen nachhaltig voranbringen kann.

FAZIT

Wer die Wahl hat, hat die Qual!

Die Vielzahl der Methoden, von denen ich nur einige angerissen habe, zeigt, dass es nicht die eine universelle Methode für die optimale Priorisierung gibt.

Methoden sollte man wie Tools einsetzen, die manchmal besser manchmal weniger gut für eine Aufgabe geeignet sind. Aus diesem Grunde halte ich es für wichtig, dass Produktteams die relevanten Kontexte ihres Produktes stetig reflektieren und den methodischen Werkzeugkoffer kennen, um situativ zu priorisieren.