Wenn in Produktteams das Verständnis fehlt, reden Menschen oft aneinander vorbei. Und manchmal reichen ein Stift und ein Flipchart, um das zu ändern. Olaf Bublitz kennt diese Situationen gut. Als erfahrener Agilist, Berater und Mitautor des neuen Buchs Visual Product Ownership setzt er sich seit Jahren dafür ein, visuelle Methoden in der Produktentwicklung gezielter und wirkungsvoller einzusetzen.

In dieser Folge spricht er mit Tim über die Kraft der Visualisierung. Nicht als Deko oder hübsches Extra, sondern als echte Unterstützung für Klarheit, Zusammenarbeit und Entscheidungsfindung. Denn visuelle Methoden in der Produktentwicklung helfen dabei, komplexe Zusammenhänge sichtbar zu machen – über alle Ebenen hinweg: von der Strategie bis zur operativen Umsetzung.

Olaf versteht unter visuellen Methoden nicht nur Zeichnungen oder Sketchnotes. Für ihn beginnt visuelles Arbeiten schon mit einem Canvas, einem Taskboard oder einer Map. Sobald Informationen so aufbereitet sind, dass man sie auf einen Blick erfassen und besprechen kann, entsteht ein gemeinsamer Fokus. Und genau darum geht es in der Produktentwicklung: Orientierung schaffen und Diskussion ermöglichen – ohne sich in Textwüsten zu verlieren.

Viele der Methoden, die Olaf beschreibt, helfen dabei, Perspektiven nebeneinander sichtbar zu machen. Ob Eventstorming, Story Mapping oder Strategy Maps: Sie bringen Teams ins Gespräch – und lassen Unterschiede, Lücken oder Missverständnisse frühzeitig erkennen. Genau das ist der eigentliche Mehrwert. Denn visuelle Methoden in der Produktentwicklung machen nicht nur Dinge sichtbar. Sie machen Zusammenarbeit möglich.

Es geht nicht darum, möglichst viele Methoden zu nutzen, sondern diese passenden auszuwählen – je nach Kontext, Ziel und Team. In seinem Buch fasst Olaf über 50 bewährte Methoden zusammen und stellt sie in sogenannten Strings dar: sinnvolle Verbindungen von Methoden entlang typischer Fragestellungen in der Produktentwicklung. So entstehen keine isolierten Visualisierungen, sondern ein durchgängiger visueller Arbeitsraum.

Besonders spannend wird es, wenn Teams ihre gesamte Produktarbeit sichtbar machen – etwa in Form eines sogenannten "Obeya"-Raums. Olaf beschreibt, wie visuelle Methoden in der Produktentwicklung dabei helfen, verschiedene Ebenen miteinander zu verbinden: Ziele, Kennzahlen, Roadmaps, Backlogs, Abhängigkeiten. Alles sichtbar, strukturiert und zugänglich – ob physisch im Raum oder digital auf einem Miro-Board. Was zählt, ist der gemeinsame Blick.

Die Folge ist eine Einladung: Visualisierung nicht als Stilmittel zu sehen, sondern als praktisches Werkzeug. Wer damit beginnt, kleine Elemente sichtbar zu machen – ein Ablauf, eine Idee, ein Engpass – schafft einen Einstieg. Und wer als Produktteam konsequent mit visuellen Methoden arbeitet, verändert nicht nur die Art, wie Entscheidungen getroffen werden. Sondern auch die Qualität der Zusammenarbeit.

Frühere Folgen die zum Thema gut passen bzw. in der Epsiode genannt wurden:

Wer mit Olaf Bublitz in Kontakt treten möchte, erreicht ihn gut über sein LinkedIn-Profil. Die Website zum Buch findet ihr unter: visual-productownership.de.

Welche visuellen Methoden nutzt ihr in der Produktentwicklung – und was funktioniert bei euch besonders gut?

Wir Produktwerker freuen uns, wenn du deine Tipps und Erfahrungen aus der Praxis mit den anderen Hörerinnen und Hörern teilen möchtest. Hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite.

Folgt uns Produktwerkern auf

Refinement ist kein Meeting. Es ist Produktarbeit. Aber wie viel Refinement braucht ein gutes Produktteam – und woran merkt man, ob es zu viel oder zu wenig ist? In der neuen Folge unseres Podcasts sprechen Dominique und Tim genau darüber.

