Product Ownership: Produkte erfolgreich entwickeln

Agile Soft­wa­re­ent­wick­lung nach Scrum sieht die Aufgabe eines Product Owners – oder einer Product Owne­rin – mit spezi­fi­scher Verant­wort­lich­keit für das Ergeb­nis vor. Er oder sie ist Anwäl­tin des Produk­tes und versucht, den maxi­ma­len Nutzen in das zu entwi­ckelnde Soft­wa­re­pro­dukt zu brin­gen. Bei diesem anspruchs­vol­len Job gilt es, Anfor­de­run­gen von Inter­es­sen­grup­pen auszu­ba­lan­cie­ren und mit der fach­li­chen Sicht des Entwick­lungs­teams in Einklang zu brin­gen.

In unse­rem Gespräch erzählt Frank Düster­beck, Agiler Bera­ter der HEC und Geschäfts­füh­rer der Kurs­wech­sel Unter­neh­mens­be­ra­tung, was die Rolle von Product Owner:innen so komplex macht und wie Unter­neh­men mit weni­ger Risiko in die Produkt­ent­wick­lung gehen können. Gemein­sam mit Ina Einemann (Open Know­ledge GmbH) hat er das Buch „Pro­duct Owner­ship meis­tern“ geschrie­ben, in dem sich zahl­rei­che Metho­den nach­le­sen lassen.

Frank Düster­beck: Product Owner ist jemand, der in einem Team gemein­sam mit ande­ren Menschen dafür sorgt, dass eine Problem­lö­sung bezie­hungs­weise ein Produkt herge­stellt wird. Der Product Owner zeich­net für das Ergeb­nis verant­wort­lich: Was soll das Produkt können, damit das Problem, das es lösen soll, auch wirk­lich gelöst wird?

Produkt­ent­wick­lung ist immer ein komple­xes Problem. Es ist wich­tig, die Prin­zi­pien zu kennen und zu können, die dazu führen, dass man komplexe Probleme lösen kann. Produk­ten­wick­lung hat Fokusthe­men, in die zu einem bestimm­ten Zeit­punkt viel Arbeit hinein­ge­steckt werden muss.

Wenn du eine Idee hast, musst du diese erst einmal pitchen, ob sie wirk­lich gut ist. Dann musst du sie anhand von Wünsch­bar­keit, Mach­bar­keit, Lebens­fä­hig­keit, Nach­hal­tig­keit am Markt vali­die­ren: Ist das wirk­lich ein gutes Produkt? Um dann in die Entwick­lung zu gehen. Bei jedem dieser Fokusthe­men bis hin zur Ablö­sung eines Systems muss ein Product Owner wissen, was er machen sollte, damit er dessen Zweck erreicht. 

Dazu muss er ein wahn­sin­ni­ges Set an Metho­den­wis­sen haben und mit den Menschen umge­hen können, die Anfor­de­run­gen an das Produkt stel­len oder es entwi­ckeln.

Ein Product Owner muss rich­tig gut darin sein, ein großes Problem – „irgend­was mit Kunden“ – in klei­nere Probleme aufbre­chen zu können. Einen Auftrag wie „Wir wollen mit unse­rem CRM unsere Kunden verwal­ten“ musst du irgend­wie in hand­hab­bare Häpp­chen brin­gen, damit diese abge­ar­bei­tet werden können. Bis hin zum Beispiel zur User Story, die die Entwick­ler umset­zen können.

Das ist genau das Problem. Du kannst nicht am Anfang alles durch­pla­nen. Mal abge­se­hen davon, dass sich die Anfor­de­run­gen durch unsere dyna­mi­sche Umwelt stetig ändern, musst du immer wieder neu denken. Du fängst mit etwas an, machst  Erfah­run­gen und dann musst du auch bereit sein, einen ande­ren Weg einzu­schla­gen, damit etwas wert­schöp­fen­des Gutes heraus­kommt. Das stumpfe Verfol­gen eines Plans hilft hier nicht weiter und führt zu schlech­ten Produk­ten.

