Ich lese zurzeit das sehr spannende Buch „Product Mastery: From Good to Great Product Ownership“ von Geoff Watts. Nach Geoff sollte ein großartiger Product Owner DRIVEN sein:

• Decisive: Willing and able to make decisions with incomplete information, and to allow others to make decisions too.
•  Ruthless:  Maintaining a relentless drive to maximise value and minimise risk while staying focused on the vision.
• Informed:  Cultivating a voracious appetite to know the most possible about your product’s domain while being prepared to act with incomplete information.
• Versatile:  Being responsive to changing circumstances, both in terms of product development techniques and also leadership style.
• Empowering:  Creating a sense of shared ownership amongst all stakeholders and bringing people along with you on the journey.
• Negotiable:  Having faith in one’s vision while also being open to feedback and change.

Als Product Owner schonungslos priorisieren bedeutet, dass du immer die Produktvision (Product Vision) im Blick hast, dich nicht von den individuellen Wünschen der Stakeholder unter Druck setzen lässt, aber dennoch eine gemeinschaftliche Priorisierung durchführst und erreichst. Dein oberstes Ziel ist es, den Wert deines Produktes zu maximieren, dabei die Risiken zu minimieren und die Produktvision im Fokus zu behalten.

1.  Erster Schritt zur schonungslosen Priorisierung: Was wird wirklich benötigt? Von dieser Menge: Was davon kann warten?
2.  Nutze keine simplen Priorisierungssysteme wie Prio 1-2-3, High-Medium-Low oder MuSCoW (Must, Should, Could, Won’t). Bei solchen Systemen besteht die Tendenz, dass plötzlich alle Features die höchste Priorität bekommen und dann sinnlose Abstufungen wie Prio 1a-1b-1c eingeführt werden.
3.  Mache jedem in deiner Organisation klar: Wenn alles dieselbe Priorität hat, dann hat nichts wirklich Priorität.
4.  Nutzer zur Priorisierung immer eine Art Backlog („stack ranking“), in dem keine zwei Anforderungen dieselbe Priorität haben. Für jede Anforderung wird ein Business Value bestimmt, inwiefern eine Anforderung auf die Realisierung der Product Vision einzahlt. Der Business Value einer Anforderung wird relativ zu dem Business Value aller anderen Anforderungen vergeben und zwei Anforderungen haben nie denselben Value.
5. Um tatsächlich absolut schonungslos zu Priorisieren, folge diesen vier Schritte
   • Definiere und Kommuniziere die Product Vision. Schwöre alle Stakeholder auf diese ein, damit die Stakeholder, anstatt nur ihre individuellen Wünsche, immer das große Ganze im Blick behalten und alle fortwährend hinterfragen, ob ein Feature wirklich die Vision unterstützt.
   •   Erläutere den Stakeholdern, dass es zur Risikominimierung unabdingbar ist, zum ersten Launch erstmal nur eine minimale Version des Produktes (des Features) an den Markt zu bringen. Beschreibe wie sich das Produkt nach dem ersten Launch iterativ weiter entwickeln wird. Verdeutliche, dass ein „Nein, nicht jetzt“ nicht unbedingt ein „niemals“ bedeutet.
   • Stelle sicher, dass für jede Anforderung klar ist, inwiefern sie den Business Value des Produktes erhöht. Folgende Aspekte könnten eine Rolle spielen: Kundengewinnung, Kundenbindung, Wettbewerbsdifferenzierung, Einführung neuer Technologien, Wettbewerbsfähigkeit.
   • Gibt es endlose Diskussionen, um eine Anforderung, dann sei schonungslos genug und entscheide alleine, ob sie in das nächste Release kommt oder nicht. Nutze diese dominante Entscheidungsform nur in Ausnahmefällen.
6. Warum fällt es den meisten Menschen schwer, schonungslos zu priorisieren?
   • Die meisten Menschen scheuen Konflikte und wollen andere zufriedenstellen.
   • Viele Menschen scheuen Verluste und sei es einfach nur eine Idee, die man verwerfen soll, obwohl man schon Zeit und Arbeit in sie investiert hat.
7. Wenn du dich unter Druck gesetzt fühlst, deine schonungslose Priorisierung aufzugeben:
   •  Nimmt dir Zeit, um deinen Kopf frei zu bekommen.
   • Fokussiere dich darauf, dass du mit einer strikten Priorisierung höhere Chancen hast erfolgreich zu sein.
   • Spreche über deine Herausforderungen mit einer neutralen Person.
   • Wenn jemand unnachgiebig seinen Wunsch durchsetzen möchte, zeige auf, welche Kosten ein nicht erforderliches Feature verursacht: Kosten für Wartung und Support, Komplexitätssteigerung der Software sowie Opportunitätskosten.
8. Wenn das Team die Entwicklungszeit und Kosten höher geschätzt haben als du erhofftest und du schon das absolute Minimum der Anforderungen definiert hast, dann ziehe folgende Alternativen in Betracht:
   • Entscheide, ob du ein kalkulierbares Risiko eingehst oder ob du die Entwicklung stoppst, um deine Verluste möglichst früh zu begrenzen.
   • Verschiebe die endgültige Entscheidung und entscheide erst nach ein bis zwei Sprints, wenn das Team weitere Erfahrungen gesammelt hat.
   • Hinterfrage schonungslos, ob es Impediments gibt, die das Team davon abhalten günstiger und schneller zu liefern. Wenn ja, behebe diese.
   • Ziehe in Betracht, ein anderes Team zu wählen oder Teile des Teams auszutauschen.
9.  Argumentiere nicht mit dem Entwicklungsteam über ihre Schätzung. Unter Druck könnte das Team versuchen die zeitlichen Ziele zu erreichen und dabei technische Schulden aufbauen. Das Team könnte anfangen weniger zu testen, dann werden Überstunden gemacht, diese führen zu niedrigerer Konzentration und Motivation, was zu mehr Fehler führt, die wegen mangelndem Test nicht entdeckt werden. Technische Schulden müssen immer mir Zinsen zurückbezahlt werden: Erhöhte Wartungskosten, schlechtere Weiterentwicklung und risikoreiche Refactorings.
10. Zu guter Letzt: verinnerliche das Prinzip, dass alle Pläne (z.B. Release Pläne) unpräzise sind und sich als fehlerhaft herausstellen werden. Wertschätze dennoch die Aktivität der Planung im kollektiven Team und die Lernerfahrung, die währenddessen entsteht.

• Was ist das absolute Minimum, das das Produkt zum Launch liefern muss?
• Hast du einen Plan, wie sich dein Produkt in den nächsten 6-18 Monaten entwickeln soll und wissen alle Stakeholder davon?
• Was denkst du, was währen deine Nutzer bereit für die einzelnen Items in deinem Backlog zu bezahlen? Würde diese Einschätzung deine aktuelle Priorisierung ändern?
• Welche Faktoren berücksichtigst du bei der Priorisierung des Product Backlogs?
• • Wert? Kosten? Lernerfahrung? Unsicherheit? Neuartigkeit? Abhängigkeiten?
• Was kannst du unternehmen, dass deine Reaktion auf negative Informationen ruhiger und angemessener ausfällt?
• Nehme einmal an, dass du Fehler machen wirst. Wie könntest du diese Fehler kostengünstiger, schneller und weniger niederschlagend machen?
• Was könnte dein Team motivieren, mehr Ownership, Verantwortung und Stolz für das Produkt zu empfinden?