Das Product Backlog Refinement gehört zu den meist unterschätzten (kontinuierlichen) Aktivitäten im Alltag von Product Ownern.

Für viele ist es ein Block im Kalender – ein weiteres Meeting, das Zeit kostet. Dabei wird oft übersehen, worum es wirklich geht: gemeinsam Klarheit schaffen. Denn das Missverständnis beginnt oft schon beim Begriff. „Refinement“ wird gerne als Scrum-Ritual verstanden. Als formaler Termin mit fixer Agenda. Doch darum geht es nicht. Es geht um kontinuierliche Verständigungsarbeit – um gemeinsames Denken und Entscheiden.

Wenn das fehlt, entstehen Unsicherheiten. Kontextwechsel häufen sich. Sprints ziehen sich, Entscheidungen werden vertagt, statt getroffen.

Was dann oft hilft sind weniger der Fokus auf das Meeting, als viel mehr der Fokus auf die Symptome:

Wenn sowas zu spüren ist, liegt es eher an der Qualität der gemeinsamen Produktarbeit.

Ein wirksames Refinement schafft Kontext, bevor Missverständnisse entstehen. Es lebt nicht von starren Regeln, sondern vom Gespür fürs Team, Produkt und Umfeld:

Tim und Dominique machen in dieser Episode deutlich:

Frühere Folgen zum Thema "Refinement":

Wie gelingt bei euch ein gutes Refinement – und woran erkennt ihr, wenn es Zeit für Veränderung ist? Wie viel Refinement braucht dein Team – und was funktioniert bei euch besonders gut (oder gar nicht)?

Wir Produktwerker freuen uns, wenn du deine Tipps und Erfahrungen aus der Praxis mit den anderen Hörerinnen und Hörern teilen möchtest. Hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite.

Folgt uns Produktwerkern auf

In dieser Podcastfolge spricht Daniel Koppel mit Oliver über seinen Weg in die digitale Produktwelt – und darüber, wie ihn die Ausbildung zum Produktmanager beruflich und persönlich verändert. Daniel kommt nicht aus der IT. Er hat eine kaufmännische Ausbildung gemacht, im Lager gearbeitet, Verantwortung übernommen. Aber irgendwann merkt er: Das kann es nicht gewesen sein. Der Job funktioniert – aber erfüllt nicht. Und das soll sich ändern.

Über Freunde aus der IT erfährt er mehr über agiles Arbeiten, über Quereinstiegsmöglichkeiten, über Produkte, die echten Nutzen bringen. Der Gedanke, sich beruflich neu auszurichten, wird konkreter. Daniel informiert sich, prüft Optionen und entscheidet sich schließlich für eine geförderte Ausbildung zum Produktmanager mit IHK-Abschluss. Nicht als Notlösung – sondern als echte Perspektive.

In der Ausbildung lernt er, wie moderne Produktentwicklung funktioniert: von Design Thinking bis Scrum, von Customer Journey Mapping bis Roadmapping. Er absolviert Zertifizierungen zum Scrum Master und Product Owner, entwickelt Produktideen, arbeitet an echten Use Cases – und erlebt, wie viel Freude es macht, Produkte mitzugestalten statt nur zu verwalten.

Gleichzeitig geht es um mehr als nur Inhalte. Daniel muss lernen, zu lernen. Sich zu strukturieren, dranzubleiben, Verantwortung zu übernehmen – auch für den eigenen Fortschritt. Genau das macht die Ausbildung zum Produktmanager für ihn so wertvoll: Sie fordert, aber sie gibt auch Sicherheit. Mit echtem Praxisbezug, sinnvollen Tools und guter Begleitung.

Was ihm besonders hilft: Die Ausbildung wird durch einen Bildungsgutschein gefördert. Und sie gibt ihm die Möglichkeit, Schritt für Schritt in den Beruf hineinzuwachsen. Heute steht Daniel kurz vor dem Abschluss, bereitet sich auf Bewerbungsgespräche vor und merkt, wie gefragt die Themen sind, mit denen er sich beschäftigt hat. Agilität, Nutzerzentrierung, Produktstrategie – das, was vor einem Jahr noch Neuland war, gehört inzwischen zu seinem Werkzeugkasten.

