Die Produktwerker Archiv

Der heutige Arbeitsmarkt zeigt einen klaren Wandel. Teilzeitmodelle werden immer beliebter. Daher beschäftigen wir uns in dieser Folge mit dem Konzept als Product Owner in Teilzeit. Wir sprechen nicht nur über die Gründe sondern besonders über Vor- und Nachteile und insbesondere über die Herausforderungen. Product Owner in Teilzeit müssen sich stark fokussieren. Die Zeit ist begrenzt, mehr noch als bei einer Vollzeitstelle. Und oft gibt es für die Teilzeitstelle auch noch einen Grund, der eine absolute Flexibilität erschwert. Product Owner müssen daher sicherstellen, dass sie die richtigen Aktivitäten durchführen. Wann findet man die Zeit mit den Stakeholdern und auf welcher Flughöhe befindet man sich hauptsächlich? Hier helfen bestimmte Techniken wie beispielsweise das Product Ownership Evolution Modell oder Delegation Poker. Wichtig ist aber in erster Linie, dass Product Owner vor lauter operativer Arbeit nicht vergessen auch einen großen Teil ihrer Zeit auf strategische Aktivitäten zu legen. Da die Zeit aber so beschränkt ist können (und manchmal müssen) Aufgaben an das Team abgegeben werden. Beispielsweise sollte das Team in User Tests eingebunden oder mit Supportern wie UX-Dienstleistern zusammengearbeitet werden. Daher kann ein Teilzeitmodell sogar eine Chance sein eine PO-Rolle zu etablieren, die sich auf das Wichtigste konzentriert: Den erzeugten Wert zu maximieren. Wir freuen uns über euer Feedback, besonders, wenn ihr auch Erfahrungen als PO in irgendeiner Form eines Teilzeitmodells habt. Gern auf LinkedIn oder unserem Blog.