Der Wert ergibt sich aus der Befrie­di­gung der Bedürf­nisse aller Stake­hol­der. Aber eben nicht nur von den Kunden. So gibt es zum Beispiel den feinen Unter­schied zwischen Nutzer und Nutz­nie­ßer. Nutzer eines CRM-Systems könnte jemand sein, der die Daten eingibt. Der zieht aber keinen Nutzen aus dem Produkt. Nutzen ziehen wir zum Beispiel im Marke­ting daraus, indem wir diese Daten nutzen können und damit coole Kampa­gnen machen.

Das ist total wich­tig! Wenn du ein Produkt nutzen musst, obwohl du gar keinen Nutzen daraus ziehst, dann ist es wich­tig, dass die Benut­zung einfach ist. Wenn wir das einfa­cher machen, haben wir durch das neue Produkt schon ein Problem gelöst.

Aber noch mal kurz zurück zum Wort Wert­ma­xi­mie­rer. Wert maxi­mie­ren funk­tio­niert eben nur, wenn der Product Owner die Bedürf­nisse aller Stake­hol­der im Blick hat. Eine total schwie­rige Aufgabe!

Die Unter­neh­men merken, dass Produkt­ent­wick­lung nicht so einfach ist, wie sie manch­mal denken. Sie grei­fen dann zu Metho­den wie zum Beispiel Scrum und etablie­ren auch Product Owner. Häufig sind diese dann aber leider nur Projekt­lei­ter 2.0, denn es wird nicht rich­tig verstan­den, wie Produkt­ent­wick­lung heute geht. Nämlich nur im Team mit verschie­de­nen Exper­ti­sen.

Die Akzep­tanz für „es gibt so eine Rolle“ ist da. Aber das wirk­li­che Verständ­nis, was dahin­ter steckt, nämlich die spezi­fi­sche Ergeb­nis­ver­ant­wort­lich­keit, ist häufig noch nicht da. Es gibt ganz viele Leute, die sollen Product Owner­ship machen, aber wissen gar nicht so genau, wofür sie verant­wort­lich sind und wofür nicht oder wie sie die Verant­wort­lich­keit umset­zen können.

Wenn du als Product Owner ein gutes Produkt machen willst, musst du viele Entschei­dun­gen tref­fen. Das dürfen dummer­weise die wenigs­ten Product Owner.

Oft sind sie nur Erfül­lungs­ge­hil­fen, zum Beispiel für die Fach­be­rei­che. Die Leute kommen mit Anfor­de­run­gen zu ihnen und erwar­ten, dass diese eins zu eins im Produkt umge­setzt werden. Und es sind immer zu viele Anfor­de­run­gen! Die Product Owner können diese nicht rich­tig prio­ri­sie­ren, weil sie viel­leicht gar nicht wissen wonach. Also zum Beispiel: Was bringt den größ­ten Wert? Wie kriege ich die Inter­es­sen der Stake­hol­der über­ein­an­der?

Häufig dürfen sie gar nicht direkt mit den Stake­hol­dern spre­chen. Das macht sie zu Erfül­lungs­ge­hil­fen und eben nicht zu manda­tier­ten Product Ownern. Die Rolle heißt nicht umsonst „Owner“!

Auf der ande­ren Seite ist da das Team, das manch­mal gefühlt gegen den Product Owner arbei­tet oder Schät­zun­gen ablie­fert, die niemals einge­hal­ten werden. Die er aber vertre­ten muss. Es entsteht ein „Die“ und „Ich“.  Etwas, was guter Produkt­ent­wick­lung total wider­spricht, denn diese funk­tio­niert nur im Team. Nicht selten empfin­det der Product Owner Druck durch Stake­hol­der oder durch die Geschäfts­füh­rung, die zum Beispiel fragt: Geht die Produkt­ent­wick­lung nicht schnel­ler? Diesen Druck gibt er an die Entwick­ler weiter, wenn er ihn nicht abfe­dern kann.