Daniels Geschichte zeigt, was eine gute Ausbildung zum Produktmanager leisten kann – besonders für Menschen, die den Quereinstieg wagen. Sie schafft Klarheit, stärkt Selbstvertrauen und eröffnet neue Wege. Und sie macht deutlich: Es ist nie zu spät, einen neuen Anlauf zu nehmen.

Wenn du selbst mit dem Gedanken spielst, dich beruflich zu verändern, mehr Verantwortung zu übernehmen oder tiefer in die digitale Produktwelt einzusteigen – dann hör in diese Folge rein. Vielleicht ist es genau der Impuls, den du brauchst.

Produktkrankheiten entstehen nicht über Nacht. Sie schleichen sich ein. Leise, manchmal kaum merklich. Und plötzlich ist das Produkt schwerfällig, das Team frustriert, die Nutzer:innen aus dem Blick geraten. In dieser Folge sprechen Dominique und Oliver über typische Produktkrankheiten, wie sie entstehen und was sie mit unserer täglichen Arbeit als Produktmenschen machen.

Einige der Krankheiten wie „Featureitis“, „Tool-Tourette“ oder „Prozess-Sklerose“ kommen uns erschreckend bekannt vor. Es sind genau die Muster, die sich in vielen Organisationen festsetzen, obwohl eigentlich alle das Gegenteil wollen. Mehr Klarheit, mehr Wirkung, mehr Verantwortung. Featureitis bedeutet beispielsweise, dass ein Produkt mit jedem Sprint wächst, immer neue Features bekommt, aber niemand weiß mehr, wofür es eigentlich steht. Teams liefern zuverlässig, aber niemand prüft, ob es überhaupt jemandem hilft. Stakeholder:innen fordern Features, die niemand priorisiert – aber die trotzdem gebaut werden. Genau hier zeigen sich das Konzept einer Produktkrankheit in ihrer vollen Wirkung. Sie erzeugen Aktivität ohne echtes Ziel und sie lassen uns Routinen folgen, die sich irgendwann wie Wahrheit anfühlen.

Typische Produktkrankheiten haben viele Ursachen. Sie entstehen durch Unsicherheit, durch fehlende Nutzerperspektive oder durch Organisationsstrukturen, die eher auf Output als auf Outcome optimiert sind. Manchmal ist es auch das Fehlen einer klaren Produktvision – oder zu viele Meinungen, die lauter sind als echte Erkenntnisse. Doch gerade weil Produktkrankheiten so verbreitet sind, lohnt es sich, sie beim Namen zu nennen. Nicht als Diagnose von außen, sondern als Einladung zur Reflexion, denn die erste wirksame Therapie ist Aufmerksamkeit: zu erkennen, dass etwas nicht stimmt. Und dann gemeinsam hinzusehen, was sich ändern lässt.

Diese Podcastfolge ist keine Checkliste für die perfekte Produktentwicklung. Aber sie soll helfen, ein Vokabular für das zu entwickeln, was in vielen Teams spürbar ist aber selten offen angesprochen wird. Und die Folge soll Mut machen wieder öfter zu fragen: Lösen wir mit unserem Produkt wirklich ein relevantes Problem oder folgen wir gerade einer gut geölten Routine, die zwar funktioniert, aber niemandem hilft?

Klarheit ist für uns Produktmenschen ein entscheidender Faktor, um auch in unsicheren Situationen handlungsfähig zu bleiben.

Gerade in der Produktentwicklung arbeiten wir oft mit unvollständigen Informationen. Arne beschreibt Klarheit als bewusste Entscheidung: den Kontext so gut wie möglich zu erfassen und daraus hilfreiche Orientierung abzuleiten – auch wenn absolute Sicherheit nie erreichbar ist. Zusammenarbeit funktioniert nur, wenn wir bereit sind, Unklarheiten aktiv zu klären und gemeinsam tragfähige Annahmen zu entwickeln.

Klarheit entsteht nicht von selbst. Sie muss immer wieder neu geschaffen werden, weil sich Rahmenbedingungen verändern. Wer das ignoriert, riskiert, auf überholten Annahmen zu entscheiden – mit allen Konsequenzen. Teams, die regelmäßig bewusst für Klarheit sorgen, arbeiten schneller, wirksamer und mit weniger Reibungsverlusten.