Als Produktmanagerin und Product Ownerin sollte ich die relevanten Daten zu meinem Produkt kennen. Und diese Daten dann für die Entscheidungsfindung heranziehen. Oliver hat sich in dieser Podcastfolge die Product Management Coach und Trainerin Büşra Coşkuner eingeladen, um in das Thema Data-Fluent Product Manager, gute Metriken und hilfreiche Frameworks einzutauchen. Zu Beginn des Gesprächs reflektieren die beiden, dass Entscheidungen nach ihren Erfahrungen in der Produktentwicklung in der Regel noch zu sehr aus dem Bauch heraus getroffen werden. Daten können dabei helfen, die Qualität von Entscheidungen zu verbessern. Allerdings sollte ich als PO nicht in die Falle laufen, zu viele Daten zu sammeln, sondern mich auf die wirklich relevanten Daten zu konzentrieren. Die Beschäftigung mit Frameworks kann ein Startpunkt sein, die Sprache der Daten zu erlernen - spricht ein Data-Fluent Product Manager zu werden. So kann ich Kommunikations verändern und bei meinen Stakeholdern Vertrauen schaffen. Denn Wissen führt ihrer Meinung nach zu Vertrauen. Wie immer schließt die Folge mit ganz proaktischen Tipps und Tricks von unserer Gästin. Falls Du mit Büşra Kontakt aufnehmen oder ihr folgen möchtest, kannst Du Dich über ihr [LinkedIn Profil](https://www.linkedin.com/in/busra-coskuner/) mit ihr verbinden. Sie schreibt regelmäßig auf LinkedIn und hat auch einen [sehr guten Blog](https://www.busra.co/blog) zu diversen Themen für Product Manager.

Der Produktschnitt im Kontext der agilen Organisationsentwicklung bezieht sich auf die Aufteilung der Teams rund um die Entwicklung eines Produkts oder einer Produktlinie. Es geht darum, die Teams so zu strukturieren, dass sie effektiv und effizient zusammenarbeiten können, um die Produktentwicklung voranzutreiben. Durch eine kluge Aufteilung der Verantwortlichkeiten wird sichergestellt, dass jedes Team über eine klare Aufgabe verfügt und seine Expertise in diesem Bereich entwickeln kann. Der Produktschnitt spielt eine entscheidende Rolle bei der Förderung agiler Prinzipien und der Maximierung des Produkterfolgs. Durch die Aufteilung der Teams nach Produkten, Produktkomponenten oder Kundensegmenten wird eine hohe Spezialisierung ermöglicht. Jedes Team kann sich auf seinen zugewiesenen Bereich konzentrieren und ein tiefes Verständnis entwickeln, was zu schnelleren und effizienteren Ergebnissen führt. Gleichzeitig fördert der Produktschnitt die Zusammenarbeit zwischen den Teams, um sicherzustellen, dass die verschiedenen Teile des Produkts gut aufeinander abgestimmt sind. Genauso kann sich dies aber auch gegenteilig auswirken, wenn zu große Abhängigkeiten zwischen den Teams entstehen. **Ansätze für den Produktschnitt** Es gibt verschiedene Ansätze zur Aufteilung der Teams im Produktschnitt, die je nach den Anforderungen und Gegebenheiten der Organisation gewählt werden können. Eine Möglichkeit besteht darin, die Teams nach Produktkomponenten oder den Schritten eines Transaktionsprozesses zu strukturieren. Jedes Team ist dann für einen bestimmten Teil des Produkts verantwortlich und trägt die Verantwortung für dessen Entwicklung und Verbesserung. Eine andere Option besteht darin, die Teams nach Kunden- oder Marktsegmenten oder Regionen zu gliedern, sodass jedes Team auf die Bedürfnisse und Anforderungen einer bestimmten Zielgruppe spezialisiert ist. Eine dritte Möglichkeit ist die Aufteilung nach spezifischen Funktionen, bei der jedes Team bestimmte Aufgaben oder Funktionen übernimmt, unabhängig vom Produkt oder Kundensegment. Die Teamstruktur im Rahmen des Produktschnitts hat viele Vorteile. Einer der wichtigsten Vorteile ist, dass die Teams sich auf spezifische Bereiche fokussieren und ein tiefes Verständnis für diese entwickeln können. Dadurch können sie effektiver arbeiten und spezifischer einen ganz bestimmten Teil des Produkts verbessern, da sie sich auf ihre spezielle Expertise und ein tiefes Nutzerverständnis konzentrieren können. Gleichzeitig erfordert der Produktschnitt die Zusammenarbeit und den Wissensaustausch zwischen den Teams, um sicherzustellen, dass die verschiedenen Teile des Produkts gut aufeinander abgestimmt sind. Die Wahl der geeigneten Teamstruktur hängt von verschiedenen Faktoren ab, wie zum Beispiel der Komplexität des Produkts, den Anforderungen der Kunden und den vorhandenen Ressourcen. Es ist wichtig, die Teamstruktur kontinuierlich zu evaluieren und anzupassen, um sicherzustellen, dass die Teams effektiv arbeiten und dass das Produkt schnell und effizient entwickelt wird. Nach unserer Veröffentlichung ist gerade im SoftwareArchitekTOUR-Podcast das fachliche Schneiden mittels Domain Driven Design (DDD) erschienen: "Domain-driven Transformation – Mit DDD Legacy-Systeme transformieren". Findet ihr bei Heise Developer. Welche Erfahrung habt ihr schon mit den verschiedenen Teamstrukturen in der Produktentwicklung gemacht? Waren sie positiv oder gab es Probleme? Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels (https://produktwerker.de/produktschnitt-teamstruktur/) teilst oder auf unserer Produktwerker LinkedIn-Seite (https://www.linkedin.com/company/produktwerker). **Folgt uns Produktwerker auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Fake Door Tests werden genutzt, um das Interesse und die potenzielle Nachfrage für ein Produkt zu testen, bevor es tatsächlich entwickelt oder eingeführt werden. Letztlich kann dies ein entscheidender Schritt zum Problem-Solution-Fit sein. Tim hat mit Nader Fadl einen Experten zu Gast, der in dem Themenfeld promoviert sowie als Dozent für Markenkommunikation und Marketing Analytics aktiv ist. Nader geht somit von der wissenschaftlichen Seite an Methoden des User Testing heran, zugleich aber auch als Praktiker. So hat er mit seinem StartUp experial durch den Einsatz von No-Code und KI eine stark vereinfachte und schnelle Möglichkeit zur Umsetzung von Fake Door Tests geschaffen. Falls ihr diese Testing-Methode noch nicht kennt: Bei Fake Door Tests wird quasi eine "falsche Tür" erstellt, wie zum Beispiel eine eigene Landing Page oder ein Menüpunkt, Teaser o.ä. in bestehenden Apps oder Webseiten, die jeweils das Produkt oder die Dienstleistung bewerben. Potenzielle Kunden können auf diese "Tür" klicken oder reagieren, und basierend auf ihrem Verhalten und Feedback wird entschieden, ob es sich lohnt, das Produkt oder die Dienstleistung tatsächlich zu entwickeln. Es ist also Teil der Product Discovery, um dem Value Risk zu begegnen (hierzu haben sind in diesem Podcast bereits verschiedene Episoden erschienen). Es ermöglicht Unternehmen somit, wertvolle Informationen zu sammeln, um fundierte Entscheidungen zu treffen und Ressourcen effizient einzusetzen. Folgende Podcast-Episoden passen zu diesem Thema: - Kontinuierliche Product Discovery in Teams etablieren - Welche Rolle Product Discovery in der Arbeit von Product Ownern spielen sollte Wer weitere Fragen an Nader Fadl hat oder von ihm bei der Durchführung schneller Experimente unterstützt werden möchte, kann mit ihm am Besten via LinkedIn (linkedin.com/in/nader-fadl/), per Mail (nader@experial.ai) oder über die Webseite experial.ai in Kontakt treten. Oder ihr folgt seinem StartUp experial auf LinkedIn (linkedin.com/company/experial). Welche Erfahrung habt ihr schon mit Fake Door Tests gemacht? Scheiten sie bei euch auch meist an der Umsetzungsdauer? Man redet vielleicht drüber, setzt sich aber am Ende dann doch nicht ein und vertraut auf sein Bauchgefühl? Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite. **Folgt uns Produktwerker auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Routinen und Gewohnheiten sind all jene Tätigkeiten, die wir immer wieder ausüben, ohne groß darüber nachzudenken. Beispielsweise stehen wir morgens auf und putzen unsere Zähne. Wir denken nicht mehr darüber nach, sondern machen es einfach. Abends machen wir vielleicht noch Dehnübungen für unseren Rücken und gehen dann mit einem Buch ins Bett - auch das geschieht wieder ohne großes Nachdenken. Wir entwickeln kleine Rituale, die fast automatisch ablaufen und uns helfen, den Tag zu strukturieren und uns zu organisieren. In dieser Folge sprechen Tim und Dominique darüber, welche Gewohnheiten und Routinen als Product Owner helfen können. Zum Beispiel können Blocker-Morgen und -Abende uns dabei helfen, unsere eigenen Aufgaben zu organisieren. Ein leerer Posteingang am Abend kann befreiend wirken und sich klarzumachen, welche die drei wichtigsten Aufgaben am kommenden Tag sind, hilft beim Fokussieren. Aber auch bei der Zusammenarbeit mit Stakeholdern helfen Routinen, um sich regelmäßig auszutauschen und miteinander im Kontakt zu bleiben. Hier lohnt es sich zum Beispiel, grundsätzlich nicht direkt nach dem Daily in den eigenen Mails zu versinken, sondern die Zeit bereitzuhalten, um mit Teammitgliedern noch etwas zu klären oder auch einfach mal so zu sprechen. Neben der ganzen strategischen und operativen Arbeit darf jedoch auch die persönliche Weiterentwicklung nicht fehlen. Feste Zeitfenster am Tag, um doch mal die ganzen spannenden Bücher zu lesen oder die Gewohnheit mittags mit jemandem zusammen spazieren zu gehen und ein paar interessante Themen zu reflektieren, können helfen, sich kontinuierlich weiterzuentwickeln. Dennoch sei hier direkt ein kleiner Warnhinweis vermerkt: zuviele Routinen und Gewohnheiten machen uns starr. Wenn wir welche für unser Leben einführen wollen, lasst uns einen Schritt nach dem anderen gehen. Die Überforderung kommt sonst schnell und wir verkehren die Vorteile in Nachteile. Uns hilft seit Jahren der Austausch in einem offenen Format. Das Lean Coffee für Product Owner organisiert sich mittlerweile auf LinkedIn (https://www.linkedin.com/groups/12524562/). Hier treffen sich alle zwei Wochen Interessierte rund um die Verantwortung als Product Owner zum Austausch. Jeder darf ein Thema mitbringen! Vielleicht ist es für euch ja auch spannend.

Wie bitte? In nur wenigen Wochen von der Idee zur Marktreife eines Produkts? Wie soll das denn bitte gehen? Tim hat Johannes Geske als Gast dazu eingeladen, denn er hat als Product Owner im Kundenauftrag für eine weltweit aktives B2B Unternehmen gezeigt, wie sowas mit streng hypothesen-getriebenem Vorgehen gelingen kann. In nur drei Sprints wurde durch iterativ-inkrementelles Vorgehen im Zusammenspiel mit intensiver Product Discovery ein release-fähiges Produkt für rund 15.000 Kunden des Auftragnehmers geschafften. Das Scrum Team von Johannes Geske war allerdings zuvor schon komplett eingespielt und in der Zusammenarbeit entsprechend erfahren, so dass es hier keine Lernkurve der Teamentwicklung gab, sondern der komplette Fokus auf ein schnelles Lernen durch Feedback gelegt werden konnte. Johannes nennt solch ein Setup "Plug & Play Scrum Team". Konkret wurden durch das Team einige Hypothesen bereits während jedes Sprints durch Kundenbesuche und unmittelbares User-Feedback zum Produkt Inkrement verifiziert bzw. eben auch einige falsifiziert. Letzteres ist eigentlich besonders "schön", denn diese Ideen muss man dann ja auch gar nicht umsetzen und vermeidet Verschwendung. In seinem Erfahrungsbericht spricht Johannes Geske über die Learnings dieses Vorgehens, wie z.B. klare Problem-Fokussierung, wie Vertrauen beim Kunden für dieses Vorgehen erworben wurde sowie die Festpreis-Beauftragung je Sprint durch den Kunden, d.h. z.B. auch die Go/NoGo-Entscheidung nach jedem Sprint. Für alle, die sich Details in Ruhe durchlesen wollen, hat Amazing Outcomes eine vom Kunden freigegebene Case Study erstellt. Diese gibt's hier: https://amazing-outcomes.de/de/what-we-offer/plug-and-play-scrum-team-fuer-ihr-projekt Mehr über Johannes Geske und sein Team erfahrt ihr auf der Webseite von Amazing Outcomes: https://amazing-outcomes.de/. Gerne freut er sich auch über den direkten Kontakt zu euch - am besten per Mail (hello@amazing-outcomes.de) oder LinkedIn, wo ihr ihm auch folgen solltet: https://linkedin.com/in/johannesgeske/ Passende Episoden aus unserem eigenen Podcast rund um dieses Thema sind: - Agiler Festpreis – Chancen & Grenzen dieser Vertragsform - Das Problem mit dem Minimal Viable Product Wie bitte? In nur wenigen Wochen von der Idee zur Marktreife eines Produkts? Wie soll das denn bitte gehen? Tim hat Johannes Geske als Gast dazu eingeladen, denn er hat als Product Owner im Kundenauftrag für eine weltweit aktives B2B Unternehmen gezeigt, wie sowas mit streng hypothesen-getriebenem Vorgehen gelingen kann. In nur drei Sprints wurde durch iterativ-inkrementelles Vorgehen im Zusammenspiel mit intensiver Product Discovery ein release-fähiges Produkt für rund 15.000 Kunden des Auftragnehmers geschafften. Das Scrum Team von Johannes Geske war allerdings zuvor schon komplett eingespielt und in der Zusammenarbeit entsprechend erfahren, so dass es hier keine Lernkurve der Teamentwicklung gab, sondern der komplette Fokus auf ein schnelles Lernen durch Feedback gelegt werden konnte. Johannes nennt solch ein Setup "Plug & Play Scrum Team". Konkret wurden durch das Team einige Hypothesen bereits während jedes Sprints durch Kundenbesuche und unmittelbares User-Feedback zum Produkt Inkrement verifiziert bzw. eben auch einige falsifiziert. Letzteres ist eigentlich besonders "schön", denn diese Ideen muss man dann ja auch gar nicht umsetzen und vermeidet Verschwendung. In seinem Erfahrungs Welche Erfahrung habt ihr schon mit streng hypothesengetriebener Entwicklung gemacht? Wie gelangt ihr von einer Idee zur Marktreife? Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite. **Folgt uns Produktwerker auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

In dieser Episode sprechen wir über ein eher spezielles Thema: Welche Herausforderungen haben wir als Product Owner, wenn unser Produkt als Software im Auto läuft? Da von uns niemand bisher Software für Autos hergestellt hat haben wir uns Beate Radics eingeladen, die uns von ihren Erfahrungen berichtet. Sie erzählt uns von den Herausforderungen, die sie bei der Produktentwicklung hat und natürlich auch wie sie damit umgeht. Im Gespräch mit Dominique erzählt Beate erst einmal etwas zu ihrem Produkt und die beiden gehen schnell über zu den Besonderheiten. Zu den Herausforderungen, die Beate bei der Entwicklung hat, gehört beispielsweise die Art und Weise wie man Software in Autos aktualisieren kann. Neue Releases können eben nicht immer einfach eingespielt werden. Daneben gibt es aber Schwierigkeiten mit der Erhebung von Informationen rund um die Produktgestaltung. Während andere Produkte kontinuierlich Daten aus der Nutzung bereitstellen, ist dies bei Autos schon eine etwas andere Sache. Dennoch reizt Beate ihr eigenes Produkt und jeder Product Owner kann nachempfinden, wie wichtig eine gewisse Begeisterung vom eigenen Produkt ist. Das Gespräch schließt am Ende noch mit Tipps, für Product Owner, die Lust auf diese Herausforderungen haben und schon immer Software für Autos entwickeln wollten. Zum Abschluss sprechen Dominique und Beate darüber, was Beate an der Entwicklung von Software, die im Auto läuft, reizt.

Hast du schon einmal von "Organisatorischen Schulden" gehört? Wir nutzen den Begriff in Analogie zu "Technischen Schulden" und beziehen uns damit auf organisatorische "Abkürzungen", das (bewusste) Weglassen von Scrum Elementen oder einer Vernachlässigung agiler Ideen und Prinzipien in Organisationen, die langfristig zu Problemen und damit natürlich auch zu Kosten führen. In dieser Podcast-Episode beschäftigen sich Tim und Oliver mit diesem Thema und zeigen vor allem auf, wie organisatorische Schulden auch deinen Erfolg als Product Owner beeinflussen können. Als Product Owner oder agile Produktmanager bist du möglicherweise schon mit den Herausforderungen konfrontiert worden, die sich aus der Einführung von Scrum oder anderen agilen Methoden in deine Organisation ergeben können. Mal gibt es noch keinen Scrum Master, mal fehlt die Zeit für Reviews oder Retrospektiven. Oder du musst als Product Owner für drei oder vier Scrum Teams parallel wirken. Oliver und Tim erklären zunächst ihr Verständnis vom Begriff der "Organisatorische Schulden" und zeigen die Vorteile und Nachteile auf, wenn ich Organisationen im Rahmen der agilen Transformation oder bei der Einführung von Scrum in die organisatorische Schuld begeben. Denn, wenn man dies ganz bewusst macht, kann dies absolut Sinn machen - genau wie bewusst eigegangene "Technische Schulden", um ein Produkt oder Feature schneller an den Markt zu bekommen und mit ihm früher Outcome erzeugen zu können. Die beiden zeigen dann im Hauptteil eine ganze Reihe von Beispielen für organisatorische Schulden auf, die sie in ihrer Arbeit als agile Coaches und Berater erlebt haben. Dabei diskutieren sie, wie man sie erkennt und vor allem wie sie auf die Product Owner Rolle wirken. Natürlich gibt es aber auch wieder konkrete Tipps, wie du als Product Owner oder agiler Produktmanager mit organisatorischen Schulden umgehen kannst. Also, hör rein in die neueste Episode "Organisatorische Schulden beeinflussen deinen Erfolg als Product Owner" und erfahre, wie du dich als PO von ihnen nicht aus der Erfolgsspur bringen lässt. Im Gespräch werden folgende ältere, aber immer noch wertvolle, Episoden aus unserem eigenen Podcast rund um dieses Thema erwähnt: - Product Owner ohne Scrum Master – geht das? - Technische Schulden und wie wir als Produkt Owner damit umgehen - Dein Freund der Scrum Master Hast du dich schon mal bewusst mit dem Begriff der Organisatorischen Schulden beschäftigt? Wie geht ihr in eurer Organisation damit um - egal ob ihr das Phänomen so oder anders benennt? Wir freuen uns, wenn du eure Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels (https://produktwerker.de/organisatorische-schulden/) teilst oder auf unserer Produktwerker LinkedIn-Seite (https://www.linkedin.com/company/produktwerker). **Folgt uns Produktwerker auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

In dieser Folge setzen wir uns intensiv mit den verschiedenen Verantwortungen auseinander, die ein Product Owner während des gesamten Produktlebenszyklus übernimmt. Oft sprechen wir hier nämlich eher allgemein von den Aufgaben eines Product Owners, aber es ist wichtig zu verstehen, dass sich diese im Laufe der Zeit verändern und anpassen. Nach einer Einführung in die verschiedenen Phasen des Produktlebenszyklus werfen wir einen genaueren Blick auf jede einzelne Phase und die Aufgaben von uns als Product Owner. In der Einführungs- und Entwicklungsphase liegt der Fokus zum Beispiel darauf, Marktbedürfnisse zu identifizieren und Ideen sowie Konzepte zu entwickeln. In dieser Phase geht es also darum, schnell zu lernen, indem wir beispielsweise Prototypen entwickeln und Produktideen testen. Gleichzeitig wird die Wirtschaftlichkeit und die langfristige Bereitstellung des Produkts hinterfragt. Die Wachstumsphase ist geprägt von der Zusammenarbeit mit Vertrieb und Marketing, um die Kluft zu überwinden, die vor der Nutzung des Produkts durch die frühe Mehrheit der potenziellen Kunden steht (siehe dazu auch das Buch "Croissing the chams" von Geoffrey Moore). Hier ist es wichtig, die Preisstrategie zu entwickeln oder zu überprüfen und die Produktstrategie entsprechend anzupassen. In der Reife- und Sättigungsphase liegt der Schwerpunkt darauf, Marktanteile zu maximieren und die Produktqualität kontinuierlich zu verbessern. Neue Marktsegmente können gegebenenfalls erschlossen werden, indem zusätzliche Produktfunktionen (weiter-)entwickelt werden. Die Degenerationsphase kennzeichnet das Ende des Produktlebenszyklus. In dieser Phase sollten Product Owner nach Möglichkeiten suchen, das Produkt oder die Technologie umzustellen, um den Nutzen des Produkts sinnvoll zu verlängern. Es wird auch über die Einstellung des Produkts nachgedacht, um die Kunden nicht eifnach von heut auf morgen im Stich zu lassen. Am Ende bleibt noch, dass sich die verschiedenen Phasen für uns als Product Owner unterschiedlich anfühlen. Nicht in jeder Phase fühlt man sich gleich wohl. Daher empfehlen wir jedem, sich dieser Veränderungen bewusst zu sein und so zu erkennen, in welcher Phase man den größten Mehrwert in seiner Verantwortung schaffen kann. Genauso wie sich vielleicht die Zusammensetzung eines Teams sich je nach Phase des Lebenszyklus anpasst geht auch an uns die Veränderung nicht spurlos vorbei. Welche Erfahrungen habt ihr während der verschiedenen Phasen gesammelt? Gibt es Tipps, die ihr gerne anderen mitteilen wollt? Wir freuen uns immer über eure Geschichten! Teilt sie gerne hier in den Kommentaren oder auf unserer LinkedIn-Seite (https://www.linkedin.com/company/produktwerker/).

Wir sprechen in dem “Die Produktwerker” Podcast häufig über Digitalprodukte, da wir alle aus diesem Kontext kommen. Grund genug, mit Bernadette von Wittern einmal eine Expertin für Product Management für Hardwareprodukte einzuladen. Sie hat lange Jahre als Produktmanagerin in der Medizintechnik gearbeitet bevor sie 2020 mit ihrem Unternehmen Product Lounge den Schritt in die Selbständigkeit gewagt hat. Nachdem Bernadette einleitend ihr Verständnis von Produktmanagement geteilt hat, sprechen Oliver und Bernadette über die unterschiedlichen Aufgabenbereiche und Verantwortlichkeiten. Sie teilt dabei spannende Ergebnisse einer aktuellen Studie, die sie im Rahmen der Überarbeitung eines Produktmanagement Buches durchgeführt hat. Daraus kann man einen guten Überblick über das “state of the art” für Product Management für Hardwareprodukte bekommen: Welche Aufgaben haben Produktmanager wirklich? Was sind typische Herausforderungen im Joballtag? Was macht Produktmanager erfolgreich und persönlich zufrieden? Bernadette und Oliver schließen die Folge, indem sie auch auf Gehälter und die immer noch existierende Unterschiede zwischen Frauen und Männer blicken. Wie immer schließt die Folge mit Tipps und Tricks.

Viele Wege führen nach Rom... so heißt es ja ganz gern. Und auch zur Verantwortung als Product Owner gibt es unzählige Wege. In dieser Folge sprechen Dominique und Oliver über den Weg über die Verantwortung als Scrum Master, denn sicherlich gibt es den ein oder anderen Vor- und Nachteil, wenn man sich vorher in diese Rolle befunden hat. Ein ganz großer Vorteil ist natürlich, dass man sich schon lange mit Scrum und den verschiedenen Verantwortungen beschäftigt hat. Einem sind dann beispielsweise besonders die Vorteile von iterativer, inkrementeller Entwicklung eines Produkts bereits klar. Auch hat man meist schon viele Fertigkeiten und Erfahrungen beim Durchführen von Workshops gesammelt. Dafür wird man aber auch vor ein paar Herausforderungen stehen. Innerhalb einer Organisation ist ein Rollenwechsel manchmal nicht so leicht zu kommunizieren. Manche Menschen sehen einen noch in der alten Funktion. Gleichzeitig muss man aber in der neuen Rolle den Fokus auf das Produkt anstelle des Teams legen. Das Team wird nicht unwichtig aber der Fokus liegt nun auf der Wertschöpfung. Wenn dann jemand anderes (insbesondere jemand mit weniger Erfahrung) die Verantwortung als Scrum Master übernimmt, muss man sich bewusst zurückhalten und dem Scrum Master nicht ins Handwerk pfuschen. Die Zeit muss eher in den Aufbau von Fertigkeiten rund um Produktmanagementtechniken und Denkweisen liegen. Und wenn ihr denkt, man könne als Product Owner auch direkt die Verantwortung als Scrum Master übernehmen, dann empfehlen wir euch unsere Folge "Product Owner ohne Scrum Master" (https://produktwerker.de/product-owner-ohne-scrum-master/). Wir freuen uns immer über Feedback zu unseren Podcast-Episoden. Bist du selbst aus der Verantwortung als Scrum Master hin zum Thema Product Owner gegangen? Dann lass uns gerne an deinen Erfahrungen teilhaben. Gerne in den Kommentaren auf unserer Website (https://www.produktwerker.de/vom-scrum-master-zum-product-owner/) oder auf LinkedIn (https://www.linkedin.com/company/produktwerker/). Vielen Dank!

Ohne User Research sind wir ständig im Blindflug. Wir müssen irgendwie herausfinden, wie Menschen mit unserem Produkt interagieren und können auf Grundlage von User Tests bessere Entscheidungen treffen. In dieser Folge unterhält sich Dominique mit Indra Burkart darüber, wie wir als Product Owner das Team bei User Tests einbinden können. User Tests sind ein wichtiger Teil des Designprozesses und helfen, das Benutzererlebnis (UX) zu verbessern. Durch sie können wir besser dafür sorgen, dass das Endprodukt den Bedürfnissen und Erwartungen der Menschen entspricht. Dieses Feedback von echten Menschen sorgt dafür, dass wir Nutzungsprobleme frühzeitig entdecken und unsere Designentscheidungen überprüfen können. In der Zukunft können wir anderes arbeiten, bessere Entscheidungen treffen oder sogar große Probleme bei der breiten Anwenderschaft verhinden; alles mit dem Ziel die Benutzerakzeptanz zu steigern. Die Einbindung des Teams (z.B. Developer, Designer, Business Analysten uvm.) in User Tests trägt dazu bei, dass das Team besser versteht, wie das Produkt genutzt wird und welche Probleme oder Schwierigkeiten dabei auftreten. Wenn solche Tests von anderen für das Team durchgeführt werden, gehen oft wichtige Erkenntnisse verloren und der Aufbau von Empathie ist erschwert. Bei Tests sollte ein Team aber nicht nur dabei sein, sondern aktiv mitwirken. Zum Beispiel kann das Team gemeinsam die Tests auswerten und auch direkt klären, welche Konsequenzen sie für ihre Arbeit zu ziehen sind. Wenn ihr mehr über Indra herausfinden wollt, schaut doch einmal auf ihr LinkedIn-Profil oder noch besser auf ihren YouTube-Kanal. In der Folge haben wir übrigens noch folgende Inhalte referenziert: - Studie von Nielsen und Norman zur Anzahl notwendiger Testpersonen: https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/ - Wenn ihr mehr zum Thema Personas wissen wollt, empfehlen wir euch unsere Folge zu "Warum Personas für Product Owner wertvoll sind": https://produktwerker.de/warum-personas-fuer-product-owner-wertvoll-sind/ - Und zum Abschluss noch hier das Video von Indra zum Thema Usability Tests: https://www.youtube.com/playlist?list=PLgZriansjqQ4Q7gHx3ZUMFcZ3haBFfDPv Wir freuen uns immer über Feedback zu unseren Podcast-Episoden. Welche Erfahrungen habt ihr beispielsweise mit dem Einbinden des Teams in User Tests gemacht? Gibt es Tipps, die ihr gerne mit anderen teilen wollt? Teilt gerne eure Sichtweise auf LinkedIn (https://www.linkedin.com/company/produktwerker/).

In dieser Podcastfolge wird Oliver seinen Frust über Stellenausschreibungen für Product Owner los. Denn gefühlt wurden noch nie mehr Product Owner gesucht, aber die Inhalte der Jobausschreibungen lassen auf ein bedenkliches Bild auf die Verantwortlichkeiten schließen. Oliver teilt seine Einschätzung anhand von vielen, konkreten Beispielen aus Stellenausschreibungen auf LinkedIn und Stepstone. Oft lassen auch die Jobtitel, wie Team Product Owner oder Technischer Product Owner auf den Aufgabenbereich und das Verständnis des ausschreibenden Unternehmens schließen. Natürlich gibt Oliver auch Tipps, auf welche Details ich als wechselwilliger PO achten sollte. Was sind Elemente von wirklich guten Stellenausschreibungen und welche Informationen zu dem potentiell neuen Product sollte ich im Vorstellungsgespräch einfordern. Die Folge schließt mit zahlreichen konkreten Tipps und Tricks ab.

Was sind No-Code Tools? Manchmal auch Low-Code Tools genannt. An welchen Stellen im Produktmanagement können Produktteams davon profitieren? Tim hat die No-Code Expertin Lilith Brockhaus von visualmakers.de zu Gast und bespricht mit ihr die spannende Frage, ob und wie No-Code Tools Produktteams bei der Produktentwicklung helfen können. Dabei geht es zu Beginn natürlich erstmal um die Frage, was No-Code Tools (und auch Low-Code Tools) überhaupt sind. Ziemlich schnell macht Lilith klar, dass sie nicht glaubt, dass tatsächliche Programmierung bzw. coden damit obsolet wird. Vielmehr ergeben sich für Nicht-Programmierer neue Chancen, ihre Ideen schneller auszudrücken und mit Nutzern zu testen. Ihre These: es verändert sich hierdurch etwas in der Zusammenarbeit der Teams. Tim sieht zudem den großen Wert von No-Code Tools im Rahmen der Stakeholder-Kommunikation und eben grundsätzlich Ideen schnell und einfach mal ausprobieren zu können und halt auch mit weniger "Werkstolz-Schmerzen" das Gebaute wieder wegzuwerfen. Lilith gibt zudem eine ganze Reihe von Empfehlungen von No-Code Tools, die sie im Rahmen der Produktentwicklung einsetzen würde. - softr.io - levity.ai - make.com bzw. zapier.com - bubble.io - airtable.com bzw. seatable.io - bannerbear.com - webflow.com Auf der VisualMakers Website gibt es zu einigen dieser Tools auch hilfreiche Tutorials und eine Tool-Übersicht. Zum Abschluss reden die beiden noch über die mögliche Datenschutz-Problematik und die Chancen und Grenzen der Skalierung beim Einsatz von No-Code bzw. Low-Code. Hierzu empfiehlt Lilith, sich die Erfahrung von FINN mal anzusehen: https://www.visualmakers.de/case-study/finn-x-make Um tiefer ins Thema No-Code rein zu kommen, bietet VisualMakers kostenlose No-Code Einsteiger Kurse an: https://www.visualmakers.de/no-code-online-training Tiefer rein, kommt ihr dann mit dem Rapid Prototyping Bootcamp: https://basics.visualmakers.de/rapid-prototyping Tim empfiehlt auch explizit, den VisualMakers Podcast und ist bereits großer Fan. Dort könnt ihr noch viel mehr von Lilith Brockhaus und Alex Sprogis und ihren tollen Gästen hören. Mehr über Lilith Brockhaus erfahrt ihr auf der VisualMakers Website: https://www.visualmakers.de/. Gerne freut sie sich auch über den direkten Kontakt zu euch - am Besten per LinkedIn, wo ihr ihr auch folgen solltet: https://www.linkedin.com/in/lilith-brockhaus/ Passende Episoden aus unserem eigenen Podcast rund um dieses Thema sind: - Wie hole ich User Feedback mit Kundeninterviews ein? - Das Problem mit dem Minimal Viable Product Habt ihr schon Erfahrung beim Einsatz von No Code Tools bei euch im Produktteam? Und wenn ja, wie helfen sie euch und welche Tools habt ihr im Einsatz? Wir freuen uns, wenn du deine deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels (https://produktwerker.de/no-code-tools/) teilst oder auf unserer Produktwerker LinkedIn-Seite (https://www.linkedin.com/company/produktwerker). **Folgt uns Produktwerker auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K