003 ~ Wie wird man Product Owner? mit Roman Pichler

In dieser Episode spreche ich mit Roman Pichler, Autor des einzigen deutschsprachigen Buchs zum Thema "Agiles Produktmanagement". Es geht um Hintergründe von Product Ownern, wo sie herkommen, wie sie zu Product Ownern werden, und wie sie sich weiterbilden können. Dabei kommt natürlich auch viel zur Sprache, was ein Product Owner können muss.
avatar Toby Baier Paypal Icon Amazon Wishlist Icon Bitcoin Icon
avatar Roman Pichler

Anfang

00:00:00

Gast Roman Pichler () — Produktbezogen — Roman lebt in der Nähe von London — Bücher und Blogs auf Englisch erreichen mehr Leute.

Vorstellung Roman Pichler

00:02:39

Coaching für Product Owner — Hilfe für Organisationen, agil zu werden — Produkte für eigenes Unternehmen (Schulungen — Coaching — Bücher) .

Thema: Wie wird man Product Owner?

00:03:58

Gegenbeispiel: Software-Architekten ohne Vorbereitung zum PO befördern — Es gibt keine Studiengänge zum PO (Breit gefächerte Community mit vielen Hintergründen)  — "Klassische Produktmanager" sind nicht gleich agile Product Owner (betriebswirtschaftliches Wissen ist dennoch sehr wichtig)  — Kommunikation zu Vertrieb und Marketing bei Product Launch — Fachliche vs. disziplinarische Verantwortung: Karriere? — Product Owner Aufgaben sind in klassischen Systemen über mehrere Leute verteilt.

Was bedeutet es, als PO zu arbeiten

00:10:45

(PO ist für den Produkterfolg verantwortlich — PO muss in der Lage und bevollmächtigt sein, Produktentscheidungen zu treffen — PO muss nicht alleine entscheiden — kann und muss sich Hilfe holen um gut informierte Entscheidungen treffen zu können — "PO ist ein agiles Produktmanager" — Produktlebenszyklus begleiten — Product Roadmap erstellen)  — Ein PO ist nicht ein Projektleiter, der Aufgaben verteilt — Certified Scrum Product Owner (CSPO) Kurs — Business Model Canvas — Empowerment / Bevollmächtigung (auch zu wichtigen Stake Holdern "Nein" sagen können)  — Steve Jobs: wichtigster Aspekt der Innovation ist "Nein" zu sagen — In Produktentscheidungen findet man nicht immer einen Konsens, der PO muss entscheiden — Team und Stake Holder in Entscheidungen einbeziehen.

Weiterbildungsmöglichkeiten als PO

00:19:40

Coaching durch z.B. Roman — Schulungen (z.B. zum CSPO) — Lernen von Kollegen, wenn die Organisation bereits agil ist — Bausteine zur Weiterentwicklung (Geschäftsmodell und Strategie — Schaffen der Produktvision — Marktforschung und Ideenvalidierung — Kundenbeobachtung — Wettbewerbsanalyse — Personas)  — PO skill assessment nach Marty Cagan — Roman findet Technological Knowledge nicht so wichtig — "Picasso-eyed-PO: mit einem Auge nach außen, mit dem anderen Auge nach innen schauen" (Roman) — Romans Kunde: Electronic Arts (Physics Engine aus Baustein der Spiele)  — POs sollten wenigstens wissen, was technisch möglich ist, ohne es selbst umsetzen können zu müssen — Entwickler-Team ist wichtig für den technischen Blick — Stake Holder Management (Empathie — zum Sprint Review Meeting einladen — Sprint Retrospektive nutzen)  — Mutig sein (lieber hinterher um Vergebung bitten anstatt vorher zu fragen — nicht auf Empowerment warten, sondern selbst ergreifen)  — Zeitmanagement (Aufgaben des Product Managers sind so vielfältig, dass man gut entscheiden muss, was man tut)  — Zielorientiert arbeiten (Sprint Ziele) .

Wo kommt die Mehrheit der Product Owner her?

00:39:10

Roman sieht es sehr gemischt (klassische Produktmanager — Projektleiter — Business Analysten — Programmierer)  — Alle müssen sich das Empowerment nehmen — Einige können schon einiges, anderes muss immer gelernt werden — Einige Eigenschaften kann man nicht lernen, z.B. Kommunikationsbereitschaft — Fertigkeiten wie "Arbeiten mit User Stories" kann man lernen — Es gibt wenige explizite Product Owner Bücher (Inspired — Lean Startup — Four steps to epiphaniy — Business Model Generation)  — Benutzertests und MVPs können helfen, das Product Backlog zu erarbeiten (Benutzertest — Minimum viable product)  — Verständnis von Scrum und Agile (Iteratives Vorgehen zum gezielten Lernen)  — "Design as if you were right, but test as if you were wrong".

Communities

00:50:13

(Product Camps und Product Tanks)  — UX Community — starke Scrum Master Community — Abschluss mit Bitte um Feedback und Dank.