Dabei ist Klarheit oft unbequem. Sie verlangt, innezuhalten, nachzufragen und auch unangenehme Themen anzusprechen. Es kostet Mut und Energie, in Meetings Unsicherheiten offen zu machen, statt einfach weiterzugehen. Doch genau das zahlt sich aus: Was am Anfang Zeit kostet, spart später doppelte Arbeit und verhindert Missverständnisse.

Klarheit braucht eine Kultur, in der Fragen ausdrücklich erwünscht sind und Unsicherheiten nicht als Schwäche gelten. Psychological Safety wird so zur Basis für echte Zusammenarbeit. Nur wenn Menschen sich sicher fühlen, auch unbequeme Wahrheiten auszusprechen, können Teams wirkliche Klarheit herstellen und aufrechterhalten.

Im Gespräch wird auch deutlich, wie stark bewusste Sprache zur Klarheit beiträgt: Nicht vage bleiben, sondern präzise formulieren, nachfragen, visualisieren – so entsteht aus einem "Wir haben uns doch verstanden" eine belastbare Grundlage für Entscheidungen. Klarheit hilft, den Nebel frühzeitig zu lichten, bevor aus kleinen Missverständnissen große Probleme werden.

Arne bringt es treffend auf den Punkt: Produktmenschen tragen die Verantwortung, Klarheit herzustellen – selbst wenn es unbequem wird. Gerade in cross-funktionalen Teams und in der Zusammenarbeit mit Stakeholdern macht das den entscheidenden Unterschied zwischen gut gemeinter Abstimmung und echter Wirksamkeit.

Wer Klarheit über Komfort (siehe auch Matthew LeMay) stellt, schafft die Basis für nachhaltige Produktentwicklung – und stärkt nicht nur das eigene Team, sondern auch die eigene Wirksamkeit als Product Owner oder Produktmanager:in.

Weitere Empfehlungen zum Vertiefen

Weitere Quellen zu Klarheit

Wer mit Arne Kittler direkt in Kontakt treten möchte, erreicht ihn über seine Website (arnekittler.de) oder sein LinkedIn-Profil. Folgt ihm auch gerne auf LinkedIn.

Konferenz Product at Heart in Hamburg

Unsere klare Konferenzempfehlung ist die jedes Jahr von Arne organisierte Product at Heart in Hamburg - diesmal am Fr, 27. Juni 2025. Die Workshops am Vortag sind mal wieder schon komplett ausgebucht, aber für die Konferenz am Freitag gibt es derzeit noch letzte Tickets. Die Talks sind alle auf englisch und das Publikum (ca 700-750 Menschen) ist auch international (wenn auch im Schwerpunkt aus der deutschen Produktmanagement Szene). Diese von Petra Wille und Arne Kittler seit 2017 organisierte Veranstaltung (früher unter dem Namen "MTPengage") hat eine enorme Strahlkraft und bietet ganz hervorragend ausgewählte Speakerinnen und Speaker (dieses Jahr u.a. mit Marty Cagan, Henrik Kniberg) in einer großartigen Atmosphäre. Unser Tipp: plant in jedem Fall auch am Freitagabend noch die "After-Conference-Party" mit ein und reist erst am Samstag zurück - denn das ist ein großes Networking & Party Event!

Was denkst du zum Thema Klarheit? Hast du schon mal so über dieses Thema und die unterschiedlichen Dimensionen nachgedacht?

Wir Produktwerker freuen uns, wenn du deine Tipps und Erfahrungen aus der Praxis mit den anderen Hörerinnen und Hörern teilen möchtest. Hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite.

Folgt uns Produktwerkern auf

Viele Teams liefern solide Features, füllen regelmäßig ihr Sprint-Backlog und schaffen es, in kurzen Zyklen Output zu produzieren. Doch was am Ende häufig fehlt, ist die entscheidende Frage: Welche Wirkung hat das eigentlich beim Nutzer? Genau darum geht es in dieser Folge. Oliver und Tim nehmen sich die drei häufig vermischten Begriffe Output, Outcome und Impact vor und ordnen sie praxisnah ein – nicht als Buzzwords, sondern als Grundlage sinnvoller Produktarbeit.

