Die Rolle des Product Owners ist gar nicht so einfach zu verstehen. Der Scrum Guide spricht hier vom Wertoptimierer. Wie geht das nun genau? Ich hätte da zwei Fragen, mit denen wir die Rolle besser verstehen.
Um die Arbeit des POs genauer zu beschreiben, müssen wir die wesentlichen Begriffe für seine Arbeit genauer begreifen.
Jeff Patton weist daraufhin, dass wir uns in technischen Projekten gut überlegen sollen, was wir auf den Markt bringen. Wenn Scrum uns hilft, mehr sinnlose Features zu veröffentlichen, ist noch nichts gewonnen /2/. Er unterscheidet zwischen Output, Outcome und Impact. Im Deutschen würden wir das in etwas mit Arbeitsergebnis, Wirkung und echter Veränderung übersetzen. Ein neues Feature ist zunächst ein Arbeitsergebnis. Die Software hat jetzt eine Funktion mehr. Das kann man zählen. Aber nutzt der Kunde sie auch? Wenn ja, hätte das Ergebnis auch eine Wirkung. Aber ändert sich etwas grundlegend im o. g. Sinne? Dann wäre es wirklich eine Veränderung.
Aber welche Veränderung brauchen wir genau? Hier können wir auf eine Beschreibung von Clayton Christensen zurückgreifen. Er fasst die Kaufentscheidung eines Kunden so zusammen. Kunden kaufen nicht einfach ein Produkt. Sie heuern es an, damit es ihnen im Alltag hilft, unter bestimmten Umständen einen Fortschritt zu machen ("Jobs to be done") /3, Pos. 533/. Dabei sind nicht nur funktionale, sondern auch soziale und emotionale Aspekte zu berücksichtigen. Das Produkt hilft dabei einen Job zu erledigen. Sei es einfach voranzukommen, ein Hindernis beseitigen oder bestimmte Ziele zu erreichen. Das Produkt hilft deshalb, weil die vorherigen Lösungen nicht passten oder gar nicht existierten.
Preis und Kosten sind bekanntlich unabhängige Funktionen /4/. Der Preis sollte sich nicht aus Kosten plus Marge berechnen. Besser ist es, Marktpreise zu finden und das eigene Produkt damit zu vergleichen. Die Marge ergibt sich aus dem Preis abzüglich der eigenen Kosten. Das ist eine wichtige Unterscheidung. Es geht nicht darum, zu welchem Preis ich verkaufen will, sondern darum, zu welchem Preis ich verkaufen kann.
Nehmen wir an, Sie als PO und Ihr bauen eine tolle neue Funktion in ihr Produkt ein. Aber diese Funktion bieten bereits alle anderen Mitbewerber an. Was ist dann der Preis für diese Funktion? Sicherlich werden die Kunden sagen: "Wieso soll ich hierfür Geld bezahlen, wenn ich es bei der Konkurrenz billiger bekommen kann?"
Wenn Sie einen höheren Preis haben möchten, müssen Sie prüfen, warum dieser Preis gerechtfertigt ist.
Wenn ich weiß, was ich wissen will ("Was ändert sich?" und "Wer bezahlt?"), werde ich gute Werkzeuge finden. Wenn mir nicht klar ist, was ich wissen will, helfen auch keine Tools.
Wie entstand die Rolle des Product Owners?
Der Miterfinder von Scrum Jeff Sutherland berichtet aus dem ersten Scrum-Projekt. Das Team hatte zu viele Ideen und feste Termine. Das Team konnte sich nicht einigen, welche Ideen die besten seien. Daher wurde eine Person dazu abgestellt, um herauszufinden, was das Produkt gut macht. Der erste Product Owner ging ständig die Ideenliste durch, horchte sich am Markt um und besprach die Umsetzung mit dem Team. Das hat gut funktioniert. Deswegen wurde die Rolle beibehalten.
Um die Arbeit des POs genauer zu beschreiben, müssen wir die wesentlichen Begriffe für seine Arbeit genauer begreifen.
1. Frage: Was soll sich konkret ändern?
IT-Systeme haben per se erst einmal keinen Wert. Nur geänderte Arbeitsweisen sparen Geld oder führen zu zusätzlichen Einnahmen. John Ward und Elisabeth Daniel argumentieren, dass der überwiegende Nutzen aus folgenden drei Quellen kommt /1/:
- Die Organisation kann nach der Projektinvestition neue Dinge tun oder Dinge anders erledigen. Vorher war dies nicht möglich.
- Die Organisation kann Dinge, die sie sowieso tun muss, deutlich besser erledigen.
- Die Organisation kann aufhören, bestimmte Dinge zu tun, die nicht mehr nötig sind.
Jeff Patton weist daraufhin, dass wir uns in technischen Projekten gut überlegen sollen, was wir auf den Markt bringen. Wenn Scrum uns hilft, mehr sinnlose Features zu veröffentlichen, ist noch nichts gewonnen /2/. Er unterscheidet zwischen Output, Outcome und Impact. Im Deutschen würden wir das in etwas mit Arbeitsergebnis, Wirkung und echter Veränderung übersetzen. Ein neues Feature ist zunächst ein Arbeitsergebnis. Die Software hat jetzt eine Funktion mehr. Das kann man zählen. Aber nutzt der Kunde sie auch? Wenn ja, hätte das Ergebnis auch eine Wirkung. Aber ändert sich etwas grundlegend im o. g. Sinne? Dann wäre es wirklich eine Veränderung.
Aber welche Veränderung brauchen wir genau? Hier können wir auf eine Beschreibung von Clayton Christensen zurückgreifen. Er fasst die Kaufentscheidung eines Kunden so zusammen. Kunden kaufen nicht einfach ein Produkt. Sie heuern es an, damit es ihnen im Alltag hilft, unter bestimmten Umständen einen Fortschritt zu machen ("Jobs to be done") /3, Pos. 533/. Dabei sind nicht nur funktionale, sondern auch soziale und emotionale Aspekte zu berücksichtigen. Das Produkt hilft dabei einen Job zu erledigen. Sei es einfach voranzukommen, ein Hindernis beseitigen oder bestimmte Ziele zu erreichen. Das Produkt hilft deshalb, weil die vorherigen Lösungen nicht passten oder gar nicht existierten.
2. Frage: Ist jemand bereit, für diese Änderung zu bezahlen?
Wir haben herausgefunden, was der Kunde braucht. Wir verstehen seine konkrete Situation. Die neuen Funktionen, die wir ihm anbieten wollen, helfen ihm voranzukommen. Aber ist er auch bereit, dafür zu bezahlen? Und was wäre ein guter Preis?
Preis und Kosten sind bekanntlich unabhängige Funktionen /4/. Der Preis sollte sich nicht aus Kosten plus Marge berechnen. Besser ist es, Marktpreise zu finden und das eigene Produkt damit zu vergleichen. Die Marge ergibt sich aus dem Preis abzüglich der eigenen Kosten. Das ist eine wichtige Unterscheidung. Es geht nicht darum, zu welchem Preis ich verkaufen will, sondern darum, zu welchem Preis ich verkaufen kann.
Nehmen wir an, Sie als PO und Ihr bauen eine tolle neue Funktion in ihr Produkt ein. Aber diese Funktion bieten bereits alle anderen Mitbewerber an. Was ist dann der Preis für diese Funktion? Sicherlich werden die Kunden sagen: "Wieso soll ich hierfür Geld bezahlen, wenn ich es bei der Konkurrenz billiger bekommen kann?"
Wenn Sie einen höheren Preis haben möchten, müssen Sie prüfen, warum dieser Preis gerechtfertigt ist.
Was macht ein PO?
Mit den zwei Fragen "Was ändert sich?" und "Wer bezahlt?" klärt sich auch, was ein PO machen kann. Da fallen mir zum Beispiel folgende Punkte ein:
- Potenzielle Kunden beobachten. In welchen Kontexten sind sie gerade? Welche Jobs müssen sie erledigen? Wo klemmt es genau? Welche Wünsche und Ziele haben sie? User Personae können hier helfen.
- Auf die ganze Benutzergeschichte achten, von Anfang bis zum Ende. Wie könnte ein Kunde das Produkt benutzen, damit er weiterkommt. User Story Maps sind hier sinnvoll.
- Konkurrenzprodukte und Preise suchen und vergleichen. Das Konkurrenzprodukt muss nicht unbedingt die Software eines anderen Herstellers sein. Es kann auch sein, dass der Kunde das Problem ohne Software löst.
- Wissen organisieren. Dazu werden Etappenziele festgelegt, zu denen etwas fertig ist. Dies Zwischenergebnis wird dazu benutzt, um mehr über den Kunden, Funktionsweise, Preisvorstellungen und Technologie zu lernen.
Welche Tools braucht ein PO?
- Welche Tools braucht man, um zu beobachten? Papier, Stifte, Videos, Fotos.
- Welche Tools braucht man, um sich einen Überblick zu verschaffen? Story Maps und Haftnotizzettel
- Welche Tools braucht man, um Preis und Funktionen zu bewerten? Tabellen, Taschenrechner
Wenn ich weiß, was ich wissen will ("Was ändert sich?" und "Wer bezahlt?"), werde ich gute Werkzeuge finden. Wenn mir nicht klar ist, was ich wissen will, helfen auch keine Tools.
Anmerkungen
- /1/ Ward, John ; Daniel, Elizabeth: Benefits Management : Delivering Value from IS and IT Investments. New York: Wiley, 2006.
- /2/ Patton, Jeff ; Economy, Peter: User Story Mapping : Discover the Whole Story, Build the Right Product. Sebastopol: "O'Reilly Media, Inc.", 2014.
- /3/ Christensen, Clayton M. ; Hall, Taddy ; Dillon, Karen ; Duncan, David S.: Competing Against Luck : The Story of Innovation and Customer Choice. Heidelberg: HarperCollins, 2016.
- /4/ Nagle, Thomas T. ; Hogan, John E. ; Zale, Joseph: The Strategy and Tactics of Pricing : A Guide to Growing More Profitably. Harlow: Pearson Education Limited, 2016.
Kommentare
Kommentar veröffentlichen