In der HEC versu­chen wir über inten­sive Ausbil­dungs­kon­zepte, die über mehrere Tage gehen, für das Aufga­ben­kon­glo­me­rat zu sensi­bi­li­sie­ren. Das ist aber auch immer nur ein tiefer Impuls. Wirk­lich gut helfen können wir, indem wir mit dem/der Product Owne­rin arbei­ten und sie in der konkre­ten Produkt­ent­wick­lung beglei­ten. Ergän­zend bieten wir auch Hospi­ta­ti­o­nen in unse­ren eige­nen Scrum Teams an.

Ganz schlimm ist es, wenn ein Product Owner in einer Company ganz alleine ist und sich nicht austau­schen kann. Gut finde ich dann, Konfe­ren­zen oder User Groups zu besu­chen, um zu netz­wer­ken.

Wich­tig ist auch, dass der Product Owner eine Koali­tion mit den Entwick­lern und dem Scrum Master eingeht. Der Scrum Master soll dabei dem Product Owner helfen, Scrum und die notwen­di­gen Metho­den besser zu verste­hen.

Viele Product Owner haben leider gar nicht die Ausbil­dung, sondern werden einfach so ins kalte Wasser geschmis­sen. Da gibt’s dann noch eine Zerti­fi­zie­rung und dann ist man meis­ter­li­cher Product Owner. So funk­tio­niert das aber leider nicht. Hinzu kommt: Product Owner­ship braucht Zeit. Das ist eben nicht mal so neben­bei gemacht.

Ich rate, erst­mal mit einer klei­nen Produkt­ent­wick­lung anzu­fan­gen. Mit etwas Inno­va­ti­vem viel­leicht. Immer mit dem Bewusst­sein, dass man das auch abbre­chen kann, wenn man erkennt, dass die vier Aspekte Wünsch­bar­keit, Mach­bar­keit, Lebens­fä­hig­keit, Nach­hal­tig­keit, nicht erreicht werden.

An einer klei­nen Produkt­ent­wick­lung zu üben und diese extern beglei­ten zu lassen, finde ich total wich­tig. Man würde mit einer Mini-Ausbil­dung anfan­gen, damit alle ein gemein­sa­mes Verständ­nis für komplexe Produkt­ent­wick­lung bekom­men. Dann kann man Scrum einset­zen und lernen, das ist aber kein Muss. Die spezi­el­len Ausbil­dun­gen in Product Owner­ship, für Entwick­ler und für Scrum Master kann man super am konkre­ten Beispiel machen.

Für größere Produkt­ent­wick­lun­gen stel­len wir jeman­den, der den Kunden Product Owner unter­stützt und auch ausbil­det. Das heißt, wenn wir mit einer Firma als Digi­ta­li­sie­rungs­part­ner in Co-Krea­tion gehen, dann stel­len wir immer ein komplet­tes Team, inklu­sive Entwick­ler, Scrum Master, Proxy-Product Owner.

Es ist sehr viel Bedarf da. Das Risiko in einer Produkt­ent­wick­lung ist gigan­tisch groß. Zu schei­tern kann unglaub­lich viel Geld kosten, egal ob das ein Produkt ist, was deine interne Digi­ta­li­sie­rung darstellt, oder nach außen hin deine Produkte digi­ta­ler macht. Wir sehen über­all, dass zig Milli­o­nen Euro für Digi­ta­li­sie­rung ausge­ge­ben werden, die kein Mensch braucht, oder die nicht funk­tio­niert. Eine Produkt­ent­wick­lung klug anzu­ge­hen und bei Bedarf auch früh stop­pen zu können, ist also essen­zi­ell wich­tig. Nur so können wir den komple­xen Heraus­for­de­run­gen gerecht werden.