Die Produktwerker

Nader Fadl im Gespräch mit Tim 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, per Mail (nader@experial.ai) oder über die Webseite experial.ai in Kontakt treten. Oder ihr folgt seinem StartUp experial auf LinkedIn. 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

Dominique und Tim im Gespräch In dieser Folge referenzieren wir folgende Folgen: Produktmanager im Startup – ein Erfahrungsbericht (https://produktwerker.de/produktmanager-im-startup/) Fähigkeiten sehr guter Product Owner (https://produktwerker.de/fahigkeiten-eines-po/) Seine Stakeholder kennen und richtig analysieren (https://produktwerker.de/stakeholder-analysieren/) Sei dein eigenes Produkt! (https://produktwerker.de/sei-dein-eigenes-produkt/)

Johannes Geske im Gespräch mit Tim 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 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

Beate Radics im Gespräch mit Dominique Mehr über Beate erfahrt ihr auf ihrem LinkedIn-Profil.

Oliver und Tim im Gespräch 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 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

Oliver und Dominique im Gespräch Wie immer setzt sich der Inhalt dieser Folge in Beziehung zu anderem Wissen. Daher hier die Liste der Referenzen, die in dieser Folge genannt wurden: Crossing the chasm von Geoffrey Moore Das POEM (https://productownership.de/poem/ ) von Oliver und Tim Die vier Wissensdomänen der Produktentwicklung (https://www.designik.de/2018/08/die-vier-wissensdomaenen-der-produktentwicklung/ ) Folge über das Evidence Based Management (https://produktwerker.de/evidence-based-management/ ) Folge übers "Nein Sagen" (https://produktwerker.de/nein-sagen-als-product-owner/ )

Bernadette von Wittern im Gespräch mit Oliver 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.

Dominique und Oliver im Gespräch 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!

Indra Burkart im Gespräch mit Dominique 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/).

Olivers Gedanken 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.