Die Produktwerker

Tim Klein, Dominique Winter, Oliver Winter

Im Podcast der Produktwerker besprechen wir Themen rund um die Rolle des Product Owners. Dazu tauschen wir uns nicht nur untereinander aus, sondern sprechen auch mit interessanten Gesprächspartnern aus allen möglichen Themenbereichen von Product Ownern. Die Produktwerker sind Tim Klein (@produktwerkCGN), Oliver Winter (@oliwin) und Dominique Winter (@designik). Als Experten für Produktentwicklungen haben wir uns in der agilen Community Kölns kennen und schätzen gelernt. Wir drei wollen die Kompetenz von Product Ownern und Produktorganisationen fördern, bessere Produkte und Services zu entwickeln. Wir freuen uns über Euer Feedback auf produktwerker.de, per Mail an podcast@produktwerker.de oder via Twitter an @produktwerker.

  1. vor 3 Tagen

    Product Backlog Priorisierung, wenn Aufwand nicht mehr die Bremse ist?

    In dieser Folge sprechen Oliver und Dominique über Product Backlog Priorisierung in einer Zeit, in der Aufwand als Bremse mehr und mehr als Kriterium verschwindet. Wenn KI Agenten Features nahezu ohne Realisierungsaufwand bauen, verliert das klassische Rechenspiel aus Wert geteilt durch Aufwand seine Grundlage. Genau diese Verschiebung nehmen die beiden zum Anlass, gängige Priorisierungsmethoden neu zu hinterfragen und erklären, was sich dabei in der Welt der Product Owner verändert. Viele bekannte Priorisierungsformeln setzen Aufwand in den Nenner. Das gilt für den klassischen Vergleich von Wert und Aufwand genauso wie für Ansätze wie Weighted Shortest Job First (WSJF). Überall steckt die Annahme drin, dass Entwicklungszeit eine knappe Ressource bleibt. Sinkt der Aufwand durch KI gestützte Entwicklung Richtung Null, verlieren diese Formeln ihre Rechengrundlage. Product Backlog Priorisierung braucht dann andere Kriterien, denn eine Reihenfolge bleibt trotzdem nötig. Selbst mit vielen parallelen Agents entstehen Abhängigkeiten zwischen Ergebnissen, die eine Sortierung weiterhin erzwingen. Ohne Aufwand als Korrektiv droht das Product Backlog zur reinen To do Liste einer reinen Product Delivery zu werden. Alles, was sich schnell umsetzen lässt, wird dann einfach abgearbeitet. Matt LeMay beschreibt in seinem Buch "[Impact-first Product Teams](https://mattlemay.com/books)" genau diese Gefahr der sog. "Death Spiral". Viele kleine, wirkungsarme Dinge machen ein Produkt am Ende schwerer wartbar und schwerer weiterentwickelbar. Wer sich nur auf kleine, billig gebaute Dinge konzentriert, ohne vorher zu klären, ob sie überhaupt Wert erzeugen, verliert genau diese Fähigkeit. Die eigentliche Frage lautet nicht, was sich bauen lässt, sondern was es wert ist, gebaut zu werden. Als Ersatz für Aufwand bringt Oliver einen Artikel von Jeff Gothelf ins Gespräch. Der Titel lautet [How to prioritize your backlog when effort is no longer the constraint](https://jeffgothelf.com/blog/how-to-prioritize-your-backlog-when-effort-is-no-longer-the-constraint/). Gothelf schlägt zwei Kriterien vor, die in bestehenden Priorisierungsformeln einfach die Spalte für Aufwand ersetzen können. Das erste Kriterium ist der Lernwert, also wie viel Erkenntnis die Umsetzung eines Backlog Items über Nutzerinnen, Markt oder Technik bringt. Das zweite Kriterium ist die Umkehrbarkeit, angelehnt an Jeff Bezos bekannte Unterscheidung zwischen leicht rückgängig zu machenden und kaum revidierbaren Entscheidungen. Aus beiden Achsen entsteht eine Matrix mit vier Feldern, die ganz unterschiedliche Umgänge mit Backlog Einträgen nahelegt. Hoher Lernwert und leichte Umkehrbarkeit markieren den Bereich, in dem sich schnelles, KI gestütztes Bauen besonders lohnt. Hier reicht es, zu bauen, zu messen und bei Bedarf wieder zurückzudrehen. Hoher Lernwert bei schwerer Umkehrbarkeit verlangt dagegen mehr Vorsicht. Oliver und Dominique sprechen über kleinere Spikes, Prototypen oder Fake Door Tests. Diese liefern genau den hohen Lernwert und lassen sich trotzdem leicht wieder zurücknehmen. Niedriger Lernwert kombiniert mit schwerer Umkehrbarkeit gilt beiden als das heikelste Feld überhaupt. Bleibt der Lernwert niedrig und die Entscheidung leicht umkehrbar, lohnt sich meist ein schneller Versuch ohne großen Abstimmungsaufwand. Gerade weil Bauen so günstig wird, gibt es die Gefahr von unreflektierten, teuren Entscheidungen. Wie schmerzhaft eine Umkehrung tatsächlich ausfällt, lässt sich selten allein am Schreibtisch beurteilen. Diese Einschätzung gelingt nur im Gespräch mit denjenigen, die Architektur und technische Realisierung im Detail kennen. Politische oder hierarchische Diskussionen um laute Stimmen und große Budgets lösen die beiden Kriterien ohnehin nicht auf. Sie verschieben aber den Fokus dieser Gespräche weg vom Aufwand hin zu Lernwert und Rückabwicklungsfähigkeit. Genau das verändert nach Einschätzung der beiden auch den Ton solcher Diskussionen.

  2. 17. Aug.

    Die fünf Funktionen von Produktvisionen

    In dieser Folge sprechen Oliver und Dominique über die fünf Funktionen von Produktvisionen. Sie erklären, warum viele Teams ihre Vision nach der Erstellung schlicht vergessen. Dominique begleitet seit vielen Jahren Produktteams als Coach und Trainer. Dabei hat er sich intensiv mit der Frage beschäftigt, was eine Produktvision eigentlich leisten muss, damit sie im Alltag wirkt. Genau darum dreht sich das Gespräch. Es geht nicht um die Erstellung eines Vision Statements, sondern um die Funktionen, die eine Vision danach erfüllen sollte. Am Anfang steht das Klären. Bevor ein Team eine knackige Formulierung sucht, muss es einiges klären. Für wen baut es das Produkt, welches Problem löst es dabei und unter welchen Bedingungen entsteht daraus Wert? Teams gehe hier oft zu schnell über konkrete Menschen hinweg. Stattdessen bemühen sie abstrakte Zielgruppen wie junge Erwachsene mit mittlerem Einkommen. Solche Beschreibungen helfen bei Entscheidungen kaum weiter. Wer dagegen über echte Bedürfnisse, Nutzungskontexte und die eigenen Organisationsziele spricht, schafft eine Basis für spätere Entscheidungen. Aus dem Klären wird noch keine Vision. Dafür braucht es die zweite Funktion, das Verdichten. Ein Team führt die gesammelten Erkenntnisse, Wünsche und teils widersprüchlichen Meinungen zusammen und wählt daraus eine gemeinsame Richtung aus. Verdichten bedeutet nicht, alles unterzubringen, sondern sich für eine Richtung zu entscheiden. Am Ende dieser Phase steht meist ein Satz oder ein Bild, das als Erinnerungsanker dient. Es hilft dem Team, sich immer wieder klarzumachen, wofür es eigentlich arbeitet. Damit dieser Anker im Alltag ankommt, braucht es die dritte Funktion: das Übersetzen. Eine Vision allein lässt praktisch jede Entscheidung zu, weil sie meist viel zu weit weg vom operativen Geschäft formuliert ist. Oliver und Dominique sprechen deshalb über die Verbindung zwischen Produktvision, Produktstrategie, Zielen und Roadmaps. Erst wenn eine Strategie erkennbar auf die Vision einzahlt und daraus ein Product Goal abgeleitet wird, entsteht eine Brücke. Sie verbindet den Alltag mit der langfristigen Richtung. Ohne diese Übersetzung bleibt die Vision ein hübscher Satz ohne Wirkung auf reale Entscheidungen. Die vierte Funktion, das Anwenden, prüft, ob die Vision tatsächlich in echten Produktentscheidungen sichtbar wird. Das betrifft die Priorisierung im Backlog, Gespräche in der Discovery, Sprintziele und die Einleitung eines Reviews. Hält sich ein Team an seine Vision, wenn ein wichtiger Termin, ein Wettbewerber oder ein großer Kunde Tempo verlangt? Genau in solchen Momenten zeigt sich, ob eine Vision wirklich handlungsleitend ist oder nur an der Wand hängt. Sichtbarkeit allein reicht dafür nicht, erst die tägliche Nutzung macht den Unterschied. Zum Schluss kommt das Lernen als fünfte Funktion ins Spiel. Dabei geht es darum, die Annahmen hinter der Vision regelmäßig zu überprüfen. Neue Erkenntnisse aus Research, Nutzung oder Marktbeobachtung fließen ein, während der eigentliche Erinnerungsanker meist stabil bleibt. Bleibt diese Funktion aus, entsteht mit der Zeit eine Art Visionsschuld. Veraltete Annahmen und widersprüchliche Zielbilder passen dann längst nicht mehr zur Realität. Wie oft ein Team diesen Check braucht, hängt von der Lebensphase des Produkts ab. Junge Produkte mit vielen neuen Erkenntnissen reflektieren häufiger, etablierte Produkte reichen oft schon vierteljährliche Runden. Die fünf Funktionen von Produktvisionen bilden kein Phasenmodell, das man einmal durchläuft, sondern ein Modell in dem sie sich gegenseitig andauernd beeinflussen. Ein Team kann in einer Funktion stark und in einer anderen schwach sein. Genau dieser Blick lohnt sich als Reflexionsübung. Ist das Verdichten gut, das Klären aber schwach, klingt eine Vision oft überzeugend, obwohl sie zu wenig fundiert ist. Sind Anwenden und Lernen niedrig, entsteht schnell der bekannte Wandpostereffekt, schön anzusehen, aber ohne echten Nutzen.

  3. 10. Aug.

    Produktentwicklung mit einem agentischen Team (BMad, GSD, Superpowers ...)

    In dieser Folge ist Alexander Sprogis bei Tim zu Gast. Gemeinsam sprechen die beiden über Produktentwicklung mit einem agentischen Team und über die Frameworks die man kennen sollte. Alex kommt ursprünglich aus der Softwareentwicklung und dem Produktmanagement. Früher gründete er mit Lilith Brockhaus die No-Code & Low-Code Ausbildung und KI-Beratung VisualMakers. Inzwischen baut er unter eigenem Namen seinen YouTube Kanal rund um AI Coding auf. Seine Leidenschaft gilt seit jeher dem Befähigen von Menschen. Heute geht es dabei vor allem um Coding Agents wie Claude Code. Wer einfach drauflos promptet, landet schnell im klassischen Vibe Coding. Viele Ergebnisse wirken gut, sind aber kaum reproduzierbar. Die KI trifft munter eigene Annahmen, ohne dich zu fragen. Alex vergleicht Coding Agents gern mit einem hastigen Junior Entwickler. Der liefert zwar schnell, neigt aber zum Overengineering. Auch Widerspruch legt so ein Agent nur selten ein. Dazu kommt ein Problem namens Context Rot. Je länger eine Session dauert, desto voller wird das Kontextfenster. Und desto öfter verliert die KI den roten Faden. Um dieses Chaos einzufangen, kann man vier Ebenen unterscheiden: Ganz unten steht das Sprachmodell (LLM) selbst, etwa Claude Opus oder Fable. Darüber liegt der Harness, also die Konfigurationsschicht, zum Beispiel Claude Code. Darüber wiederum sitzt das Framework als methodischer Rahmen für die eigentliche Arbeit. Innerhalb dieses Rahmens übernehmen einzelne Agenten oder Skills konkrete Rollen. Genau hier zeigt sich der Kern von Produktentwicklung mit einem agentischen Team. Ein gutes Framework bringt Struktur und wiederholbare Qualität in die tägliche Arbeit mit Coding Agents. Am ausführlichsten sprechen die beiden über die BMad Methode. BMad steht mittlerweile meist für "Breakthrough Method for Agile AI Driven Development" - manchmal aber auch für seinen Erfinder Brian Madison. Das Framework stellt ein komplettes agentisches Team aus neun Personas bereit. Die Business Analystin Mary erstellt mit dir zusammen ein Product Brief. Ein Produktmanager übersetzt das anschließend in ein PRD. Der Architekt Winston plant danach Technik und Stack. Am Ende entstehen daraus Epics und Storys mit klaren Akzeptanzkriterien. Es ist fast vergleichbar mit einem Team, das sich Dokumente zuwirft. Von echter gemeinsamer Arbeit an einem Inkrement (im Sinne von Scrum) bleibt allerdings wenig übrig. Ein sogenannter Party Mode bringt immerhin mehrere Agenten an einem Artefakt zusammen. Alex nutzt BMad selbst produktiv, sieht aber auch klare Grenzen. Für einzelne Personen entsteht schnell zu viel Dokumentation. Ein Project Brief kann schon mal mehrere Seiten lang werden. Ein Architekturdokument wird schnell zu einem kleinen Buch. Wer allein arbeitet, muss all das lesen und pflegen. Bei jeder Änderung fällt zusätzlich noch ein Review an. In kleinen Teams führt das schnell zu Overhead statt zu Tempo. Deshalb setzt Alex das Framework heute nur noch punktuell ein. Parallel schaut er sich längst andere Ansätze an. Als leichtere Alternative gibt es auch 'Get Shipped Done', früher bekannt als 'Get Shit Done'. Es läuft in einer kurzen Schleife aus fünf Phasen. Erst wird besprochen, dann geplant, dann umgesetzt, geprüft und ausgeliefert. Einzelne Unteragenten starten dabei mit einem leeren Kontextfenster. Sie melden am Ende nur ihr fertiges Ergebnis zurück. Ein Befehl namens Map Codebase schickt gleich sieben Unteragenten los. Die analysieren eine bestehende Codebasis aus verschiedenen Blickwinkeln. Das hilft besonders bei Legacy Projekten ohne gute Dokumentation. Superpowers verfolgen einen ähnlichen Ablauf, arbeiten aber testgetrieben. Erst entstehen die Tests, dann nur so viel Code wie nötig. So bremst das Framework Overengineering von vornherein aus. Neben BMad, Get Shipped Done und Superpowers fallen in der Folge noch weitere Namen. SpecKit von GitHub gehört dazu, ebenso Kiro von Amazon und AgentOS.

  4. 20. Juli

    "AI hilft uns ganz praktisch im Produktmanagement" (Erfahrungsbericht)

    Jan Werner spricht in dieser Folge mit Tim darüber, wie AI im Produktmanagement seinen Arbeitsalltag als Lead Product Manager von Instaffo massiv verändert hat und dass der größte Gewinn nicht in spektakulären Demos, sondern in vielen kleinen Verbesserungen liegt. Seine Erfahrungen stammen aus der täglichen Arbeit in der Praxis und zeigen, wie sich der Einsatz von AI Schritt für Schritt entwickelt. Der Einstieg in das Thema begann wie so oft mit einfachen Aufgaben wie Produkttexten und wuchs mit jeder neuen Erfahrung. Dadurch entstand nach und nach ein Arbeitsstil, bei dem AI selbstverständlich zum Werkzeugkasten in Jans Umfeld gehört, ohne dass die AI dabei Verantwortung für Entscheidungen oder Produktstrategie übernimmt. AI im Produktmanagement entfaltet ihren Wert dort, wo viel Zeit in wiederkehrende Denk- und Schreibarbeit fließt. Wer Anforderungen vorbereitet, Produkttexte formuliert oder umfangreiche Informationen zusammenführt, kennt den mental Load vor einem Refinement oder einer wichtigen Abstimmung. Genau an diesen Stellen schafft AI Freiräume. Statt Stunden in die Formulierung von Tickets oder Dokumenten zu investieren, bleibt mehr Zeit für Recherche, Bewertung von Erkenntnissen und den Austausch mit dem Team. Der Fokus verschiebt sich auf die Qualität der Entscheidungen und nicht auf die reine Produktion von Texten. Mit wachsender Erfahrung verändert sich auch die Art der Zusammenarbeit mit AI. Aus einzelnen Prompts entstehen persönliche Werkzeuge, die den eigenen Arbeitskontext kennen und auf bestehendes Wissen zugreifen. Repositories, wiederverwendbare Skills und agentische Arbeitsweisen sorgen dafür, dass Ergebnisse nicht jedes Mal neu aufgebaut werden müssen. Dadurch wächst das Vertrauen in den Einsatz und gleichzeitig steigen die Erwartungen an die eigene Arbeitsweise. AI im Produktmanagement entwickelt sich damit von einer Unterstützung für einzelne Aufgaben zu einem festen Bestandteil des gesamten Produktprozesses. Diese Entwicklung verlangt allerdings mehr als die Auswahl eines guten Modells. Wer AI sinnvoll einsetzen möchte, braucht Klarheit über den eigenen Arbeitsablauf und über die Qualität des vorhandenen Wissens. Schlechte Dokumentation oder fehlender Kontext lassen sich nicht durch bessere Prompts ausgleichen. Erst wenn Produktwissen sauber strukturiert vorliegt, kann AI darauf aufbauen und wirklich nützliche Ergebnisse liefern. Genau deshalb verändert sich mit dem Einsatz von AI im Produktmanagement nicht nur die tägliche Arbeit, sondern auch der Blick auf Dokumentation, Zusammenarbeit und kontinuierliches Lernen. Interview Guide Skill Jan hat uns im Nachgang auch noch seinen Interview Guise Skill für euch zur Nutzung oder Nachahmung bereitgestellt. Es ist ein Workflow, der Produktmanager durch den gesamten Lebenszyklus von Nutzerbefragungen begleitet: Vorbereitung, Analyse und Integration. Entwickelt für Claude Code. Funktioniert mit jedem Produkt, jedem Nutzertyp und jeder Teamzusammensetzung: https://github.com/jnwrnr/user-interview-guide-skill Umfrage: “Hands-on mit AI” – oder nur KI-Theater? Jan Werner checkt mit einer Survey, wie PMs und PO in der täglichen Arbeit wirklich mit AI arbeiten. Das ganze dauert nur ca. 10 Minuten und die Ergebnisse gibt’s exklusiv für Teilnehmende an der Umfrage. Wenn Du als Produktmanager:in oder Product Owner:in arbeitest, mach also bitte noch mit: https://handsonproduct.de/survey Folgende Episoden wurden von Tim im Laufe des Gesprächs erwähnt bzw. empfohlen: - Was kann AI im Produktmanagement heute schon wirklich? - Nutze Story Mapping, um mit Stakeholdern über Outcome zu sprechen - Seine Stakeholder kennen und richtig analysieren Wer weitere Fragen an Jan Werner hat oder mit ihm in Kontakt treten will, erreicht ihn am besten über sein LinkedIn-Profil.

  5. 13. Juli

    Erfahrungsbericht: Von UX zu PM

    Paul Wall spricht gemeinsam mit Dominique über seinen Weg von der User Experience ins Produktmanagement und darüber, warum der Wechsel von UX zu PM für ihn der nächste konsequente Schritt war. Viele Menschen mit einem Hintergrund in Design oder User Experience erleben, dass sie Nutzerinnen und Nutzer zwar sehr gut verstehen, auf wichtige Produktentscheidungen aber nur begrenzten Einfluss haben. Genau das hat Paul während seiner persönlichen Entwicklung gespürt. Er sucht nach mehr Verantwortung, möchte früher an Entscheidungen beteiligt sein und findet im Produktmanagement die Möglichkeit, seine Erfahrungen wirksamer einzubringen. Damit wird UX zu PM für ihn weit mehr als ein Rollenwechsel. Es verändert die eigene Perspektive auf Produkte und die Zusammenarbeit mit anderen Bereichen. Der Weg von UX zu PM beginnt bei Paul nicht mit einer Bewerbung, sondern mit der Erkenntnis, dass Veränderungen innerhalb seines damaligen Unternehmens kaum möglich sind. Er versucht zunächst, das Verständnis für User Experience auf unterschiedlichen Ebenen zu stärken. Als dieser Ansatz an Grenzen stößt, sucht er nach einer fundierten Weiterbildung statt nach einem kurzen Zertifikatskurs. Die Entscheidung für ein mehrmonatiges Vollzeitprogramm gibt ihm die Gelegenheit, Methoden des Produktmanagements intensiv kennenzulernen und direkt an einem eigenen Projekt anzuwenden. Gleichzeitig baut er auf Fähigkeiten auf, die er bereits aus der User Experience mitbringt. Empathie, das Verständnis für unterschiedliche Menschen und die Gewohnheit, Ideen früh sichtbar zu machen, helfen ihm dabei, auch in der neuen Rolle schnell Wirkung zu entfalten. Besonders spannend war für ihn, wie sich die Arbeitsweise verändert hat. Statt lange über Konzepte zu diskutieren, entstehen früh greifbare Entwürfe und Prototypen, die Gespräche mit Stakeholdern erleichtern. Gleichzeitig wächst das Bewusstsein dafür, dass erfolgreiche Produktarbeit mehr verlangt als gute Lösungen für Nutzerinnen und Nutzer. Wer den Schritt von UX zu PM geht, muss lernen, die Sprache von Geschäftsführung, Vertrieb und weiteren Beteiligten zu sprechen. Paul beschreibt, wie schon kleine Veränderungen in der Kommunikation die Akzeptanz für Ideen erhöhen können. Damit rückt nicht die Methode in den Vordergrund, sondern die Fähigkeit, unterschiedliche Perspektiven miteinander zu verbinden und gemeinsame Entscheidungen zu ermöglichen. Pauls Erfahrung zeigt, dass der Wechsel von UX zu PM weder zufällig noch einfach verläuft. Er verlangt die Bereitschaft, vertraute Denkmuster zu hinterfragen, neues Handwerkszeug zu lernen und Verantwortung für das gesamte Produkt zu übernehmen. Gleichzeitig wird deutlich, dass viele Kompetenzen aus der User Experience ihren Wert behalten und sogar an Bedeutung gewinnen, wenn sie mit Produktmanagement verbunden werden. Wer heute über den eigenen nächsten Karriereschritt nachdenkt, findet darin viele praktische Anknüpfungspunkte und erkennt, wie sich vorhandene Stärken in einer neuen Rolle gezielt weiterentwickeln lassen. Was Paul in dieser Folge erwähnt: - Event: Product Lean Coffee (https://www.linkedin.com/groups/12524562/) - Empfehlung: Simonetta Batteiger (https://www.linkedin.com/in/simonettabatteiger/) - Folge: JTBD (https://produktwerker.de/podcast-episode/mit-jobs-to-be-done-zu-mehr-kundenverstaendnis/) - Folge: Assumption Mapping (https://produktwerker.de/podcast-episode/assumption-mapping/) - Event: UX Festival (https://www.ux-festival.org/) - Fortbildung: Digitale Leute School (https://school.digitale-leute.de/) - Buch:  50 Arten Nein zu sagen (https://dpunkt.de/produkt/50-arten-nein-zu-sagen/)

  6. 6. Juli

    Der "Six Pager" als Form des Written Narrative

    In dieser Folge sprechen Tim und Dominique über den sogenannten "Six Pager" als besondere Form des Written Narrative. Der Six Pager stammt aus dem Umfeld von Amazon und steht für weit mehr als nur ein Dokument mit sechs Seiten Fließtext. Er schafft einen Rahmen, in dem Gedanken vollständig entwickelt werden, bevor andere Menschen darüber diskutieren und entscheiden. Genau darin liegt seine Stärke. Wer eine Idee schriftlich nachvollziehbar erklärt, beschreibt nicht nur die gewünschte Lösung, sondern setzt sich intensiv mit dem Problem, dem Kontext, den Annahmen, Gegenargumenten möglichen Alternativen und den Risiken auseinander. Das führt häufig zu einer deutlich besseren Grundlage für Entscheidungen als eine Präsentation mit wenigen Stichpunkten ("Death by PowerPoint"). Ein Six Pager verändert gleichzeitig die Art, wie Meetings ablaufen. Statt Folien zu präsentieren und dabei auf Vorwissen zu hoffen, lesen alle Beteiligten den Text zunächst gemeinsam. Erst danach beginnt die Diskussion. Dadurch entsteht ein gemeinsames Verständnis, bevor Meinungen aufeinander treffen. Niemand muss vermuten, ob einzelne Personen die Unterlagen vorher gelesen haben oder wichtige Informationen fehlen. Gleichzeitig zwingt das Schreiben im Vorfeld dazu, die eigenen Gedanken zu ordnen. Wer eine Idee nicht klar aufschreiben kann, hat sie oft selbst noch nicht vollständig durchdacht. Genau deshalb eignet sich ein Six Pager besonders für strategische Entscheidungen, neue Produktinitiativen oder wichtige Investitionen. Der Six Pager ist jedoch kein Werkzeug für jede Situation. Niemand sollte alltägliche Abstimmungen oder kleine operative Entscheidungen auf diese Weise dokumentieren. Der Aufwand lohnt sich dort, wo Tragweite und Unsicherheit zusammenkommen und unterschiedliche Sichtweisen berücksichtigt werden müssen. Gerade Product Owner, Produktmanager und Führungskräfte profitieren davon, weil sie Entscheidungen regelmäßig begründen und verschiedene Interessen zusammenbringen. Ein sauber formuliertes Written Narrative macht Annahmen sichtbar, legt Zielkonflikte offen und schafft eine gemeinsame Grundlage für konstruktive Diskussionen. Das verbessert nicht nur die Qualität von Entscheidungen, sondern auch die Zusammenarbeit innerhalb einer Produktorganisation. Wer den Six Pager zum ersten Mal ausprobiert, merkt schnell, dass Schreiben vor allem ein Denkwerkzeug ist. Gute Texte entstehen nicht nebenbei. Sie fordern Klarheit und machen Lücken im eigenen Verständnis sichtbar. Genau deshalb ersetzt ein Six Pager keine Präsentation, sondern verfolgt einen anderen Zweck. Statt Informationen möglichst kompakt auf Folien zu verdichten, entwickelt er einen nachvollziehbaren Gedankengang, der von der Ausgangssituation bis zur Empfehlung führt. So entsteht eine Entscheidungsvorlage, die Diskussionen auf ein deutlich höheres Niveau hebt und Produktteams dabei unterstützt, bewusstere und tragfähigere Entscheidungen zu treffen. Im Gespräch wurde auf diese älteren Episoden hingewiesen: - Assumption Mapping - Wie die Produktvision hilft, Product Ownern eine Richtung zu geben - Eine Produktstrategie ohne Canvas erarbeiten (mit Tim Herbig) Es gibt jede Menge gut Quellen, um noch tiefer in das Thema einzusteigen, z.B.: - Marty Cagan (svpg): Coaching Tools – The Narrative: https://www.svpg.com/coaching-tools-the-narrative/ - The Beauty of Amazon's 6-Pager: https://www.linkedin.com/pulse/beauty-amazons-6-pager-brad-porter - How Amazon Innovates: https://www.digitaltonto.com/2018/how-amazon-innovates/ - Working Backwards: https://medium.com/keqius-management-notes/working-backwards-e3a8ea5a99ab - What is a Narrative? (Video): https://youtu.be/lw9EO04MpJU - Working backwards: Amazon’s approach to innovation (Video): https://youtu.be/aFdpBqmDpzM

Bewertungen und Rezensionen

5
von 5
2 Bewertungen

Info

Im Podcast der Produktwerker besprechen wir Themen rund um die Rolle des Product Owners. Dazu tauschen wir uns nicht nur untereinander aus, sondern sprechen auch mit interessanten Gesprächspartnern aus allen möglichen Themenbereichen von Product Ownern. Die Produktwerker sind Tim Klein (@produktwerkCGN), Oliver Winter (@oliwin) und Dominique Winter (@designik). Als Experten für Produktentwicklungen haben wir uns in der agilen Community Kölns kennen und schätzen gelernt. Wir drei wollen die Kompetenz von Product Ownern und Produktorganisationen fördern, bessere Produkte und Services zu entwickeln. Wir freuen uns über Euer Feedback auf produktwerker.de, per Mail an podcast@produktwerker.de oder via Twitter an @produktwerker.

Das gefällt dir vielleicht auch