Output ist schnell sichtbar. Ein Release ist gemacht, ein Feature live. Doch das allein reicht nicht. Outcome meint die Veränderung, die daraus entsteht – idealerweise beim Nutzer. Ein Verhalten, das sich ändert. Eine Aufgabe, die leichter fällt. Ein Problem, das nicht mehr existiert. Und genau darum sollte es gehen: Wirkung vor Lieferung. Es ist diese Wirkung, der wir in der Produktentwicklung hinterherlaufen sollten – nicht nur dem fertigen Feature.

Was das schwierig macht: Outcome ist oft nicht sofort greifbar. Er entsteht nicht exakt in dem Moment, in dem ein Button live geht oder ein Flow angepasst wird. Es braucht Beobachtung, echtes Nutzerverständnis, Hypothesen und die Bereitschaft, Wirkung als Lernfeld zu begreifen. Viele Teams bleiben beim Output stehen, weil er einfacher zu messen ist. Doch wer wirklich wissen will, ob ein Produkt erfolgreich ist, muss sich auf Outcome fokussieren – auch wenn das bedeutet, Unsicherheit auszuhalten.

Gleichzeitig braucht es gute Grundlagen, denn ohne verlässlichen, qualitativ hochwertigen Output gibt es auch keinen Outcome. Doch die reine Lieferung darf nicht zum Selbstzweck werden. Es geht darum, das Produkt so weiterzuentwickeln, dass es tatsächlich etwas verändert – beim Menschen, der es nutzt, und letztlich auch beim Unternehmen, das es anbietet.

Hier kommt der Impact ins Spiel. Denn wenn ein Feature genutzt wird, weil es einen echten Unterschied macht, dann kann daraus auch ein (positives) Geschäftsergebnis entstehen.

Oliver und Tim zeigen in der Folge, wie Product Owner diese Perspektive einnehmen können – nicht als dogmatischen Rollenwechsel, sondern als bewussten Schritt. Outcome-orientiertes Arbeiten bedeutet, sich stärker mit Nutzerverhalten zu beschäftigen, Hypothesen zu formulieren, die Wirkung von Features zu hinterfragen und gemeinsam im Team zu reflektieren, was funktioniert – und was nicht. Es geht darum, sich vom Projektdenken zu lösen, Raum für Lernen zu schaffen und sich nicht nur an der Anzahl der ausgelieferten Features zu messen, sondern an der Veränderung, die sie bewirken.

Outcome ist aber nicht immer eindeutig zuzuordnen. Manchmal braucht es Geduld, manchmal bleibt Wirkung aus, obwohl der Output gut war. Doch genau das ist der Kern moderner Produktentwicklung. Es geht nicht um Planbarkeit, sondern um Verantwortung für Wirkung. Und wer als Product Owner diese Wirkung gestalten will, kommt um den Outcome nicht herum.

Erwähntes Video zur Erklärung der Begriffe:

Frühere Folgen, auf die verwiesen wird:

Wie setzt du diese Begriffe ein? Wie erklärst du sie deinem Team und deinem Umfeld? Hast du weitere Tipps, um besser Outcome und Impact liefern zu können?

Wir Produktwerker freuen uns, wenn du deine Tipps und Erfahrungen aus der Praxis mit den anderen Hörerinnen und Hörern teilen möchtest. Hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite.

Folgt uns Produktwerkern auf

Die Verantwortung als Product Owner:in ist nicht mehr das, was sie mal war – und genau darin liegt die Herausforderung, denn Veränderung passiert. Sie kommt schleichend, manchmal unbemerkt, manchmal mit Ansage. In jedem Fall aber erfordert sie Orientierung, Mut und die Bereitschaft, sich selbst zu hinterfragen. In dieser Folge sprechen Annette Greil, Maik Seyfert und Dominique über genau diesen Wandel – und darüber, wie man ihn aktiv gestalten kann. Die Veränderung betrifft dabei nicht nur Aufgaben, sondern das gesamte Selbstverständnis der Rolle. Während Product Owner:innen früher oft stark in der Delivery verankert waren, verschiebt sich der Schwerpunkt zunehmend in Richtung Discovery, Strategie und Business-Verantwortung.

Das klingt erst einmal nach einem echten Upgrade. Doch mit der erweiterten Verantwortung kommen auch neue Erwartungen – und nicht selten Unsicherheit. Gerade wenn eine Organisation alte Strukturen aufbricht, entstehen Freiräume, die zwar viel Potenzial bieten, aber auch überfordern können. Denn: Nur weil man offiziell mehr entscheiden darf, heißt das nicht, dass man automatisch auch die Sicherheit hat, diese Entscheidungen zu treffen. Vergangenes Verhalten, kulturelle Prägung und gewachsene Erwartungen wirken oft lange nach. Viele Product Owner:innen müssen sich erst wieder zutrauen, wirklich agil zu arbeiten – gerade wenn sie aus stark regulierten oder hierarchischen Kontexten kommen. Was hilft, ist nicht nur methodisches Know-how, sondern auch ein Bewusstsein für die eigenen Stärken. Wer weiß, wie er tickt, kann besser mit Unsicherheit umgehen. Tools wie der Gallup Strengths Finder oder persönliche Reflexionsformate (vgl. dazu auch Sei dein eigenes Produkt) können hier wertvolle Unterstützung sein.

Doch Veränderung lässt sich nicht allein stemmen. Die Verantwortung als Product Owner:in entwickelt sich in einem Umfeld weiter – und dieses Umfeld muss mitziehen. Teams, Stakeholder, Führungskräfte: Alle sind Teil des Veränderungsprozesses. Das bedeutet nicht nur neue Absprachen und Verantwortlichkeiten, sondern auch das Aushalten von Reibung. Widerstände gehören dazu – und sie sind oft kein Zeichen von Ablehnung, sondern Ausdruck von Unsicherheit. Was es braucht, ist Kommunikation auf Augenhöhe und die Bereitschaft, sich gemeinsam auf Neues einzulassen. Veränderung gelingt nicht durch starre Frameworks oder das bloße Umbenennen von Rollen. Sie braucht Begleitung, Reflexion – und vor allem Zeit. Workshops, Coachings, Community-Formate oder interne Netzwerke können dabei helfen, einen stabilen Rahmen zu schaffen, in dem Entwicklung möglich ist.

Der wichtigste Rat von Annette und Maik: Ruhe bewahren. Nicht jede Veränderung ist sofort greifbar – aber sie ist eine Chance. Für persönliches Wachstum, für bessere Produkte und für eine stärkere Verbindung zwischen Technik, Business und Kund:innen. Am Ende ist es keine Frage, ob sich die Rolle des Product Owners verändert. Die Frage ist, wie wir damit umgehen. Wer neugierig bleibt, reflektiert und bereit ist, dazuzulernen, kann aus dem Wandel einen echten Entwicklungsschub machen. Für sich selbst – und für das ganze Produktteam.

Eine Zertifizierung ist für viele Product Owner ein Thema, das immer wieder aufkommt – oft dann, wenn sie neu in der Rolle sind oder sich weiterentwickeln wollen. Doch was bringt eine Zertifizierung wirklich? Ist sie nur ein Türöffner für den ersten Job oder hilft sie tatsächlich dabei, ein besserer Product Owner zu werden? Gleichzeitig gibt es eine Vielzahl an Anbietern für solche Zertifizierungen – von etablierten Organisationen wie der Scrum Alliance oder scrum.org bis hin zu eher unbekannten Anbietern. Jede Organisation verspricht einen eigenen Mehrwert. Manche Zertifikate lassen sich durch das Bestehen eines Online-Tests erwerben, andere setzen auf Trainings mit erfahrenen Coaches. Doch nicht jede Zertifizierung passt zu jedem Kontext oder Lerntyp.

Eine Zertifizierung kann ein guter Einstieg sein, um sich strukturiert mit den Grundlagen des Product Ownership auseinanderzusetzen. Sie gibt Orientierung und zeigt, welche Themen zur Rolle gehören. Aber sie ersetzt nicht die tägliche Praxis, nicht den Austausch im Team, nicht die Auseinandersetzung mit Stakeholdern oder Nutzerbedürfnissen. Wer Product Owner ist, lernt ständig dazu – unabhängig vom Zertifikat auf dem Papier. Besonders spannend wird es, wenn wir uns die Motivation anschauen, warum Menschen überhaupt eine Zertifizierung machen wollen. Geht es um ein besseres Gehalt? Um Sichtbarkeit im Unternehmen? Oder darum, sich selbst sicherer in der Rolle zu fühlen? Je nach Zielsetzung können ganz unterschiedliche Formate sinnvoll sein. Für manche ist zum Beispiel ein Einstiegskurs wie der „Professional Scrum Product Owner“ (PSPO I) ideal, andere profitieren mehr von Advanced-Kursen mit Fokus auf Stakeholder-Management, strategischer Produktentwicklung oder Leadership.

Zertifizierungen sind also weder gut noch schlecht – sie sind Werkzeuge. Und wie bei allen Werkzeugen kommt es darauf an, wie man sie einsetzt. Ein Product Owner, der gelernt hat, wie wichtig kontinuierliche Validierung von Hypothesen ist, wird sich nicht auf ein Zertifikat verlassen, sondern im Alltag ausprobieren, verwerfen, neu denken. Genau das macht die Rolle so anspruchsvoll – und so spannend. Am Ende zählt weniger, welches Logo auf dem Zertifikat steht, sondern was die Person daraus macht. Wer bereit ist, kontinuierlich zu lernen, Feedback anzunehmen und sich mit anderen POs zu vernetzen, braucht nicht unbedingt eine Zertifizierung, um gute Arbeit zu leisten. Aber sie kann ein sinnvoller Baustein sein – vor allem dann, wenn sie nicht als Endpunkt, sondern als Anfang verstanden wird.

Diesmal widmen wir uns dem User Experience Questionnaire (UEQ), einem bewährten Werkzeug zur Messung der UX. Bei uns zu Gast ist Andreas Hinderks, der an der Weiterentwicklung des UEQ mitarbeitet und besonders die Perspektive von Produktmenschen mit einbringt. Zur Zeit ist er Professor für Informatik, insbesondere Human Computer Interaction (HCI), an der Hochschule Hannover.

Der UEQ ist ein wissenschaftlich fundierter Fragebogen, der verschiedene Dimensionen der UX misst, darunter Attraktivität, Effizienz, Steuerbarkeit, Stimulation und Originalität. In der Praxis ermöglicht der UEQ eine schnelle und fundierte Einschätzung der User Experience. Anstatt sich auf subjektive Einzelmeinungen zu verlassen, erhalten Unternehmen messbare Daten, die klare Hinweise auf Stärken und Schwächen ihres Produkts liefern. Gerade für Product Owner ist dies ein entscheidender Vorteil, da sie datenbasierte Entscheidungen treffen können, um die Nutzerfreundlichkeit gezielt zu optimieren.

Im Gespräch diskutieren Dominique und Andreas, wie der UEQ in verschiedenen Kontexten angewendet werden kann. Besonders in agilen Entwicklungsprozessen bietet sich der Fragebogen an, um nach jedem Sprint oder größeren Produkt-Iterationen die UX-Qualität systematisch zu überprüfen. So lässt sich nachvollziehen, ob Anpassungen tatsächlich eine Verbesserung der Nutzererfahrung bewirken. Der UEQ hilft dabei, die subjektiven Eindrücke der Nutzer in eine objektive, vergleichbare Form zu bringen. Ein großer Vorteil des UEQ ist die Möglichkeit, Ergebnisse mit Benchmark-Daten zu vergleichen. Da der Fragebogen in vielen Branchen eingesetzt wird, können Unternehmen ihre Werte mit bestehenden Datensätzen abgleichen und so erkennen, wo ihr Produkt im Wettbewerbsumfeld steht. Natürlich bringt der Einsatz des UEQ auch Herausforderungen mit sich. Die Qualität der Ergebnisse hängt stark davon ab, wie sorgfältig die Befragung durchgeführt wird. Teilnehmer sollten den Fragebogen ehrlich und aufmerksam ausfüllen, um aussagekräftige Daten zu erhalten. Zudem sollten die Ergebnisse nicht isoliert betrachtet werden, sondern stets im Kontext der Produktstrategie und Nutzerbedürfnisse.

Zum Abschluss der Folge gibt Andreas praxisnahe Tipps, wie sich der UEQ optimal in den Arbeitsalltag integrieren lässt. Wer sich mit UX-Messung beschäftigt oder eine datenbasierte Entscheidungsgrundlage für die Weiterentwicklung seines Produkts sucht, findet in dieser Episode wertvolle Impulse. Der UEQ bietet einen pragmatischen Ansatz, um UX greifbar zu machen und nachhaltige Produktverbesserungen zu erzielen.

Wenn ihr mehr zum UEQ wissen wollt, schaut gern mal unter www.ueq-online.org. Dort bekommt ihr den Fragebogen in allen Sprachversionen aber auch Auswertungshilfen, die ihr kostenfrei nutzen könnt. Außerdem war Andreas schon mal mit dem Thema UX-Management zu Gast. Auch eine Folge, die wir sehr empfehlen können.

Produktqualität ist ein Thema, das Product Owner immer wieder vor Herausforderungen stellt. In der neuesten Episode der Produktwerker sprechen Oliver und Dominique darüber, wie Product Owner das Bewusstsein für Qualität im gesamten Team stärken können. Denn schlechte Produktqualität kann nicht nur die Nutzererfahrung negativ beeinflussen, sondern auch den Arbeitsfluss des Teams stören und langfristig viele negative Folgen verursachen.

Die Verantwortung für die Produktqualität wird in vielen agilen Produktteams unterschiedlich wahrgenommen. Während Entwickler häufig die technische Qualität in den Fokus stellen, müssen Product Owner sicherstellen, dass das Produkt nicht nur funktional, sondern auch nutzerzentriert und nachhaltig entwickelt wird. Hier entsteht schnell ein Spannungsfeld zwischen Geschwindigkeit und Sorgfalt. Oliver und Dominique sind sich einig: Qualität, egal über welche Perspektive man spricht, ist nicht verhandelbar. In einem iterativen Entwicklungsprozess muss Qualität von Anfang an mitgedacht und konsequent umgesetzt werden, damit ein stabiles, erweiterbares und zukunftsfähiges Produkt entsteht.

Auf der einen Seite ist die äußere Produktqualität wichtig, also wie Nutzer das Produkt erleben. Um sicherzustellen, dass ein Produkt einen Beitrag zur Problemlösung leisten kann, ist es wichtig, die Erwartungshaltung von Nutzern genau zu kennen und Metriken zur Messung der Nutzererfahrung zu etablieren. Product Owner können Qualität in den Fokus rücken, indem sie diese Metriken nicht nur bei der Entwicklung neuer Features berücksichtigen, sondern auch in Reviews und strategische Entscheidungen mit einfließen lassen.

Ebenso bedeutend ist die innere Qualität, also die technische Exzellenz des Produkts. Ein schlecht strukturierter Code kann langfristig zu Problemen führen, die die Entwicklung verlangsamen und Innovationen erschweren. Daher ist es wichtig, dass Product Owner Raum für technische Verbesserungen und nachhaltige Entwicklungspraktiken wie automatisierte Tests oder Refactoring schaffen. Hier sollten sie mit Entwicklern und dem Scrum Master offen diskutieren, wie viel Zeit für technische Qualität eingeplant wird, um langfristig effizient zu bleiben.

Ein weiterer Faktor ist die Zusammenarbeit im Team. Qualität entsteht nicht nur durch technisches Können, sondern auch durch gute Kommunikation, klare Verantwortlichkeiten und Vertrauen. Product Owner sollten in Retrospektiven gezielt das Thema Produktqualität ansprechen und gemeinsam mit dem Team reflektieren, welche Maßnahmen Qualität langfristig sichern können. Auch psychologische Sicherheit spielt eine Rolle: Teammitglieder müssen sich trauen, Probleme offen anzusprechen, um Verbesserungen anzustoßen.

Ein starkes Qualitätsbewusstsein entsteht nicht von heute auf morgen. Es erfordert kontinuierliche Aufmerksamkeit, einen gemeinsamen Anspruch an Exzellenz und eine Kultur der Zusammenarbeit. Product Owner haben dabei die Aufgabe, das Thema Qualität immer wieder ins Bewusstsein zu rufen und durch ihr eigenes Verhalten vorzuleben. Denn nur so kann langfristig ein Produkt entstehen, das sowohl technisch robust als auch für Nutzer wertvoll ist.